Synapse Homeserver 1.163.0

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Synapse Homeserver 1.163.0 on Ubuntu 24.04 as the software version and your Region, then choose Launch through EC2.

Choose m5.large, your key pair and a security group as described above.

With the AWS CLI (replace the values in angle brackets; add --user-data file://server-name.yaml to set your own domain, see below):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=synapse}]'

Version SSH user

Synapse Homeserver 1.163.0 on Ubuntu 24.04 ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot generates every secret, creates the database and the administrator, then opens the front door. It takes under a minute:

systemctl is-active postgresql@16-main matrix-synapse coturn nginx matrix-stack-firstboot
sudo test -f /var/lib/sac/data/matrix-stack-firstboot.done && echo FIRSTBOOT_DONE

active active active active active FIRSTBOOT_DONE

If you connect in the first minute and the web address answers HTTP 503, first boot is still running; follow it with sudo journalctl -u matrix-stack-firstboot -f.

The versions on the image, and the Matrix client API answering through nginx:

dpkg-query -W -f='${Package} ${Version}\n' matrix-synapse-py3 printf 'element-web %s\n' "$(cat /var/www/element/version)" printf 'coturn %s\n' "$(/usr/local/bin/turnserver --version)" curl -ks -o /dev/null -w 'client API -> HTTP %{http_code}\n' https://127.0.0.1/_matrix/client/versions

matrix-synapse-py3 1.163.0+noble1 element-web v1.12.32 coturn 4.18.0 client API -> HTTP 200

sudo cat /root/matrix-stack-credentials.txt

The file is readable by root only:

matrix.server.name=<SERVER_NAME> matrix.web.url=https://<SERVER_NAME>/ matrix.homeserver.url=https://<SERVER_NAME> matrix.admin.user=<ADMIN_USER> matrix.admin.pass=<ADMIN_PASSWORD> matrix.admin.mxid=@<ADMIN_USER>:<SERVER_NAME> matrix.federation.port=8448 matrix.turn.realm=<SERVER_NAME>

When you need to share it, for example in a support request, print it with the password masked:

sudo sed -E 's/^(matrix\.admin\.pass=).*/\1********/' /root/matrix-stack-credentials.txt | grep '^matrix\.'

The signing key at /etc/matrix-synapse/homeserver.signing.key is this server's identity. It was generated on this instance and exists nowhere else: back it up with the database, and never copy it to another server.

Every socket bound to something other than loopback. This is the whole public surface, and it matches the security group table above (68 is the DHCP client):

sudo ss -lntuH | awk '{print $1, $5}' | grep -vE '127\.0\.0|\[::1\]|%lo' | sed -E 's/^(tcp|udp) (.*):([0-9]+)$/\1 \3/' | sort -u -k1,1 -k2,2n

tcp 22 tcp 80 tcp 443 tcp 3478 tcp 5349 tcp 8448 udp 68 udp 3478 udp 5349

PostgreSQL and the Synapse process listen on loopback only:

sudo ss -lntH | awk '{print $4}' | grep -E ':(5432|8008)$' | sort

127.0.0.1:5432 127.0.0.1:8008

Registration is closed, unknown host names are refused, and port 80 redirects to the configured name:

curl -ks -o /dev/null -w 'register -> HTTP %{http_code}\n' -X POST https://127.0.0.1/_matrix/client/v3/register \
  -H 'Content-Type: application/json' -d '{"username":"walkup","password":"not-allowed-123"}'
curl -ks -o /dev/null -w 'Host: evil.example -> %{http_code} (000 = connection closed)\n' -H 'Host: evil.example' https://127.0.0.1/ || true
S=$(sudo sed -n 's/^matrix\.server\.name=//p' /root/matrix-stack-credentials.txt)
curl -s -o /dev/null -w 'http:// -> %{http_code} %{redirect_url}\n' -H "Host: $S" http://127.0.0.1/

register -> HTTP 403 Host: evil.example -> 000 (000 = connection closed) http:// -> 301 https://<SERVER_NAME>/

Instance metadata is denied to every service; only the small address reader may reach it:

for u in nginx matrix-synapse coturn postgresql@16-main matrix-stack-firstboot; do printf '%-24s %s\n' "$u" "$(systemctl show -p IPAddressDeny --value $u.service)" done

nginx 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 matrix-synapse 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 coturn 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 postgresql@16-main 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 matrix-stack-firstboot 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128

The administrator password authenticates and a wrong one is refused. The request bodies go to curl on standard input, so the password never appears in the process list or your shell history. Synapse rate limits sign ins, so a burst of attempts may answer 429 instead of 403; both mean refused:

sudo bash -c ' F=/root/matrix-stack-credentials.txt U=$(sed -n "s/^matrix\.admin\.user=//p" $F) body() { printf "{\"type\":\"m.login.password\",\"identifier\":{\"type\":\"m.id.user\",\"user\":\"%s\"},\"password\":\"%s\"}" "$U" "$1"; } login() { curl -ks -o /dev/null -w "%{http_code}" -X POST https://127.0.0.1/_matrix/client/v3/login -H "Content-Type: application/json" --data-binary @-; } GOOD=$(sed -n "s/^matrix\.admin\.pass=//p" $F | { read -r P; body "$P"; } | login) BAD=$(body "wrong-password-xyz" | login) case "$BAD" in 403|429) B="refused ($BAD)";; *) B="UNEXPECTED ($BAD)";; esac echo "correct password -> $GOOD; wrong password -> $B" [ "$GOOD" = 200 ] && case "$BAD" in 403|429) true;; *) false;; esac '

correct password -> 200; wrong password -> refused (403)

Open https://<SERVER_NAME>/ in a browser. Use the public IP unless you set a domain.

The certificate is self-signed for this instance, so the browser warns you on the first visit. Accept it, or install a trusted certificate as described below. Sign in with the administrator user and password from Step 4. You land on your own homeserver.

Matrix verifies devices against each other so end-to-end encrypted history can be shared safely. The first device to sign in sets up the account's encryption identity; later devices are asked to confirm against one you already trust. That is normal Matrix behaviour.

Use the + beside Home to create a room, invite people and type into the composer. Rooms you create from Element are end-to-end encrypted by default. The room below was created through the API without encryption, which Element points out at the top of the timeline.

Settings, Account shows the full Matrix ID your homeserver issued, in the form @user:server-name.

Calls between people on restrictive networks are relayed by coturn. Synapse gives each signed-in client a short-lived TURN credential derived from a secret it shares with the relay, so there is no static call password to leak:

sudo bash -c ' F=/root/matrix-stack-credentials.txt U=$(sed -n "s/^matrix\.admin\.user=//p" $F) for i in $(seq 1 12); do T=$(sed -n "s/^matrix\.admin\.pass=//p" $F | python3 -c "import json,sys; print(json.dumps({\"type\":\"m.login.password\",\"identifier\":{\"type\":\"m.id.user\",\"user\":sys.argv[1]},\"password\":sys.stdin.read().strip()}))" "$U" \
  | curl -ks -X POST https://127.0.0.1/_matrix/client/v3/login -H "Content-Type: application/json" --data-binary @- \
  | python3 -c "import json,sys; print(json.load(sys.stdin).get(\"access_token\",\"\"))") [ -n "$T" ] && break; sleep 10 done [ -n "$T" ] || { echo "sign in is rate limited; wait a few minutes and retry"; exit 1; } H=$(mktemp /run/turn.XXXXXX); printf "Authorization: Bearer %s\n" "$T" > $H curl -ks -H @$H https://127.0.0.1/_matrix/client/v3/voip/turnServer \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(\"ttl:\", d[\"ttl\"]); [print(\"uri:\", u) for u in d[\"uris\"]]" curl -ks -H @$H -X POST -d "{}" https://127.0.0.1/_matrix/client/v3/logout >/dev/null; rm -f $H '

ttl: 86400 uri: turn:<SERVER_NAME>:3478?transport=udp uri: turn:<SERVER_NAME>:3478?transport=tcp uri: turns:<SERVER_NAME>:5349?transport=tcp

The relay refuses to forward traffic to loopback, private ranges, link-local addresses and the EC2 instance metadata address 169.254.169.254, so an authenticated user cannot use it to reach your VPC:

sudo grep -cE '^denied-peer-ip=' /etc/coturn/turnserver.conf
sudo grep -E '^denied-peer-ip=169\.254|^no-multicast-peers|^use-auth-secret' /etc/coturn/turnserver.conf

20 use-auth-secret no-multicast-peers denied-peer-ip=169.254.0.0-169.254.255.255

Registration is closed, so you create accounts. register_new_matrix_user reads the shared secret from this instance's own configuration. Give it the new password through a root-only file rather than on the command line, so it is never written to /var/log/auth.log or your shell history:

sudo install -m 600 /dev/null /root/newuser.pass
sudo nano /root/newuser.pass
# type the new user's password, save sudo /opt/venvs/matrix-synapse/bin/register_new_matrix_user \
  -c /etc/matrix-synapse/conf.d/90-sac-instance.yaml \
  -u alice --password-file /root/newuser.pass --no-admin http://127.0.0.1:8008 sudo shred -u /root/newuser.pass

Use --admin instead of --no-admin for another server administrator. Run it without --password-file and it prompts for the password instead.

To let people sign up themselves, set enable_registration: true in /etc/matrix-synapse/conf.d/10-sac.yaml, pair it with email verification or a registration token so you are not an open relay for spam, and sudo systemctl restart matrix-synapse. Synapse also supports SAML, CAS and OpenID Connect single sign on; configure your provider in the same directory.

The Synapse admin API listens on loopback only. Reach it over an SSH tunnel, for example ssh -L 8008:127.0.0.1:8008 ubuntu@<public-ip>, then call http://127.0.0.1:8008/_synapse/admin/... with an administrator's access token.