Continuwuity

• In the Azure Portal, choose Create a resource and search the Marketplace for Continuwuity on Ubuntu 24.04 LTS by SecureAnyCloud.
• Select the offer and choose Create.
• On Basics, pick your subscription, resource group and region, name the VM, and choose size Standard_B2s.
• Set the authentication type to SSH public key and provide your key.
• On Networking, attach a network security group that allows inbound TCP 22, 80 and 443 as described above.
• Review and create the VM. When deployment finishes, note the VM's public IP address.

az group create --name continuwuity-rg --location eastus
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:continuwuity:default:latest
az vm create \
  --resource-group continuwuity-rg \
  --name continuwuity \
  --image sac1647283583153:continuwuity:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# open ssh + the HTTPS client-server API (and 80 for the redirect)
az vm open-port --resource-group continuwuity-rg --name continuwuity --port 22 --priority 1001
az vm open-port --resource-group continuwuity-rg --name continuwuity --port 443 --priority 1002
az vm open-port --resource-group continuwuity-rg --name continuwuity --port 80 --priority 1003

First boot sets the homeserver's server_name to the VM's public IP address, so the server is ready to use as soon as the VM is up. If you intend to use a real domain and federation, set that up before you onboard users (see Step 8). The Matrix server_name cannot be changed after the database is initialised without a wipe.

Connect over SSH as azureuser. Confirm that both services are healthy and that the pinned release is in place:

sudo systemctl status continuwuity --no-pager | head -6 sudo systemctl is-active continuwuity.service nginx.service cat /opt/continuwuity/VERSION

The output shows continuwuity.service as active (running), nginx.service as active, and the provenance file recording the pinned upstream release and its SHA-256 digest:

● continuwuity.service - Continuwuity Matrix homeserver (sac) Active: active (running) since ... active active product=Continuwuity version=26.7.2 upstream=https://forgejo.ellis.link/continuwuation/continuwuity

Run continuwuity-selftest, which proves that the homeserver is serving the Matrix client-server API and not merely listening on a port. It queries the API over TLS, confirms that an unauthenticated registration is refused, then logs in as the per-VM admin and creates a room:

curl -sk https://127.0.0.1/_matrix/client/versions | head -c 120 echo
sudo continuwuity-selftest

Expected output:

{"versions":["r0.0.1","r0.1.0","r0.2.0","r0.3.0", ... continuwuity-selftest — proving the Matrix CS API round-trip for <SERVER_NAME> [ OK ] GET /_matrix/client/versions returned the version list over TLS on :443 [ OK ] token-less registration was correctly REJECTED (registration_token required) [ OK ] per-VM admin @admin:<SERVER_NAME> logged in and obtained an access token [ OK ] the admin token created a room (!...) — CS API round-trip is complete continuwuity-selftest: PASS — CS API up, open registration refused, per-VM admin logs in and creates a room.

Read the credentials summary that first boot wrote. Only root can read it. It contains this VM's server_name, the admin login and the registration token:

sudo cat /root/continuwuity-credentials.txt

The file looks like this. The values are unique to your VM:

continuwuity.server_name=<your VM public IP or domain> continuwuity.client_url=https://<your VM public IP or domain> continuwuity.admin_user=admin continuwuity.admin_mxid=@admin:<your VM public IP or domain> continuwuity.admin_password=<generated on first boot> continuwuity.registration_token=<generated on first boot>

Keep this file safe. The admin account is your Matrix server administrator, and the registration token lets you add more users (Step 7).

Continuwuity has no web console of its own, so you use a standard Matrix client. In Element (web, desktop or mobile):

• Choose Sign in, then Edit or Other homeserver.
• Enter the homeserver URL from your credentials file: https://<your VM public IP or domain>.
• Sign in as username admin with the admin_password from the credentials file.

The image ships a self-signed certificate, so your client or browser warns about the certificate until you install a real one (Step 8). The admin account is automatically a member of the server's admin room. You administer the server from that room by sending commands to the server bot.

Registration on this server is not open. A new account requires the per-VM registration token, which stops your homeserver from becoming a spam relay. Confirm that an unauthenticated registration is refused, and check the network posture, with these commands:

curl -s -XPOST 'http://127.0.0.1:6167/_matrix/client/v3/register?kind=user' \
  -H 'Content-Type: application/json' \
  --data '{"username":"open","password":"Abc-123456","auth":{"type":"m.login.dummy"}}' echo ss -lnt | grep -E ':443|:6167|:80 '

The registration is rejected because no valid registration flow exists without the token. The output also shows that the homeserver listens on 127.0.0.1:6167 only, while nginx owns 0.0.0.0:443 and 0.0.0.0:80:

{"errcode":"M_INVALID_PARAM","error":"No flows include the supplied stage"} LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 511 0.0.0.0:443 0.0.0.0:* LISTEN 0 128 127.0.0.1:6167 0.0.0.0:*

To let a colleague join, give them the registration_token from your credentials file. They enter it in their Matrix client when they register.

To close registration entirely once your users are set up, set allow_registration = false in /etc/continuwuity/continuwuity.toml and run sudo systemctl restart continuwuity.

Every secret on this VM is generated on first boot and is unique to it. That covers the homeserver ed25519 signing key (stored inside RocksDB, never baked into the image), the admin password, the registration token, and the nginx TLS certificate and key. Check the credentials file and the key identifiers:

sudo ls -l /root/continuwuity-credentials.txt grep -E 'server_name|admin_mxid|signing_key_ids' /root/continuwuity-credentials.txt

Install a real certificate. For production, point a DNS name at the VM and replace the self-signed certificate. The nginx vhost already leaves an ACME challenge path open, so you can use a certificate tool such as certbot. Alternatively, place your own certificate and key at /etc/continuwuity/tls/cert.pem and /etc/continuwuity/tls/key.pem and run sudo systemctl reload nginx.

Federation. Federation endpoints are enabled, and nginx serves the /.well-known/matrix/server and /.well-known/matrix/client delegation files. The image ships with a self-signed certificate and an IP server_name, so other homeservers cannot federate with this VM until you deploy it with a real domain name and a real certificate. The server_name is fixed once the database is initialised, so plan your domain before you onboard users if you intend to federate.

Use systemd to restart the services and follow the homeserver log:

sudo systemctl restart continuwuity
# restart the homeserver
sudo systemctl restart nginx
# restart the TLS reverse proxy
sudo journalctl -u continuwuity -f
# follow the homeserver log

Configuration lives in /etc/continuwuity/continuwuity.toml. Edit the file and restart continuwuity to apply your changes. The Continuwuity configuration reference documents every option.