Matrix Synapse auf einem VPS selbst hosten

Was erforderlich ist, damit ein Matrix-Synapse-Homeserver dauerhaft funktioniert

Matrix Synapse lässt sich einfach installieren und ebenso leicht vernachlässigen. Für die Installation benötigen Sie ein apt-Repository, eine Konfigurationsdatei, einen Reverse-Proxy-Block und einen DNS-Eintrag. Einen Homeserver ein Jahr lang zuverlässig zu betreiben, erfordert andere Maßnahmen: eine echte Datenbank, einen bereinigten Medienspeicher, eine Registrierung, die Fremde nicht verwenden können, und ein Backup, das beide Teile des Servers erfasst.

Diese Anleitung richtet sich an Ubuntu 24.04 LTS und installiert Synapse aus dem apt-Repository von matrix.org. Das ist die Paketquelle, die das Synapse-Projekt für Debian und Ubuntu pflegt. Die Paketversionen ändern sich alle paar Wochen. Deshalb wird hier keine Versionsnummer angegeben. Alle folgenden Pfade und Optionen stammen aus der aktuellen Synapse-Dokumentation.

Dimensionierung: Was 1 vCPU und 2 GB RAM tatsächlich leisten

Veröffentlichte Dimensionierungsangaben setzen einen Synapse-Homeserver im August 2026 häufig mit 1 vCPU und 2 GB RAM an. Für einen Fall ist das realistisch: einen privaten Server mit wenigen Benutzern, kleinen Räumen und keinen stark frequentierten öffentlichen Räumen. Die Synapse-Dokumentation weist ausdrücklich auf den anderen Fall hin. Dort heißt es: „At least 1GB of free RAM if you want to join large public rooms like #matrix:matrix.org“. Gemeint ist freier RAM zusätzlich zu dem Speicherbedarf von Python, Postgres und dem Kernel.

Ein einzelner Raum kann Ihre Dimensionierung verändern. Der Grund ist der Ablauf beim Beitritt. Wenn ein lokaler Benutzer einem Raum beitritt, wird Ihr Homeserver zu einem vollständigen Teilnehmer dieses Raums. Er empfängt jedes Ereignis von jedem anderen Server in diesem Raum, prüft die Signatur jedes Ereignisses und speichert den Raumzustand lokal. Ein großer öffentlicher Raum hat Tausende Mitglieder, die auf Hunderte Server verteilt sind. Ihr Server führt diese Verarbeitung daher kontinuierlich aus, unabhängig davon, ob Ihr Benutzer den Raum später noch einmal öffnet. Wenn der Benutzer den Raum später verlässt, wird die bereits gespeicherte Historie nicht gelöscht.

Der größte Teil des RAM von Synapse wird für Caches verwendet. Der Abschnitt caches enthält einen global_factor, der alle Caches gleichzeitig skaliert. Die Umgebungsvariable SYNAPSE_CACHE_FACTOR legt denselben Wert fest. Wenn Sie ihn erhöhen, wird mehr RAM verwendet, um Datenbankabfragen zu vermeiden. Wenn Sie ihn verringern, werden CPU-Zeit und Postgres-Ressourcen eingesetzt, um RAM zu sparen. Postgres benötigt eigenen Speicher. Auf einem System mit 2 GB konkurrieren beide daher um dieselben Megabytes.

Für einen kleinen Tarif gelten zwei praktische Regeln. Richten Sie Swap ein. Swap macht Synapse nicht schneller, verhindert aber, dass der Kernel den Prozess während eines großen Beitritts beendet. Beobachten Sie außerdem ab der ersten Woche den Speicherplatz. Der Media Store und die Tabellen für den Raumzustand wachsen ohne feste Obergrenze. Beide liegen auf der Festplatte.

Warum Postgres und warum SQLite keine Option mehr ist

