Matrix-Server selbst hosten: Synapse auf Proxmox, VPS oder Docker

Warum einen eigenen Matrix-Server betreiben?

Wer Element als Messenger im Unternehmen einsetzt, steht irgendwann vor einer grundsätzlichen Entscheidung: Reicht der öffentliche matrix.org-Server – oder braucht es eine eigene Instanz?

Für viele Teams ist die Antwort klar. Ein eigener Homeserver bedeutet volle Kontrolle über Daten, Nutzer und Zugriffsrechte. Keine Abhängigkeit von Dritten, kein Vertrauen auf fremde Infrastruktur. Und für Unternehmen mit DSGVO-Anforderungen ist Selbsthosting oft der einzig gangbare Weg.

Dieser Artikel zeigt, welche Homeserver-Implementierungen es gibt, was Sie an Infrastruktur brauchen und wie ein Setup in der Praxis aussieht.

Welcher Homeserver? Synapse, Dendrite oder Tuwunel

Matrix ist ein offenes Protokoll – es gibt mehrere Server-Implementierungen, die es umsetzen. Die drei relevantesten im Überblick:

Synapse – der Standard

Synapse ist die Original-Implementierung, geschrieben in Python. Mit einem Marktanteil von über 85 Prozent ist es die mit Abstand verbreitetste Option. Synapse ist ausgereift, unterstützt alle Matrix-Features und bietet Enterprise-Funktionen wie Single Sign-On, Audit-Logs und Worker-basierte Skalierung.

Der Nachteil: Synapse braucht Ressourcen. Für einen produktiven Betrieb sollten Sie mindestens 2 bis 4 GB RAM einplanen, PostgreSQL ist Pflicht – SQLite führt bei Synapse unweigerlich zu Datenbankkorruption.

Dendrite – die zweite Generation

Dendrite wurde als leichtgewichtige Alternative in Go entwickelt. Es verbraucht weniger RAM und skaliert über eine Microservices-Architektur. Allerdings befindet sich Dendrite seit 2025 im Maintenance-Mode – es gibt nur noch Security-Fixes, keine neuen Features. Für bestehende Installationen eine solide Basis, für neue Projekte aber nicht mehr die erste Wahl.

Tuwunel – der Newcomer aus Rust

Tuwunel ist der offizielle Nachfolger von Conduwuit und in Rust geschrieben. Das Projekt wird von der Schweizer Regierung gesponsert, wo es produktiv für Bürger eingesetzt wird. Mit über 1.600 GitHub-Stars und regelmäßigen Releases hat es sich schnell etabliert.

Der größte Unterschied zu Synapse: Tuwunel nutzt RocksDB als eingebettete Datenbank. Kein PostgreSQL nötig, keine externe Datenbankinstanz, keine SQL-Administration. Das vereinfacht das Setup erheblich. Die Ressourceneffizienz ist beeindruckend – unter 1 GB RAM, kaum messbare CPU-Last.

Authentifizierung unterstützt Tuwunel über LDAP, JWT und seit v1.5.0 auch experimentell über OIDC. Die OIDC-Anbindung funktioniert bisher mit GitHub als Identity Provider, weitere Anbieter wie Keycloak oder Authentik befinden sich in Arbeit.

Was Tuwunel gut kann: Einfaches Deployment als Single Binary oder Docker Container, Federation, Sliding Sync, Bridges über die Appservice-API, Administration über einen eingebauten Admin-Raum via Matrix-Chat.

Was Tuwunel nicht kann: Keine horizontale Skalierung über Workers, kein REST-Admin-API (nur Chat-basiert), keine Migration bestehender Synapse-Daten. Wer von Synapse wechseln will, muss Nutzer neu anlegen und Räume neu erstellen – verschlüsselte Nachrichtenhistorie geht dabei verloren.

Für Neuinstallationen kleiner Teams ist Tuwunel die spannendste Option. Für bestehende Synapse-Installationen kommt ein Wechsel derzeit nicht in Frage.

