Bei Echtzeitkommunikation sind Unternehmen häufig besonders stark von externen Software-as-a-Service-Anbietern (SaaS) abhängig. Chatverläufe, Dateianhänge, Nutzerverzeichnisse und interne Unterhaltungen liegen möglicherweise auf der Infrastruktur von Microsoft, Slack, Discord oder anderen Drittanbietern. Für Teams, die mehr Kontrolle darüber haben möchten, wo ihre Kommunikationsdaten gespeichert werden und wie ihre Messaging-Infrastruktur betrieben wird, bietet Matrix eine offene Alternative.
Synapse ist die am weitesten verbreitete Homeserver-Implementierung für Matrix. Die Software stellt die serverseitige Infrastruktur für Matrix-Nutzer, Räume, Nachrichten, Föderation, Authentifizierung und Medienspeicherung bereit. Synapse wird von Element entwickelt und lässt sich auf der eigenen Infrastruktur hosten.
In Kombination mit einem Matrix-Client wie Element können Unternehmen damit eine vollständige Chatplattform betreiben und gleichzeitig mit Nutzern auf anderen Matrix-Servern kommunizieren.
Projektinformationen zu Synapse:
Name: Synapse
URL: https://element-hq.github.io/synapse/
Lizenz: AGPLv3 oder Element Commercial License
Protokoll: Matrix
Programmiersprache: Python/Twisted mit Rust components
Aktuelle Version: 1.163.0
Datenbank: PostgreSQL empfohlen
Kommerzielles Angebot: Synapse Pro/Element Server Suite
Ein Homeserver für das Matrix-Netzwerk
Matrix ist ein föderiertes Kommunikationsprotokoll. Statt dass alle Nutzer an einen zentralen Anbieter gebunden sind, können Unternehmen ihre eigenen Homeserver betreiben und trotzdem mit Nutzern anderer Server kommunizieren.
Synapse übernimmt dabei die Rolle des Homeservers. Wenn ein Nutzer ein Konto auf einem Synapse-Server erstellt, enthält seine Matrix-ID den Servernamen (z. B. @alice:example.com). Die beteiligten Homeserver verwalten anschließend Räume, Nutzer, Nachrichten, Informationen über Raummitgliedschaften und andere Matrix-Ereignisse.
Wer Synapse selbst hostet, sollte daher bei der Installation besonders auf die Wahl des server_name achten. Dieser Wert wird Bestandteil der Nutzer-IDs und Raumadressen und lässt sich später nicht ohne Weiteres ändern. Ein Unternehmen kann beispielsweise example.com als Matrix-Identität verwenden, während Synapse tatsächlich unter matrix.example.com läuft.
Synapse selbst stellt normalerweise keine Chatoberfläche für Nutzer bereit. Stattdessen verbinden sie sich über einen Matrix-Client wie Element, FluffyChat oder eine andere kompatible Anwendung mit dem Server. Diese Trennung von Client und Server ist eine der Stärken von Matrix: Nutzer sind nicht an eine bestimmte Anwendung gebunden, nur weil sich das Unternehmen für Synapse als Server entschieden hat.
Souveränität beginnt beim selbst hosten.
Risiken minimieren. Kosten kontrollieren. Datenschutz maximieren. Starte jetzt mit Self-Hosting und Hetzner.
Föderation
Die Föderation unterscheidet Matrix von vielen anderen selbst gehosteten Chatsystemen. Ist sie aktiviert, können Nutzer deines Synapse-Servers Räumen beitreten, in denen sich auch Nutzer anderer Server befinden. Die beteiligten Matrix-Server tauschen die entsprechenden Ereignisse direkt miteinander aus.
Damit ähnelt Matrix vom Prinzip her eher E-Mails als einer klassischen Chatplattform für Unternehmen. Zwei Organisationen können jeweils ihre eigene Infrastruktur betreiben und miteinander kommunizieren, ohne Konten bei demselben zentralen Dienst zu benötigen.
Allerdings macht die Föderation die Netzwerkkonfiguration etwas aufwendiger. Andere Matrix-Server müssen wissen, wie sie deinen Homeserver erreichen können. Standardmäßig leitet Matrix diese Information aus dem konfigurierten server_name ab. Das Protokoll unterstützt aber auch die Delegierung über .well-known-Dateien. Dadurch lassen sich Nutzer-IDs wie @alice:example.com verwenden, obwohl Synapse selbst unter einem anderen Hostnamen wie matrix.example.com läuft.
Bei privaten Installationen lässt sich die Föderation auch einschränken oder vollständig deaktivieren. Ein Unternehmen, das Matrix ausschließlich für die interne Kommunikation einsetzen möchte, muss seinen Homeserver nicht unbedingt für das gesamte Matrix-Netzwerk zugänglich machen.
Deployment und Datenbank
Synapse lässt sich über Softwarepakete, Python-Umgebungen oder Container installieren. Eine typische selbst gehostete Produktivumgebung besteht aus Synapse, PostgreSQL, einem Reverse Proxy, dauerhaftem Speicher für Mediendateien und optional einem TURN-Server (Traversal Using Relays around NAT), der zuverlässige Sprach- und Videoverbindungen ermöglicht.
Synapse unterstützt für einfache Installationen auch SQLite. Für den produktiven Einsatz sollte PostgreSQL jedoch die Standardlösung sein. Besonders bei wachsenden Installationen gewinnt PostgreSQL an Bedeutung. Außerdem ist die Datenbank erforderlich, wenn Synapse mithilfe mehrerer Worker-Prozesse skaliert werden soll.
Normalerweise wird Synapse hinter einem Reverse Proxy wie NGINX, Caddy, Apache oder HAProxy betrieben. Dieser übernimmt die TLS-Terminierung und stellt die Matrix-Endpunkte für Clients und Föderation über die üblichen HTTPS-Ports bereit. Synapse selbst lauscht dabei auf einem internen HTTP-Port.
Auch die Medienspeicherung muss berücksichtigt werden. Bilder, Videos, Sprachnachrichten, Dokumente und andere hochgeladene Inhalte werden getrennt von der PostgreSQL-Datenbank gespeichert. Administratoren müssen deshalb sowohl die Datenbank als auch den Medienspeicher sichern. Ein Backup von PostgreSQL allein reicht für eine vollständige Wiederherstellung nicht aus.
Authentifizierung und Nutzerverwaltung
Synapse kann Nutzerkonten und Passwörter selbst verwalten. Unternehmen möchten die Software jedoch häufig in einen bestehenden Identity Provider integrieren. Je nach Umgebung unterstützt Synapse dafür Authentifizierungsverfahren wie OpenID Connect und Security Assertion Markup Language (SAML). Damit können sich Nutzer über eine bereits vorhandene Identitätsplattform anmelden.
Die Registrierung sollte sorgfältig konfiguriert werden. Ein öffentlich über das Internet erreichbarer Homeserver sollte normalerweise keine uneingeschränkte Registrierung neuer Konten erlauben, sofern dies nicht ausdrücklich gewünscht ist. Stattdessen können Administratoren Konten selbst erstellen, kontrollierte Registrierungsverfahren einsetzen oder einen externen Identity Provider verwenden.
Die Serverkonfiguration enthält außerdem sensible Informationen wie Registrierungsschlüssel und Signaturschlüssel. Diese sollten wie andere Zugangsdaten der Infrastruktur behandelt und bei der Backup- und Secret-Management-Strategie berücksichtigt werden.
Skalierung mit Workern
Für eine kleine oder mittelgroße Matrix-Installation sollte Synapse normalerweise zunächst als einzelner Prozess laufen. Eine offizielle Kapazitätsgrenze in Form einer bestimmten Nutzerzahl oder einer Anzahl von Ereignissen pro Sekunde gibt es nicht. Dafür unterscheiden sich die Workloads bei Matrix zu stark: 500 überwiegend inaktive Nutzer in kleinen privaten Räumen verursachen eine ganz andere Last als 500 Nutzer, die sich aktiv an großen föderierten Räumen beteiligen. Als grober Richtwert gilt: Ein ausreichend dimensionierter einzelner Synapse-Prozess mit PostgreSQL kann problemlos einige Hundert aktive Nutzer bedienen. Selbst bei Installationen mit etwa 1.000 registrierten Nutzern sind zusätzliche Worker möglicherweise nicht nötig, solange die gleichzeitige Nutzung und der Föderationsverkehr überschaubar bleiben.
Eine Skalierung mit Workern lohnt sich, wenn der Synapse-Hauptprozess regelmäßig einen CPU-Kern nahezu vollständig auslastet, /sync-Anfragen spürbar langsamer werden, sich die Verarbeitung von Föderationsereignissen verzögert oder die Nachrichtenübermittlung unter normaler Spitzenlast länger dauert. Da Synapse weitgehend in spezialisierte Aufgabenbereiche unterteilt ist, besteht der erste Schritt häufig nicht darin, mehrere identische Instanzen zu erstellen. Stattdessen können besonders ressourcenintensive Funktionen auf eigene Worker ausgelagert werden. Dazu gehören beispielsweise die Synchronisierung der Clients, die Verarbeitung von Föderationsereignissen, die Medienverarbeitung, Hintergrundaufgaben oder das dauerhafte Speichern von Ereignissen. Bei größeren Installationen lassen sich die für das Speichern von Ereignissen zuständigen Worker auch anhand der Raum-ID aufteilen (Sharding).
Ein sinnvoller Ansatz besteht daher darin, Installationen mit einigen Dutzend bis wenigen Hundert aktiven Nutzern zunächst mit der einfacheren monolithischen Architektur zu betreiben und ihre Auslastung zu überwachen, bevor zusätzliche Komplexität hinzukommt. Sobald mehrere Hundert Nutzer gleichzeitig aktiv sind, dauerhaft mehrere Hundert Anfragen pro Sekunde eingehen oder der Hauptprozess an seine CPU-Grenzen stößt, werden zusätzliche Worker zunehmend sinnvoll. Sehr große Installationen mit Tausenden gleichzeitig aktiven Nutzern sollten dagegen von Anfang an für den Betrieb mit mehreren Workern ausgelegt sein. Alle Worker greifen weiterhin auf dieselbe PostgreSQL-Datenbank zu und kommunizieren über die Replikationsmechanismen von Synapse, typischerweise mithilfe von Redis. Die horizontale Skalierung von Synapse macht eine ausreichend dimensionierte Datenbank daher nicht überflüssig.
Ein dedizierter Synapse-Server benötigt für eine kleine Installation keine besonders leistungsstarke Hardware. Ein Homeserver für ein kleines Unternehmen, eine Familie oder eine Community kann bei moderatem Föderationsverkehr und überschaubarer Mediennutzung problemlos mit 2–4 modernen CPU-Kernen, 4–8 GiB RAM und etwa 100–250 GB SSD- oder NVMe-Speicher starten. Für eine mittelgroße Installation mit mehreren Hundert aktiven Nutzern, größeren föderierten Räumen oder ersten Worker-Prozessen eignen sich etwa 6–12 CPU-Kerne, 32–64 GiB RAM und 500 GB bis 1 TB NVMe-Speicher besser. Bei einer großen Installation mit Tausenden aktiven Nutzern und mehreren Synapse-Workern bieten 16–32 CPU-Kerne, 64–128 GiB RAM und 1–4 TB schneller NVMe-Speicher eine sinnvolle Ausgangsbasis.
In dieser Größenordnung ist es allerdings meist sinnvoller, PostgreSQL, Synapse-Worker und Medienspeicher auf mehrere Systeme zu verteilen, statt einen einzelnen Server immer weiter aufzurüsten.
In allen Fällen ist schneller SSD-Speicher wichtiger als große Mengen langsamen Speicherplatzes, da die Leistung von PostgreSQL einen erheblichen Einfluss auf die Reaktionsgeschwindigkeit von Synapse hat.
Security und End-to-End-Verschlüsselung
Matrix unterstützt End-to-End-Verschlüsselung für private Unterhaltungen und Räume. In einem verschlüsselten Raum verschlüsseln die Clients die Nachrichteninhalte, bevor sie Synapse erreichen. Der Homeserver speichert und übermittelt somit verschlüsselte Ereignisse statt Nachrichteninhalte im Klartext.
Beim Self-Hosting ist diese Unterscheidung wichtig. Wenn du deinen eigenen Synapse-Server betreibst, hast du die Kontrolle über Kontodaten, Raummetadaten, Mediendateien, Infrastruktur und Aufbewahrungsfristen. Die Ende-zu-Ende-Verschlüsselung hängt jedoch in erster Linie von den Matrix-Clients und deren Schlüsselverwaltung ab.
Der Homeserver selbst bleibt sicherheitskritisch. Administratoren sollten Synapse und PostgreSQL deshalb regelmäßig aktualisieren, den Zugriff auf administrative APIs einschränken, Registrierungsmechanismen absichern, HTTPS verwenden, Signaturschlüssel sichern und vermeiden, interne Dienste direkt über das Internet zugänglich zu machen.
Fazit & Ausblick
Synapse ist die ausgereifteste Lösung für Unternehmen, die einen eigenen Matrix-Homeserver betreiben möchten. Zu den größten Stärken zählen die Kompatibilität mit dem Matrix-Ökosystem, die Föderation, die Unterstützung für Ende-zu-Ende-verschlüsselte Kommunikation, umfangreiche Verwaltungsfunktionen und die Möglichkeit, von einer kleinen Installation auf einem einzelnen Server bis hin zu deutlich größeren Umgebungen zu skalieren.
Dem steht eine gewisse Komplexität gegenüber. Für eine produktive Installation reicht es nicht aus, einfach einen Chat-Container zu starten. Auch PostgreSQL, DNS, TLS, Föderation, Medienspeicherung, Backups, Identitätsverwaltung und gegebenenfalls eine TURN-Infrastruktur müssen berücksichtigt werden.
Insgesamt eignet sich Synapse besonders für Teams, die ihre Kommunikationsinfrastruktur selbst kontrollieren möchten, ohne eine weitere isolierte Messaging-Plattform zu schaffen. Wer bereit ist, die dafür notwendige Infrastruktur selbst zu betreiben, findet in Matrix und Synapse eine überzeugende Alternative zu zentralisierten Kommunikationsplattformen.
