Self-Hosting Matrix Synapse and Its Bridges

Most group chat lives inside walled gardens where your message history, members, and moderation policies answer to a corporate server. Matrix is an open, federated protocol for real-time communication, and Synapse is its reference homeserver. Self-hosting Synapse gives you an encrypted chat room on your own domain that can still talk to the rest of the Matrix network — and, through bridges, to Discord and WhatsApp.

The appeal is durable ownership of your communication layer. Rooms, history, file attachments, and moderation live on servers you run, while federation keeps you connected to the wider community. You are not locked into a proprietary timeline or a fragile API, because the protocol is open and interoperable.

Synapse is more demanding than the typical self-hosted app, so this guide walks through an honest, production-minded deployment, federation basics, and bridging. It pairs naturally with the VPS you already run other services on.

What Synapse Provides

• E2E-encrypted private rooms using the Olm/Megolm protocol.
• Federation: your rooms interoperate with any other homeserver on the Matrix network.
• Bridges that join your rooms to Discord, Slack, or WhatsApp.
• Full control over moderation, retention, and who can register.

The trade-off is operational: a busy homeserver needs a real database and some care, so Synapse is a middle-weight service rather than a throwaway container.

Deploying Synapse With Compose

Synapse needs a config, a Postgres database, and the homeserver service. Generate a config first:

docker run --rm -v "$(pwd)/data:/data"   -e SYNAPSE_SERVER_NAME=matrix.example.com   -e SYNAPSE_REPORT_STATS=no   matrixdotorg/synapse:latest generate

On Windows PowerShell, replace the mount with -v "C:/path/to/data:/data". That writes homeserver.yaml and signing keys into ./data. Then bring up the stack:

services:
  synapse:
    image: matrixdotorg/synapse:latest
    container_name: synapse
    environment:
      - SYNAPSE_SERVER_NAME=matrix.example.com
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8008:8008"
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=synapse
      - POSTGRES_USER=synapse
      - POSTGRES_PASSWORD=secret
    volumes:
      - ./db:/var/lib/postgresql/data
    restart: unless-stopped

Edit homeserver.yaml to point the database at the db host and set federation port 8448 if you want legacy federation. Restart after config changes.

Federation and DNS

For other homeservers to reach yours, Matrix uses SRV lookups on the _matrix subdomain. Publish:

_matrix._tcp.example.com.  SRV  10 10 8448 matrix.example.com.
matrix.example.com.        A    203.0.113.10

This tells the federation to find your server at port 8448 on matrix.example.com. Open that port in your firewall and terminate TLS on the homeserver with a reverse proxy that also forwards port 8448.

Without these records, your server works for local users but cannot federate, and the failure is silent: clients on other homeservers simply cannot reach you. Verify federation once with the small tool config.addons.matrix.org/echo or by joining a public room from a second account on a different homeserver. Getting this right before you announce the server to anyone saves a confusing debugging session.

Bridging to the Outside

Bridges let Matrix rooms talk to Discord and WhatsApp. The appservice approach is standard: install the bridge, register it with Synapse as an application service, and get a token:

# after configuring a bridge, register it once:
docker exec synapse register_new_matrix_user   -u bridge-bot -p a-secure-password -c /data/homeserver.yaml

Once the bridge is configured and its appservice YAML is listed under app_service_config_files in homeserver.yaml, restart Synapse and join the bridge room to mirror a Discord or WhatsApp conversation into Matrix.

Bridges are the killer feature for real adoption, because they let you keep the room where your friends already are while storing the actual conversation history on your own server. The Matrix copy is complete and searchable even if the bridged platform later restricts access, and you can keep chatting when a platform hiccups. Plan to run each bridge as its own container so one misbehaving bridge does not take down the homeserver.

Takeaway

Self-hosting Synapse puts your encrypted messaging, history, and moderation on your own domain while staying federated and bridgeable to the mainstream chat apps. It is a heavier service, so give it a dedicated instance rather than stacking it on a tiny box.

A 2 GB Ubuntu VPS on Netbay with SSD storage gives Synapse room to federate and bridge cleanly — deploy in under 60 seconds at netbayhosts.in.