Synapse + Postgres + Element on a Ravelin at $23.90/mo. Your homeserver relays and federates; it cannot read its own E2E traffic; Nordic jurisdiction means nobody can politely ask it to start trying.
Ravelin at $23.90/mo carries a ~100-room well-federated Synapse comfortably — Postgres, Redis, the Synapse workers, room state cache, all on the same box.
End-to-end encryption is structural — the homeserver relays ciphertext it cannot decrypt. KYC-free admin signup means the operator does not carry a paper trail either.
Nordic jurisdiction + no-logs-by-design + unmetered uplink. Federation chatter for an active room set is real volume; it does not invoice extra here.
Joining matrix.org is the right answer for most people. Running your own homeserver is the right answer when your handle, your room membership and your message metadata should not live on someone else's administrative panel. The protocol is federated, the encryption is end-to-end; the missing piece is "who controls the box my account is anchored to", and the answer changes the threat model materially.
Matrix's federation model is generous: any homeserver can talk to any other homeserver, rooms span servers, encryption follows the user, and there is no central directory required to participate. Once your homeserver is running and validated against the federation tester, your account is a first-class citizen of the network — the same as @user:matrix.org or @user:mozilla.org, just on your domain.
The operational story for Synapse is well-trodden: Docker Compose template upstream, Postgres for state, Redis for the worker pool, optional sharded workers for high-volume federation. None of it is novel; all of it is documented; the failure modes are known.
The right question is not "self-host or matrix.org" in the abstract — it is "do I want my federation identity anchored to a box I administer". If the answer is yes, the rest of this page is the recipe.
For a community homeserver with ~100 rooms (mix of small DMs and a handful of well-populated public rooms federated outward), the Ravelin ($23.90/mo, 8 vCPU, 16 GB, 480 GB NVMe) is the right tier. Synapse's Python data path is RAM-hungry under federation bursts — a popular room joined by a server with 50k users produces a transient state-resolution spike that wants headroom. 16 GB absorbs that comfortably.
Beyond ~1000 active rooms or once federation traffic pushes Synapse to need its sharded worker mode, the Bulwark tier gives you the cores to run dedicated federation_sender, synchrotron and event_persister workers — Synapse's horizontal scaling story within a single box. At that point you also want to think about whether Postgres should be on its own VPS; we can talk about a two-box layout.
For a personal homeserver — your account, a few DMs, a couple of small private rooms — a Garrison ($11.90/mo, 4 vCPU, 8 GB, 240 GB NVMe) is plenty. Conduit on a Sentinel is technically possible for a single-user setup, but Synapse on a Garrison gives you the room to grow without a migration.
What none of these are: a thousand-tenant managed-Matrix offering. NordBastion is built for the operator running their own homeserver for people they know — not for selling Matrix accounts to strangers.
A skeleton sketch — the upstream element-hq Synapse docs remain the authoritative reference for homeserver.yaml tuning and worker mode.
The official Docker engine + the Compose v2 plugin. Element-HQ publishes a maintained Synapse image you can pin by tag.
curl -fsSL get.docker.com \
| sh
apt install \
docker-compose-pluginThe Synapse image's one-shot "generate" mode writes a starter config keyed to your server_name. Disable open registration on the same pass.
docker run --rm \
-v ./data:/data \
-e SYNAPSE_SERVER_NAME=example.org \
matrixdotorg/synapse:latest \
generatePostgres is the production store; SQLite is for testing only. Redis is required for the worker pool even if you start single-process.
# add to docker-compose.ymlpostgres: postgres:15
redis: redis:7-alpine
# then in homeserver.yaml: database driver psycopg2Two small JSON files at /.well-known/matrix/{client,server} on your apex domain. Served as application/json with CORS Access-Control-Allow-Origin: *.
# /.well-known/matrix/server
{"m.server": "matrix.example.org:443"}
# /.well-known/matrix/client
{"m.homeserver":{"base_url":"https://matrix.example.org"}}federationtester.matrix.org checks well-known, certificate chain, TLS handshake, version handshake, and key exchange. Do not invite users until it is green.
# paste server_name into:# federationtester.matrix.org
# all checks must be greenregistration_shared_secret in homeserver.yaml + register_new_matrix_user CLI = an admin account without ever opening public signup.
docker compose exec synapse \
register_new_matrix_user \
-a -c /data/homeserver.yaml \
http://localhost:8008End-to-end encryption is a strong claim. It is undermined the moment the hoster of the relay knows, from billing-side KYC, exactly which legal person stood up this homeserver. KYC-free signup with crypto-only billing keeps the relay's administrative metadata as opaque as the relay's payload metadata is: "the prepaid balance behind this email", end of story.
Matrix's end-to-end encryption already arithmetically prevents the relay from reading payloads. Nordic jurisdiction adds a second layer: no data-retention mandate forcing the hoster to log connection metadata, no client-side scanning legislation actioned, and a published warrant canary that describes what would happen if someone tried to change the math (we cannot). Two layers of "no" beat one.
A federated homeserver in a few well-populated public rooms pushes a lot of small federation events — every join, every state change, every message receipt is a deliver-to-N-servers fan-out. The aggregate is not enormous but it is sustained, and any hoster that bills by GB-out makes the operator nervous. Unmetered uplink removes the cognitive overhead: federate as much as the protocol demands; the invoice is the same.
Self-hosting a Matrix homeserver is one of the cleanest sovereignty moves a small group can make for its messaging. For the price of a single SaaS chat-tool seat you get a federated, end-to-end encrypted homeserver whose handles outlive any platform, whose moderation is yours, and whose hosting is in a jurisdiction with neither data-retention mandates nor client-side-scanning legislation actioned.
NordBastion is opinionated about the parts that matter for this specific job — KYC-free admin signup, Nordic jurisdiction, unmetered uplink — and deliberately ordinary about the rest. Docker is Docker. Synapse is Synapse. Element-HQ ships the image; we ship the box.
Take an evening, run through the six steps, validate against the federation tester, mint the admin. The homeserver outlives the evening by years.
The eight questions Matrix admins actually wrestle with before docker compose up. Well-known delegation is question two for a reason.
Because the server is one machine and the messages live forever. Anyone with disk access — a snapshot accident, a forensic image, a co-admin gone rogue, a successor when you eventually hand the box off — sees plaintext if the room is unencrypted. End-to-end encryption keeps the homeserver useful (it relays, it federates, it presents the UI) while making the message payload arithmetic-unreadable to anything but the participant's device keys. Self-hosting and E2E are belt + suspenders: you control the relay AND the relay cannot read its own traffic.
Matrix lets your user-facing domain (example.org) differ from your server-facing domain (matrix.example.org) by serving two small JSON files at https://example.org/.well-known/matrix/client and /.well-known/matrix/server. The client one tells Element which homeserver URL to use; the server one tells federating peers where to reach Synapse for the s2s API. People trip on three things: serving the files with the wrong Content-Type, CORS not allowing other instances to fetch them, or the server file pointing at a port that the firewall does not actually expose. Validate with federationtester.matrix.org before publishing the room.
Synapse (Python, the reference implementation) is what 95% of public homeservers run; it is the most-tested federation peer and the only one that supports every feature the spec defines. Conduit (Rust, single binary, RocksDB) and Dendrite (Go, microservices) are lighter — Conduit famously runs on a Raspberry Pi. For a public-facing federated homeserver with users on it, Synapse is the answer; for a hobbyist single-user server you can experiment with Conduit on a Sentinel. This editorial assumes Synapse.
Set enable_registration: false in homeserver.yaml and rely on the registration_shared_secret to mint accounts via the admin API for the people you actually want. Alternatively, enable_registration_without_verification: false combined with a hard-coded shared-secret invite flow. The Matrix federation is large enough that any open-registration homeserver becomes a spambot account farm within days; the canonical answer is "registration is admin-curated, federation is open".
No — the Matrix C-S API is the protocol contract, and every conformant client speaks to every conformant server. Element is the default and the most-tested; Cinny is a lighter web client that some self-hosters prefer to bundle; SchildiChat is an Element fork with the Telegram-style UI; FluffyChat targets mobile-first. The homeserver does not see or care which client a user is on. Pick what your community prefers, change it later, no migration involved.
Each Matrix user has a set of device keys (per-device, ephemeral) and a cross-signing key (per-account, long-lived). The cross-signing master key is what lets a user add a new device without re-verifying everything; lose it and the user is locked out of historical E2E messages until they re-key. Element's "Secure Backup" feature encrypts the cross-signing key with a passphrase or recovery key and stores it server-side as opaque ciphertext — the homeserver holds the blob but cannot read it. Document the recovery-key step for your users at signup; it is the single piece of UX that prevents avoidable lock-outs.
Not directly — rooms are federated objects, not per-server records, so "moving" a room means upgrading it (a Matrix-native primitive that creates a successor room and stubs the old one with a redirect) and inviting the same set of participants. The room ID changes, the alias can follow. Direct user-account migration between homeservers is a long-standing Matrix wishlist item (account portability is on the spec roadmap); today you create a new account on your server and ask people to re-add you.
Matrix has per-room moderation primitives (kick, ban, redact, room admins) and per-server moderation primitives (denylist via the Synapse module API, MJOLNIR bot for managed denylists, server-level allowlist mode for invitation-only federation). For a community homeserver, MJOLNIR-style denylist subscription is the standard answer — you delegate spam/abuse identification to maintained denylist communities and apply the policy locally. Your sovereignty: you choose which denylists to follow.
Federated microblogging — the sibling federation protocol; same operator pattern, different surface area.
Kernel-fast VPN exit on a Sentinel — for the homeserver admin who wants to ssh-in over their own tunnel.
Donate Nordic bandwidth to the Tor network — the natural neighbour of an end-to-end encrypted homeserver in the same operator's rack.