Das Debian-Paket startet mit SQLite. Für den ersten Start ist das in Ordnung, für einen Server, den andere Personen verwenden, nicht. SQLite erlaubt jeweils nur einen Schreibvorgang. Federation-Verkehr und Client-Anfragen schreiben gleichzeitig. Dadurch wartet eine einfache Anfrage hinter einer langsamen, und für Ihre Benutzer wirkt es so, als würde die Anwendung zufällig für einige Sekunden hängen.

Der zweite Grund ist struktureller Natur. Die Worker-Prozesse von Synapse sind der unterstützte Weg, mehr als einen CPU-Kern zu verwenden, und Worker benötigen Postgres. Wenn Sie bei SQLite bleiben, verzichten Sie sowohl auf die Leistungssteigerung als auch auf den späteren Ausbau.

Eine spätere Migration wird unterstützt und verursacht eine Downtime. Führen Sie sie daher durch, bevor Sie Benutzer haben. Synapse liefert synapse_port_db mit. Damit wird eine SQLite-Datenbank in eine vorbereitete Postgres-Datenbank kopiert:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

Wenn Sie die Datenbank lieber in einem Container neben Synapse betreiben möchten, finden Sie die Abwägungen unter Ihre Datenbank in Docker oder auf dem Host betreiben.

Synapse unter Ubuntu 24.04 installieren

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Unter Ubuntu 24.04 gibt lsb_release -cs noble aus, und das Repository von matrix.org stellt eine noble-Suite bereit. Verwenden Sie nicht das matrix-synapse-Paket aus dem eigenen Ubuntu-Archiv. Das Synapse-Projekt rät davon ab, weil diese Builds hinter den Releases zurückliegen und bekannte Sicherheitslücken enthalten.

Das Installationsprogramm fragt nach einem Servernamen und schreibt die Antwort nach /etc/matrix-synapse/conf.d/server_name.yaml. Beantworten Sie diese Frage sorgfältig. server_name ist der Teil nach dem Doppelpunkt in jeder Benutzer-ID (@alice:example.com) und wird in jeden Raum eingebettet, den Ihr Server erstellt. Eine spätere Änderung verschiebt keine Daten: Sie erzeugt einen anderen Homeserver. Verwenden Sie Ihre reine Domain, example.com, auch wenn Synapse selbst auf matrix.example.com ausgeführt wird. Eine Delegation verbindet beide, und das ist Gegenstand des nächsten Abschnitts.

Das Paket führt Synapse als Benutzer matrix-synapse aus, speichert seine Daten unter /var/lib/matrix-synapse und liest /etc/matrix-synapse/homeserver.yaml gefolgt von jeder Datei in /etc/matrix-synapse/conf.d/. Legen Sie Ihre eigenen Einstellungen in kleinen Dateien unter conf.d ab. Paketaktualisierungen lassen diese Dateien unverändert.

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

Bei einem erfolgreichen Start werden die Listener aktiviert, anschließend bleibt der Dienst ruhig. Die systemd-Unit startet den Dienst wenige Sekunden nach jedem Beenden neu. Eine von Synapse abgelehnte Konfiguration führt daher dazu, dass die Unit in einer Start-und-Beenden-Schleife läuft. Die letzten Zeilen des Journals nennen den Schlüssel, den Synapse abgelehnt hat.

Synapse auf Postgres umstellen

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

Die Locale ist nicht nur Kosmetik. Synapse startet nicht mit einer Datenbank, die mit anderen Werten für COLLATE und CTYPE erstellt wurde, sofern Sie allow_unsafe_locale nicht in der Datenbankkonfiguration setzen. Die dokumentierte Reparatur besteht anschließend darin, die Datenbank zu dumpen und in eine korrekt erstellte Datenbank zu laden. Erstellen Sie sie gleich beim ersten Mal korrekt.

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