Empfehlung

Was braucht man? Technische Voraussetzungen

Ein Matrix-Homeserver ist kein komplexes Rechenzentrum-Projekt. Die Grundanforderungen sind überschaubar:

Server: Ein VPS mit 2 bis 4 GB RAM für Synapse, 1 GB für Tuwunel. Zwei CPU-Kerne reichen für den Anfang.

Domain: Eine eigene Domain mit korrekt konfigurierten DNS-Einträgen. Matrix nutzt SRV-Records für die Server-zu-Server-Kommunikation (Federation).

Reverse Proxy: Nginx oder Caddy vor dem Homeserver, um HTTPS auf Port 443 zu terminieren. Caddy hat den Vorteil, dass es Let’s-Encrypt-Zertifikate automatisch verwaltet.

Datenbank: PostgreSQL für Synapse – zwingend. Tuwunel bringt eine eingebettete Datenbank mit.

TLS-Zertifikat: Let’s Encrypt, automatisiert über Caddy oder Certbot.

Container-Runtime: Docker und Docker Compose als empfohlener Weg. Deutlich einfacher als manuelle Installation.

Wo den Server betreiben?

Klassische VPS-Anbieter in der EU

Für DSGVO-konforme Unternehmen kommen nur EU-Standorte in Frage. Bewährte Optionen:

Hetzner Cloud ist für viele die erste Wahl: Rechenzentren in Falkenstein und Nürnberg, ein CX22 mit 4 GB RAM und 40 GB SSD kostet unter 5 Euro im Monat. Gutes Preis-Leistungs-Verhältnis und solide API.

Hostinger VPS bietet günstige Einstiegstarife mit EU-Rechenzentren und einem benutzerfreundlichen Panel. Für Teams, die weniger Erfahrung mit Linux-Administration haben, ein niedrigschwelliger Einstieg.

netcup und IONOS sind weitere deutsche Alternativen mit guter Infrastruktur und AVV-Möglichkeit.

Proxmox: Der Weg über eigene Hardware

Wer bereits eigene Server-Hardware betreibt – etwa in einem kleinen Rechenzentrum oder im Büro – kann Matrix auch auf einer Proxmox-Umgebung deployen. Proxmox ist eine Open-Source-Virtualisierungsplattform, die sich gut für den Betrieb von LXC-Containern oder VMs eignet.

Der Vorteil: Volle physische Kontrolle über die Hardware, keine monatlichen Hosting-Kosten außer Strom und Internet. Ideal für Unternehmen, die ohnehin eigene Infrastruktur betreiben und die Daten nicht aus dem Haus geben wollen.

Der Nachteil: Sie sind selbst für Verfügbarkeit, Backups und Netzwerk-Sicherheit verantwortlich. Ohne Erfahrung in der Systemadministration ist das kein sinnvoller Einstieg.

Managed Hosting: Wenn eigene IT fehlt

Nicht jedes Team hat die Kapazität für Serverbetrieb. Zwei seriöse Managed-Anbieter:

etke.cc ist der einzige vollständig FOSS-basierte Matrix-Hosting-Dienst. Keine Per-User-Kosten, über 700 installierte Server, betrieben von aktiven Community-Mitgliedern. Dazu gibt es optionale Addons wie Bots und Bridges.

Element Matrix Services (EMS) ist das offizielle Managed-Angebot von Element selbst. Multi-Tenant-Hosting ab 5 Nutzern, dediziertes Hosting ab 500 Nutzern mit Enterprise-Features.

Setup mit Docker Compose

Der schnellste Weg zu einem laufenden Synapse-Server führt über Docker Compose. Das folgende Beispiel zeigt die Grundstruktur – Synapse, PostgreSQL und Caddy als Reverse Proxy.

Konfiguration generieren

Bevor Sie den Server starten, muss Synapse eine Konfigurationsdatei erzeugen. Ersetzen Sie matrix.example.com durch Ihre Domain:

docker run -it --rm \
  -v ./synapse-data:/data \
  -e SYNAPSE_SERVER_NAME=matrix.example.com \
  -e SYNAPSE_REPORT_STATS=no \
  matrixdotorg/synapse:latest generate

Docker Compose

services:
  synapse:
    image: matrixdotorg/synapse:latest
    restart: unless-stopped
    volumes:
      - ./synapse-data:/data
    environment:
      - SYNAPSE_CONFIG_PATH=/data/homeserver.yaml
    depends_on:
      - db
    ports:
      - "8008:8008"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: synapse
      POSTGRES_USER: synapse
      POSTGRES_PASSWORD: changeme_strong_password
      POSTGRES_INITDB_ARGS: "--encoding=UTF8 --lc-collate=C --lc-ctype=C"
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "8448:8448"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy-data:/data
      - ./caddy-config:/config

Caddyfile

matrix.example.com {
    reverse_proxy /_matrix/* synapse:8008
    reverse_proxy /_synapse/* synapse:8008
}

matrix.example.com:8448 {
    reverse_proxy synapse:8008
}

homeserver.yaml anpassen

Nach dem Generieren der Konfiguration müssen Sie die Datenbankverbindung von SQLite auf PostgreSQL umstellen. Öffnen Sie synapse-data/homeserver.yaml und ersetzen Sie den database-Block:

database:
  name: psycopg2
  args:
    user: synapse
    password: changeme_strong_password
    database: synapse
    host: db
    cp_min: 5
    cp_max: 10

Starten und ersten Nutzer anlegen

docker compose up -d

# Ersten Admin-Nutzer erstellen
docker compose exec synapse register_new_matrix_user \
  http://localhost:8008 \
  -c /data/homeserver.yaml \
  -u admin -p sicheres_passwort --admin

Danach können Sie sich mit dem Element-Client unter https://matrix.example.com anmelden.

Alternative: Tuwunel mit Docker Compose

Wer statt Synapse lieber Tuwunel einsetzen möchte, profitiert von einem deutlich schlankeren Setup. Keine PostgreSQL-Instanz, keine Konfigurationsgenerierung – ein Volume für die RocksDB-Datenbank und zwei Umgebungsvariablen reichen:

services:
  tuwunel:
    image: ghcr.io/matrix-construct/tuwunel:latest
    restart: unless-stopped
    environment:
      - TUWUNEL_SERVER_NAME=matrix.example.com
      - TUWUNEL_ALLOW_REGISTRATION=false
    volumes:
      - ./tuwunel-data:/var/lib/tuwunel
    ports:
      - "8008:8008"

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "8448:8448"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy-data:/data
      - ./caddy-config:/config

Das Caddyfile ist identisch zum Synapse-Setup – nur synapse:8008 wird zu tuwunel:8008. Die Administration erfolgt nach dem Start über einen automatisch erstellten Admin-Raum im Matrix-Client. Dort können Sie mit !admin-Befehlen Nutzer anlegen, Räume verwalten und den Server konfigurieren.

Für weiterführende Konfiguration unterstützt Tuwunel eine tuwunel.toml-Datei oder Umgebungsvariablen mit dem Prefix TUWUNEL_. Die minimale Konfiguration besteht aus server_name und database_path.

DNS-Einträge für Federation

Damit andere Matrix-Server Ihren Homeserver finden können, brauchen Sie die richtigen DNS-Einträge:

A-Record:     matrix.example.com → IP-Adresse
SRV-Record:   _matrix._tcp.example.com → 0 10 8448 matrix.example.com

Alternativ können Sie eine .well-known-Datei unter Ihrer Domain bereitstellen. Das ist oft einfacher als SRV-Records und funktioniert genauso zuverlässig.

DSGVO und Federation: Was Sie beachten müssen

Federation ist das Herzstück von Matrix – aber sie hat Konsequenzen für den Datenschutz.

Das Federation-Problem

Wenn ein Nutzer Ihres Servers einem Raum auf einem fremden Server beitritt, werden Nachrichten auf beiden Servern gespeichert. Das gilt auch für Metadaten: Wer wann mit wem kommuniziert hat. Sie haben keine Kontrolle darüber, wo diese Kopien landen – es sei denn, Sie schränken Federation ein.

Optionen für Unternehmen

Federation komplett abschalten: Für rein interne Kommunikation die sicherste Option. Ihr Server kommuniziert nur mit sich selbst. In der homeserver.yaml setzen Sie dafür federation_domain_whitelist auf eine leere Liste.

Federation einschränken: Sie können gezielt festlegen, mit welchen Servern Ihr Homeserver föderieren darf – etwa nur mit Partnern oder Kunden, die ebenfalls einen eigenen Server betreiben.

Federation offen lassen: Maximale Erreichbarkeit, aber weniger Kontrolle über Datenflüsse. Für Unternehmen mit personenbezogenen Daten nur nach sorgfältiger Prüfung empfehlenswert.

Weitere DSGVO-Pflichten

• AVV mit dem Hosting-Provider abschließen – bei EU-Anbietern in der Regel standardmäßig verfügbar
• Löschanfragen nach Art. 17 DSGVO umsetzen – Synapse unterstützt das, aber bei föderierten Räumen kann die Löschung auf fremden Servern nicht garantiert werden
• Registrierung absichern – ohne CAPTCHA oder manuelle Freigabe können Spammer Accounts anlegen und das Federation-Netzwerk missbrauchen

Betrieb und Wartung

Ein laufender Matrix-Server braucht regelmäßige Aufmerksamkeit – aber nicht viel.

Backups

PostgreSQL-Dumps täglich automatisieren, entweder per Cronjob oder über ein Backup-Tool des Hosters. Vergessen Sie nicht den Media-Store: Hochgeladene Dateien und Bilder liegen im synapse-data/media_store-Verzeichnis.

Updates

Synapse-Updates erscheinen regelmäßig. Mit Docker ist ein Update ein Dreizeiler:

docker compose pull
docker compose down
docker compose up -d

Changelog vorher lesen – gelegentlich gibt es Breaking Changes, die Anpassungen an der Konfiguration erfordern.

Monitoring

Synapse bietet einen Prometheus-Endpunkt für Metriken. Für kleine Installationen reicht aber auch ein einfacher Health-Check per HTTP auf /_matrix/client/versions.

Kosten

Der laufende Betrieb ist überschaubar: 5 bis 20 Euro pro Monat für einen VPS bei einem EU-Anbieter. Bei Proxmox-Eigenhosting fallen nur Strom- und Internetkosten an.

Selbsthosting oder Managed? Eine Entscheidung

Selbsthosting lohnt sich, wenn Sie IT-Kompetenz im Team haben, volle Kontrolle brauchen oder bereits eigene Infrastruktur betreiben.

Managed Hosting ist besser, wenn Sie schnell starten wollen, kein Admin-Personal haben oder sich nicht um Updates und Backups kümmern möchten.

Nächste Schritte

1. Serverwahl treffen: Synapse für umfangreiche Setups, Tuwunel für ressourcenschonende Installationen
2. Infrastruktur bereitstellen: VPS bei einem EU-Anbieter oder bestehende Proxmox-Umgebung nutzen
3. Docker Compose aufsetzen: Mit der Konfiguration aus diesem Artikel als Startpunkt
4. Element-Client verbinden und erste Nutzer anlegen
5. Federation-Strategie festlegen: Offen, eingeschränkt oder geschlossen
6. Backup-Strategie einrichten – bevor der erste produktive Nutzer online geht

Weiterführende Ressourcen:

• Matrix.org Server-Dokumentation
• Synapse Installation Guide
• Tuwunel auf GitHub
• Tuwunel Docker-Deployment
• etke.cc – Managed Matrix Hosting
• Element Matrix Services
• Matrix Server Comparison