Synapse

Last reviewed Sep 13, 2026 · 862 words

Synapse is the Matrix server that works with everything, and it pays for that with memory and disk. The install is a single container and one YAML file; the operating cost is a PostgreSQL database that grows every time a user joins a large room, a federation that must stay reachable, and a release train you must ride because Matrix clients and servers evolve together. The 1 GB minimum is real for day one. Six months in, with a couple of big public rooms joined, 3 to 4 GB of RAM and a database past 10 GB is normal. For a family or a small community that is a fair price; for one person who wants encrypted chat, it is probably not.

What you are actually running

Matrix is the protocol: federated rooms, end-to-end encryption handled in the clients, an open spec anyone can implement. Synapse is the original server, written in Python by the team that designed the protocol, and now maintained by Element under AGPL-3.0 after they took it over and relicensed it. Your users pick a client (Element Web is the default, and there are a dozen others) and point it at your server. Rooms your users join on other servers get replicated to yours, which is where the disk goes.

Bridges are the other reason people run Synapse. The mautrix family connects a Matrix room to WhatsApp, Signal, Telegram, Discord or Slack, so a household can keep one app for everything. Each bridge is a separate service with its own upkeep; count each as half a Synapse in effort.

Three settings that decide whether you have a server or an incident

Generate a config, then run it:

docker run -it --rm -v ./data:/data \
  -e SYNAPSE_SERVER_NAME=example.com \
  -e SYNAPSE_REPORT_STATS=no \
  ghcr.io/element-hq/synapse:latest generate

Edit data/homeserver.yaml, then start the container with port 8008 behind your reverse proxy. server_name is the part after the colon in every user ID and it is permanent; you cannot rename a Matrix server without starting over, so pick example.com rather than matrix.example.com. Delegation lets example.com serve the API from matrix.example.com by publishing /.well-known/matrix/server at the root domain, which keeps the short name without running Synapse on your main web host. And use PostgreSQL from day one; SQLite exists for testing, and migrating a live SQLite Synapse to Postgres later is a slow, error-prone weekend. The case for Postgres as the household database applies here more than anywhere.

enable_registration is false by default. Leave it that way and create users with register_new_matrix_user or the admin API. If you must open it, registration_requires_token keeps the spam accounts out.

Disk is the recurring maintenance

Two things grow: media (every image and file sent in any room your users are in, including remote rooms) and room state. Set media_retention with remote_media_lifetime at 14 or 30 days so cached media from other servers expires; local media stays. For state, the rust-synapse-compress-state tool exists because large rooms accumulate redundant state groups, and running it on the biggest rooms every few months has recovered about a third of the database for me. The admin API can purge history and forget rooms nobody is in any more. None of this is automatic, and a Synapse nobody prunes becomes the largest database in the homelab.

Beyond a few hundred active users Synapse splits into workers (separate processes for federation, media and sync), which is where it stops being a homelab project and becomes an ops job. The community playbook matrix-docker-ansible-deploy is the sane way to run that shape, and I would use it even for a single-container install because it gets delegation and the reverse proxy right.

When a lighter server is the better pick

The Rust servers descended from Conduit run the same protocol in a fraction of the memory. Continuwuity and Tuwunel are the actively maintained forks, with an embedded database and no PostgreSQL, and for a single household they fit better than Synapse. What they lack is the long tail: some admin APIs, some bridge and appservice edge cases, and the guarantee that whatever a new client does, the reference server supports it first. My split is 1 to 10 users who want private encrypted chat with a bridge or two, use Continuwuity; a community of 50 or more, wide federation, or anything where "works with everything" outranks memory, Synapse. The Matrix category page lists the rest.

What I'd do

Synapse in Docker with PostgreSQL, server_name set to the bare domain with well-known delegation, registration closed, remote media expiring at 14 days, and the state compressor on a quarterly reminder. Element Web alongside it on its own hostname. Budget 2 GB of RAM to start and watch it. If that reads as more than you wanted to sign up for, it is; run Continuwuity instead and keep the door open to Synapse later, because the protocol is the same and your users would not notice the switch.