Verwenden Sie in allen Konfigurationsdateien genau einen Schlüssel database:. Ersetzen Sie den SQLite-Block innerhalb von homeserver.yaml, statt unter conf.d eine zweite Kopie hinzuzufügen. So ist immer eindeutig, welche Konfiguration aktiv ist. Starten Sie Synapse neu und überprüfen Sie anschließend, dass es tatsächlich Postgres verwendet:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

Eine Zahl bedeutet, dass Synapse sein Schema in dieser Datenbank erstellt hat. Ein Fehler über eine fehlende Relation bedeutet, dass Synapse weiterhin in die SQLite-Datei schreibt. Die bearbeitete Konfigurationsdatei wird dann nicht eingelesen.

Reverse Proxy, TLS und die .well-known-Dateien für die Föderation

Synapse lauscht auf Port 8008 auf einfachem HTTP und ist an localhost gebunden. TLS und der öffentliche Port gehören zu einem vorgeschalteten Reverse Proxy.

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true weist Synapse an, dem vom Proxy gesetzten Header X-Forwarded-For zu vertrauen. Ohne diese Einstellung sieht jede Client-Verbindung so aus, als käme sie von 127.0.0.1. Dadurch erkennt die Ratenbegrenzung nur einen extrem ausgelasteten lokalen Benutzer und drosselt alle gemeinsam.

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

Die Synapse-Dokumentation enthält zu diesem Block eine Warnung, die viele Menschen tagelang beschäftigt. Fügen Sie nach dem Port in proxy_pass keinen Pfad hinzu, auch kein einzelnes /. nginx kanonisiert dann die URI. Dadurch ändern sich die Bytes, die der sendende Server signiert hat. Föderationsanfragen schlagen bei der Signaturprüfung fehl, während gewöhnliche Client-Anfragen weiterhin funktionieren.

client_max_body_size muss mindestens so groß sein wie max_upload_size von Synapse. Wenn nginx den kleineren Wert verwendet, weist nginx Uploads darüber mit 413 Request Entity Too Large zurück, bevor Synapse sie überhaupt erhält. Daher gibt es keine Synapse-Logzeile, die den Fehler erklärt.

Für das Zertifikat folgen Sie Certbot und Let's Encrypt unter Ubuntu 24.04. Wenn der Proxy noch nicht feststeht, zeigt der Vergleich der Reverse Proxies, welcher Proxy die TLS-Terminierung für Sie übernimmt.

Die Delegation ermöglicht, dass server_name auf example.com bleibt, während Synapse auf matrix.example.com läuft. Stellen Sie zwei Dateien unter der reinen Domain bereit:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

Die Serverdatei teilt anderen Homeservern mit, wohin sie Föderationsverkehr senden sollen. Dadurch läuft die Föderation über 443 statt über den Standardport 8448. Die Clientdatei teilt Matrix-Clients mit, welche URL @alice:example.com bereitstellt. Der Header Access-Control-Allow-Origin ist bei der Clientdatei erforderlich, weil browserbasierte Clients sie Cross-Origin abrufen. Ohne diesen Header blockiert der Browser die Antwort, und der Client meldet, dass er Ihren Homeserver nicht finden kann.

Beide Dateien müssen über gültiges TLS direkt von example.com bereitgestellt werden. Prüfen Sie sie und anschließend, was aus dem Internet sichtbar ist:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

Der erste Befehl gibt das von Ihnen eingetragene JSON zurück. Der zweite gibt ein JSON-Objekt mit der Implementierung und ihrer Version zurück. Das bestätigt, dass der Proxy Synapse über den Föderationspfad erreicht. Prüfen Sie die Domain anschließend mit dem Matrix Federation Tester unter https://federationtester.matrix.org. Dieser verwendet denselben Weg wie ein tatsächlich verbundener entfernter Server.

Federation oder keine Federation: Treffen Sie die Entscheidung bewusst

Federation ist der Kern von Matrix und zugleich der größte Kostenfaktor. Ein federierender Homeserver akzeptiert Verbindungen von Servern, die Sie noch nie gesehen haben, empfängt deren Events, cached deren Medien und speichert den Status jedes Raums, mit dem Ihre Benutzer interagieren. Das ist eine Entscheidung für das Threat Model und kein Standardverhalten.

Aktivieren Sie Federation, wenn Ihre Benutzer Personen auf anderen Homeservern erreichen müssen oder wenn eine portable Identität der Grund für Ihre Entscheidung für Matrix ist. Aktivieren Sie Federation nicht, wenn der Server für ein Team betrieben wird und alle darauf vorhandenen Konten Ihnen gehören. Ein geschlossener Server speichert weniger, empfängt weniger und ist für Missbrauch deutlich weniger interessant.

Wenn Sie Federation einschränken statt deaktivieren möchten, verwendet Synapse eine Allowlist:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

Die Dokumentation empfiehlt außerdem, den Federation-Listener per Firewall abzusichern. Unerwünschter Traffic wird dadurch bereits im Netzwerk gestoppt und nicht erst in Python. Um Federation vollständig zu deaktivieren, entfernen Sie federation aus der Listener-Liste resources, veröffentlichen Sie /.well-known/matrix/server nicht und lassen Sie Port 8448 geschlossen.

Wenn der Grund für den Betrieb von Matrix privater Team-Chat war und Federation nie vorgesehen war, vergleichen Sie die laufenden Kosten mit den anderen self-hosted Slack-Alternativen, bevor Sie sich für Synapse entscheiden. Rocket.Chat mit Docker Compose ermöglicht Team-Chat auf einer kleineren Maschine, weil es niemals den Raumstatus einer anderen Organisation speichern muss.

Das Medien-Repository füllt die Festplatte unbemerkt

Dateien, die Ihre eigenen Benutzer hochladen, bleiben dauerhaft auf Ihrer Festplatte. Dateien, die Benutzer auf anderen Homeservern veröffentlichen, werden auf Ihre Festplatte abgerufen und dort zwischengespeichert, sobald einer Ihrer Clients sie anzeigt. Synapse erzeugt außerdem Miniaturansichten für Bilder. Dadurch werden aus einem Foto mehrere Dateien. Standardmäßig läuft nichts davon ab.

Ermitteln Sie den Speicherort und messen Sie dessen Größe:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

Messen Sie den Pfad, den Ihre eigene Konfiguration ausgibt. Das Debian-Paket speichert die Synapse-Daten unter /var/lib/matrix-synapse. Das Repository befindet sich daher normalerweise dort. Legen Sie anschließend in conf.d eine Aufbewahrungsrichtlinie fest:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Lesen Sie diese beiden Zeilen sorgfältig. Sie definieren unterschiedliche Arten von Einstellungen. remote_media_lifetime lässt einen Cache ablaufen. Alles, was dadurch gelöscht wird, kann erneut von dem Server abgerufen werden, auf dem die Datei verwaltet wird. local_media_lifetime löscht die Uploads Ihrer eigenen Benutzer dauerhaft, sobald sie dieses Alter erreicht haben. Ein Team, das Dokumente im Chat teilt und sie im nächsten Jahr noch benötigt, verliert diese Dateien. Viele Server setzen nur den Wert für entfernte Medien.

Für eine einmalige Bereinigung erwartet die Admin-API einen Unix-Zeitstempel in Millisekunden:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache löscht zwischengespeicherte entfernte Medien, auf die vor diesem Zeitstempel zuletzt zugegriffen wurde. POST /_synapse/admin/v1/media/delete?before_ts=<ms> löscht lokale Medien nach derselben Regel. Führen Sie zuerst die Bereinigung der entfernten Medien aus und messen Sie anschließend erneut. Auf einem föderierenden Server ist der Cache für entfernte Medien normalerweise der größere Anteil.

Zwei Einstellungen beeinflussen denselben Speicherplatz. max_upload_size begrenzt den Umfang eines einzelnen Uploads und muss mit client_max_body_size in nginx übereinstimmen. url_preview_enabled: true veranlasst Ihren Server, entfernte Seiten abzurufen, damit Clients Link-Vorschauen anzeigen können. Dadurch werden Bandbreite verbraucht und Miniaturansichten von Inhalten gespeichert, die niemand auf Ihren Server hochgeladen hat.

Registrierung schließen, bevor jemand Ihren Homeserver findet

Scanner finden einen offenen Homeserver innerhalb weniger Tage. Sobald jeder Konten anlegen kann, wird Ihr Server in jedem Raum, mit dem er föderiert, zur Spamquelle. Die Administratoren auf der anderen Seite blockieren dann Ihre gesamte Domain. Dieser Reputationsschaden bleibt über die Bereinigung hinaus bestehen, weil die Sperrlisten manuell gepflegt werden.

Synapse ist standardmäßig geschlossen. enable_registration ist standardmäßig auf false gesetzt und registration_requires_token standardmäßig auf false. Synapse startet außerdem nicht mit aktivierter Registrierung und ohne Verifizierungsschritt, sofern Sie nicht zusätzlich enable_registration_without_verification: true setzen. Diese Verweigerung ist beabsichtigt. Aktivieren Sie die Option daher nicht, nur um einen Startfehler zu beseitigen.

Erstellen Sie die gewünschten Konten manuell:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

Das Programm fragt nach dem Benutzernamen, dem Passwort und danach, ob das Konto ein Serveradministrator ist. Es liest registration_shared_secret aus der Konfiguration, die Sie mit -c übergeben. Wenn gemeldet wird, dass kein Shared Secret gefunden werden kann, geben Sie mit -c die Datei an, die das Secret enthält.

Wenn das manuelle Erstellen von Konten nicht mehr skaliert, sind Registrierungstokens die passende Zwischenlösung. Ein Token ist eine Zeichenfolge, die ein neuer Benutzer bei der Registrierung angeben muss. Für jedes Token lässt sich festlegen, wie oft es verwendet werden darf:

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

Lassen Sie token im Body weg. Synapse generiert dann ein Token und gibt es zurück. GET /_synapse/admin/v1/registration_tokens listet die aktiven Tokens auf. Beide Aufrufe benötigen das Access-Token eines Serveradministratorkontos. Dieses erhalten Sie, indem Sie sich mit dem zuvor erstellten Administratorkonto anmelden.

Eine Organisation, die Konten bereits an anderer Stelle verwaltet, kann vollständig auf lokale Passwörter verzichten. Synapse kann die Anmeldung an einen OIDC-(OpenID-Connect-)Provider delegieren, beispielsweise an Authentik als selbst gehosteten SSO-Provider. Ein- und Austritte werden dann zentral an einer Stelle verwaltet.

Ein Backup, mit dem sich der Server tatsächlich wiederherstellen lässt

Ein Synapse-Backup besteht aus drei Teilen. Fehlt einer davon, wird ein Server wiederhergestellt, den niemand verwenden kann.

• Die Postgres-Datenbank mit allen Events, Konten und Räumen.
• Das Verzeichnis des Media Store mit allen hochgeladenen Dateien.
• /etc/matrix-synapse mit Ihrer Konfiguration und dem Signaturschlüssel des Servers.

Der Signaturschlüssel wird häufig vergessen. Ihr Homeserver signiert damit Events. Remoteserver prüfen Events anhand des zugehörigen öffentlichen Schlüssels. Führen Sie grep signing_key_path /etc/matrix-synapse/homeserver.yaml aus, um den Speicherort Ihres Schlüssels anzuzeigen. Wenn Sie ihn verlieren, stellen Sie einen Server wieder her, der nicht nachweisen kann, dass er derselbe Server ist, den Ihre Räume bereits kennen.

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

Sichern Sie zuerst die Datenbank und kopieren Sie anschließend den Media Store. Mediendateien werden einmal geschrieben und über ihre ID referenziert. Eine Kopie der Mediendateien nach dem Dump kann daher nur zusätzliche Dateien enthalten, niemals fehlende. In der umgekehrten Reihenfolge kann die wiederhergestellte Datenbank auf eine Datei verweisen, die Ihr Backup nicht erfasst hat.

Übertragen Sie alle drei Teile vom VPS an einen externen Speicherort. restic mit Off-Site-Snapshots eignet sich dafür gut, weil der Media Store den größeren Teil ausmacht und sich zwischen den Durchläufen kaum ändert. Durch Deduplizierung bleibt jeder Snapshot klein.

Üben Sie anschließend die Wiederherstellung. Ein Backup, das Sie noch nie wiederhergestellt haben, ist nur eine Annahme. Erstellen Sie einen zweiten VPS und installieren Sie dasselbe Paket. Stellen Sie die Konfiguration wieder her. Erstellen Sie die Datenbank mit derselben Codierung und Locale. Importieren Sie den Dump mit pg_restore. Kopieren Sie den Media Store zurück und melden Sie sich an. Notieren Sie, wie lange der Vorgang gedauert hat. Diese Zeit ist Ihre tatsächliche Wiederherstellungszeit.

Wenn die Zustandstabellen wachsen: Komprimierung

Synapse speichert den Raumzustand als Zustandsgruppen. Auf einem föderierenden Server wird state_groups_state häufig zum größten Objekt in der Datenbank. Messen Sie, bevor Sie Änderungen vornehmen:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

Wenn diese eine Tabelle den größten Teil Ihrer Datenbank ausmacht, stellt das Projekt dafür einen Kompressor bereit: rust-synapse-compress-state. Er schreibt die Hierarchie der Zustandsgruppen in weniger Zeilen um, ohne die Bedeutung des Zustands eines Raums zu ändern. Das Tool wird mit Rust erstellt:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c gibt an, wie viele Zustandsgruppen gleichzeitig verarbeitet werden. -n gibt an, wie viele dieser Blöcke dieser Lauf verarbeitet. Der automatische Kompressor speichert den Fortschritt. Der nächste Lauf setzt daher an dieser Stelle fort. Dadurch kann der Vorgang sicher geplant werden. In der Dokumentation steht, dass die Änderungen in Transaktionen auf Tabellen angewendet werden, die nur Datensätze anhängen. Der Vorgang kann daher ausgeführt werden, während Synapse läuft. Erstellen Sie trotzdem vor dem ersten Lauf ein Datenbank-Backup.

Ein Detail von Postgres überrascht an dieser Stelle viele. Das Löschen von Zeilen gibt den Speicherplatz an Postgres zur Wiederverwendung zurück, nicht an das Dateisystem. Daher wird sich df nach einer umfangreichen Komprimierung möglicherweise überhaupt nicht verkleinern. VACUUM FULL gibt den Speicherplatz an das Dateisystem zurück. Der Vorgang setzt außerdem eine exklusive Sperre auf der Tabelle voraus und benötigt ungefähr so viel freien Speicherplatz wie die Tabelle groß ist. Planen Sie ihn daher als Wartungsmaßnahme und führen Sie ihn nicht spontan aus.

Prüfungen, die zeigen, dass der Server fehlerfrei arbeitet

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

Fehlerfrei bedeutet, dass die Unit aktiv ist und nicht neu gestartet wird, die Delegationsdatei Ihren m.server-Wert zurückgibt, der Federation-Versionsendpunkt JSON zurückgibt und die beiden Größenwerte mit denen des letzten Monats verglichen werden können. Die Größenprüfung wird häufig übersprungen. Ein voller Datenträger ist jedoch der Fehler, der einen Synapse-Server ohne Vorwarnung außer Betrieb setzt: Ein volles Dateisystem verhindert, dass Postgres schreibt, und Synapse schlägt anschließend bei jeder Anfrage fehl, die auf die Datenbank zugreift.

FAQ

Wie viel RAM benötigt ein Matrix-Synapse-Server?

Für einen privaten Homeserver mit wenigen Benutzern, kleinen Räumen und ohne große öffentliche Räume sind 2 GB ausreichend. Das empfehlen die meisten veröffentlichten Größenempfehlungen im August 2026. Die Synapse-Dokumentation fordert zusätzlich zu den übrigen Anforderungen mindestens 1 GB freien RAM, wenn Ihre Benutzer großen öffentlichen Räumen wie #matrix:matrix.org beitreten, weil Ihr Server dann den Zustand dieses Raums speichert und seinen Datenverkehr kontinuierlich verarbeitet. Aktivieren Sie bei einem Tarif mit 2 GB zusätzlich Swap, damit der Kernel den Prozess nicht beendet, wenn ein großer Beitritt kurzfristig viel Speicher benötigt.

Muss ich PostgreSQL statt SQLite verwenden?

Ab mehr als einer Handvoll Benutzern: ja. SQLite erlaubt jeweils nur einen Schreibvorgang. Unter Last blockieren sich dadurch Federation-Datenverkehr und Client-Anfragen gegenseitig, und Anfragen hängen teilweise mehrere Sekunden. Die Worker-Prozesse von Synapse sind die unterstützte Möglichkeit, mehr als einen CPU-Kern zu verwenden, und benötigen Postgres. Eine spätere Migration ist mit synapse_port_db möglich und verursacht Ausfallzeit. Erstellen Sie die Datenbank daher mit --encoding=UTF8 --locale=C --template=template0, bevor Sie Benutzer anlegen.

Warum wächst der Speicherverbrauch meines Synapse-Servers ständig?

Ein Verzeichnis und eine Tabelle sind dafür verantwortlich. Der Media Store behält jede Datei, die in Räume hochgeladen wird, in denen Ihr Server Mitglied ist. Dazu gehören auch zwischengespeicherte Kopien von Medien entfernter Benutzer und erzeugte Vorschaubilder. Nichts läuft ab, bis Sie media_retention konfigurieren. Die Tabelle state_groups_state wächst auf einem föderierten Server mit dem Raumzustand, und rust-synapse-compress-state reduziert sie. Messen Sie beides mit du -sh in Ihrem media_store_path sowie mit SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));, bevor Sie entscheiden, welchen Bereich Sie bearbeiten.

Wie verhindere ich, dass sich Fremde auf meinem Homeserver registrieren?

Belassen Sie enable_registration auf dem Standardwert false und erstellen Sie Konten mit register_new_matrix_user. Wenn dieses Verfahren nicht mehr skaliert, setzen Sie enable_registration: true zusammen mit registration_requires_token: true und verteilen Sie über POST /_synapse/admin/v1/registration_tokens/new erstellte Tokens. Setzen Sie enable_registration_without_verification: true nicht nur deshalb, um die Startverweigerung von Synapse zu unterdrücken. Ein offener Homeserver wird sonst zu einer Spamquelle, und andere Administratoren reagieren möglicherweise, indem sie Ihre gesamte Domain blockieren.

Sollte mein Homeserver föderieren?

Federation ist eine Entscheidung über die Erreichbarkeit und kein Standard. Aktivieren Sie Federation, wenn Ihre Benutzer Personen auf anderen Homeservern erreichen müssen. Deaktivieren Sie sie, wenn der Server nur für ein Team bereitsteht. Ein Server ohne Federation speichert weniger, empfängt weniger Datenverkehr und zieht deutlich weniger Missbrauch an. Als Zwischenlösung beschränkt federation_domain_whitelist die Federation auf benannte Partnerdomains. Die Synapse-Dokumentation empfiehlt außerdem, den Federation-Listener mit einer Firewall abzusichern, statt sich allein auf diese Prüfung auf Anwendungsebene zu verlassen.