Wer Rocket.Chat zum ersten Mal öffnet, erkennt sofort die vertraute Grundordnung moderner Chatwerkzeuge: links eine Liste von Kanälen und Direktnachrichten, in der Mitte der Gesprächsverlauf, rechts kontextabhängige Bereiche für Threads, Dateien oder Mitglieder. Diese Vertrautheit ist beabsichtigt und praktisch wertvoll, weil sie den Schulungsaufwand bei einem Wechsel klein hält. Die eigentliche Substanz liegt eine Ebene darunter: in der Frage, wem die Daten gehören, wer den Server administriert und wie weit sich die Plattform an eigene Prozesse anpassen lässt.
Für die Einordnung ist wichtig, dass Rocket.Chat kein Nachbau eines einzelnen Wettbewerbers ist. Es bedient eine eigene Nachfrage: Organisationen, die Kommunikation als kritische Infrastruktur begreifen und sie deshalb nicht vollständig aus der Hand geben wollen. Das betrifft Behörden, Gesundheitswesen, Verteidigung und Forschung ebenso wie mittelständische Unternehmen mit hohen Anforderungen an Vertraulichkeit, Betriebsratsvereinbarungen oder branchenspezifische Aufsichtsregeln.
Der Kern von Rocket.Chat ist unter einer permissiven Open-Source-Lizenz veröffentlicht, der Quellcode ist öffentlich einsehbar und kann selbst gebaut, geprüft und angepasst werden. Zusätzlich existieren Funktionsbereiche, die dem kommerziellen Angebot des Herstellers zugeordnet sind und über Lizenzschlüssel freigeschaltet werden. Dieses Muster ist im professionellen Open-Source-Markt weit verbreitet und keineswegs ein Widerspruch: Es finanziert die Weiterentwicklung, verlangt aber vom Anwender eine genaue Prüfung, welche der benötigten Funktionen in welchem Teil des Angebots liegen.
Für die Praxis ergeben sich daraus drei Konsequenzen. Erstens: Auditierbarkeit. Wer wissen muss, wie Nachrichten verarbeitet und gespeichert werden, kann das am Quellcode nachvollziehen statt einer Marketingaussage zu vertrauen. Zweitens: Exit-Fähigkeit. Da die Datenhaltung in einer dokumentierten Datenbank liegt und Schnittstellen offen sind, bleibt ein Wechsel technisch möglich, auch wenn er wie jede Migration Aufwand bedeutet. Drittens: Prüfpflicht beim Funktionszuschnitt. Die Grenze zwischen frei verfügbaren und lizenzpflichtigen Funktionen verschiebt sich über Versionen hinweg und ist deshalb stets aktuell beim Anbieter zu klären, nicht aus älteren Vergleichstabellen abzuleiten.
In der Praxis begegnet Rocket.Chat in vier typischen Ausprägungen. Am häufigsten als interner Team-Messenger, der Slack oder eine gewachsene Landschaft aus privaten Messenger-Gruppen ersetzt. Zweitens als Kundenservice-Frontend, bei dem ein Livechat auf der Website und angebundene Messengerkanäle in derselben Oberfläche landen, in der die Belegschaft ohnehin arbeitet. Drittens als eingebettete Kommunikationsschicht in eigenen Anwendungen, Portalen oder Fachverfahren. Und viertens als abgeschottete Plattform in Umgebungen, die aus Sicherheitsgründen keine Verbindung nach außen haben dürfen.
Diese Bandbreite ist ein Vorteil und eine Falle zugleich. Sie erlaubt es, mehrere Bedarfe mit einer Plattform zu deckeln — was Lizenz- und Betriebskosten senkt und die Anzahl der Verarbeiter im Verzeichnis der Verarbeitungstätigkeiten reduziert. Sie verführt aber auch dazu, das Werkzeug ohne klaren Auftrag einzuführen und alles gleichzeitig zu wollen. Erfolgreiche Einführungen beginnen fast immer mit einem eng umrissenen Anwendungsfall und erweitern erst danach.
Rocket.Chat steht in der Kategorie Projektmanagement & Collaboration, weil es die Kommunikationsschicht der Zusammenarbeit stellt — jene Ebene, auf der Abstimmungen, Entscheidungen und Rückfragen tatsächlich stattfinden. Aufgabenverwaltung, Dokumentation und Terminplanung bringt es nicht selbst mit, sondern bindet sie an. Genau diese Rollenteilung ist gewollt: Ein Chatwerkzeug, das versucht, gleichzeitig Aufgabensystem und Wiki zu sein, macht meist beides halb.
Für die Werkzeugauswahl heißt das: Rocket.Chat wird nicht gegen ein Aufgabenwerkzeug abgewogen, sondern gegen andere Kommunikationsplattformen. Die relevanten Vergleichspunkte sind Betriebsmodell, Datenhoheit, Integrationsfähigkeit, Verwaltungsaufwand und die Frage, ob Kundenkommunikation mit abgedeckt werden soll. Alles andere entscheidet sich in den benachbarten Kapiteln des Stacks.
Die Community-Variante umfasst den quelloffenen Kern der Plattform und ist funktional deutlich mehr als eine Demonstration. Kanäle, private Gruppen, Direktnachrichten, Threads, Dateiablage, Suche, Rollen- und Rechteverwaltung, mobile und Desktop-Anwendungen, Webhooks sowie die Programmierschnittstellen gehören zum Kern. Für ein Team, das eine eigene Chatplattform betreiben und dabei keine unternehmensweite Verwaltungsschicht benötigt, ist das eine belastbare Grundlage.
Grenzen entstehen typischerweise an drei Stellen: bei fortgeschrittenen Verwaltungs- und Skalierungsfunktionen für große Installationen, bei bestimmten Compliance- und Auditbausteinen sowie bei Teilen des Omnichannel-Funktionsumfangs, etwa bei ausgefeilter Verteilungslogik für eingehende Anfragen. Wer die Community-Variante bewertet, sollte deshalb nicht fragen, ob sie ausreicht, sondern welche der eigenen Pflichtanforderungen genau darin enthalten sind. Diese Liste gehört an den Anfang jeder Auswahl, nicht ans Ende.
Die kommerziellen Ausprägungen setzen auf denselben Kern auf und ergänzen ihn um Funktionen, die vor allem für IT, Datenschutz und Revision relevant sind: erweiterte Identitäts- und Berechtigungssteuerung, Richtlinien für Aufbewahrung und Löschung, ausgebaute Protokollierung, feinere Steuerung von Apps und Erweiterungen sowie Werkzeuge für den Betrieb mehrerer Mandanten oder Standorte. Hinzu kommt der Punkt, der bei kritischer Infrastruktur oft den Ausschlag gibt: ein vertraglich zugesicherter Support mit definierten Reaktionszeiten.
Aus Beratungssicht ist dieser Supportaspekt häufiger der eigentliche Kaufgrund als eine einzelne Funktion. Eine Kommunikationsplattform, die stillsteht, hält ein Unternehmen an — und zwar sofort und für alle. Wer den Selbstbetrieb wählt und keine zweite Person mit Betriebswissen hat, kauft mit einer Subskription im Kern eine Versicherung. Diese Rechnung ist ehrlich zu führen: Sie fällt anders aus als der reine Vergleich von Funktionslisten.
Beim Betriebsmodell stehen drei Wege offen. Der vom Hersteller betriebene Cloud-Dienst nimmt den gesamten Betrieb ab: Installation, Aktualisierung, Sicherung, Verfügbarkeit. Dafür ist genau zu klären, in welcher Region die Instanz betrieben wird, wo Sicherungen liegen, welche Metadaten und Supportzugriffe anfallen und welches Vertragswerk gilt. Ein Auftragsverarbeitungsvertrag ist Pflicht, und wenn Verarbeitung oder Zugriff außerhalb der EU stattfinden können, ist der Transfermechanismus zu dokumentieren.
Das Self-Hosting in einem Rechenzentrum in Deutschland oder der EU ist der datenschutzrechtlich klarere Weg: Die Inhaltsdaten verlassen die eigene Verantwortungssphäre nicht, ein Drittlandtransfer entsteht durch den Betrieb nicht, und die Aufbewahrung richtet sich vollständig nach eigenen Vorgaben. Der Preis dafür ist Betriebsverantwortung — für Verfügbarkeit, Aktualisierung, Sicherung und Sicherheitspflege. Diese Verantwortung lässt sich an einen Dienstleister delegieren, aber nicht wegdiskutieren.
Der dritte Weg sind abgeschottete Installationen, oft als Air-Gapped bezeichnet: Umgebungen ohne Verbindung ins offene Netz. Rocket.Chat wird in solchen Szenarien eingesetzt, weil sich der Betrieb ohne herstellerseitige Onlinedienste organisieren lässt. Das verlangt allerdings eine durchdachte Versorgungskette für Aktualisierungen, Container-Abbilder und Lizenzinformationen sowie klare Prozesse für den Umgang mit Sicherheitsmeldungen. Ob und in welchem Umfang bestimmte Funktionen — etwa Push-Benachrichtigungen auf Mobilgeräten oder externe Dienste — in einer abgeschotteten Umgebung nutzbar sind, ist im Einzelfall zu prüfen.
Die Grundeinheit ist der Channel — ein themen-, projekt- oder bereichsbezogener Raum, der offen oder privat sein kann. Darüber steht das Konstrukt Team, das mehrere Kanäle unter einem gemeinsamen Dach bündelt und Mitgliedschaften sowie Zugriffsrechte auf dieser Ebene verwaltet. Dieses zweistufige Modell löst ein Problem, das in flachen Chatlandschaften regelmäßig auftritt: Ab einer bestimmten Größe weiß niemand mehr, welche Kanäle zu einem Bereich gehören und wer dort hineingehört.
Threads und Diskussionen sind das zweite Ordnungsmittel. Ein Thread hängt eine Unterhaltung an eine konkrete Nachricht und hält die Hauptspur lesbar; eine Diskussion erzeugt einen abgegrenzten Raum für ein Nebenthema, das eigene Aufmerksamkeit verdient. In der Praxis entscheidet die Thread-Disziplin darüber, ob ein Kanal mit dreißig Personen nutzbar bleibt oder zu einem Strom wird, den niemand mehr liest. Diese Disziplin ist Kulturarbeit, keine Konfiguration — aber sie lässt sich durch Kanalbeschreibungen, Beispiele und konsequentes Vorleben durch Führungskräfte erheblich fördern.
Ergänzt wird das durch die üblichen Bausteine moderner Kommunikation: Erwähnungen, Reaktionen, Nachrichtenbearbeitung, Zitieren und Weiterleiten, Sternchen und Lesezeichen, Dateianhänge mit Vorschau, eine Suche über Verlauf und Dateien, Abwesenheits- und Statusangaben sowie feingranulare Benachrichtigungseinstellungen je Kanal. Sichtbar wichtig für Organisationen: Rollen und Berechtigungen sind detailliert konfigurierbar, sodass sich etwa das Anlegen von Kanälen, das Einladen Externer oder das Löschen von Nachrichten gezielt beschränken lässt.
Für synchrone Zusammenarbeit stehen Sprach- und Videokonferenzen zur Verfügung, die aus einem Kanal oder einer Direktnachricht heraus gestartet werden, sowie Bildschirmfreigaben und Sprachnachrichten. Technisch werden solche Sitzungen über Konferenzdienste realisiert, die entweder mitgeliefert, als App eingebunden oder auf eigener Infrastruktur betrieben werden. Genau hier lohnt eine sorgfältige Prüfung: Ein selbst betriebener Chatserver, dessen Videokonferenzen über einen externen Dienst laufen, ist datenschutzrechtlich nicht mehr rein selbst betrieben.
Aus Beratungssicht empfiehlt sich, den Bedarf realistisch zu bemessen. Viele Organisationen brauchen im Chat nur die schnelle Zweier- oder Kleingruppenbesprechung und führen große Termine ohnehin in einem dedizierten Konferenzwerkzeug. Wer dagegen Webinare, große Schulungen oder aufgezeichnete Sitzungen benötigt, sollte einen spezialisierten Dienst einplanen und ihn anbinden, statt die Chatplattform an ihre Grenzen zu treiben. Die Qualität von Sprach- und Videoverbindungen hängt außerdem stark von Netzanbindung und Serverauslegung ab — sie ist im Selbstbetrieb eine Kapazitätsfrage, keine Lizenzfrage.
Der Omnichannel-Bereich ist das Merkmal, das Rocket.Chat von reinen Team-Messengern abhebt. Ein Livechat-Widget auf der eigenen Website erzeugt Anfragen, die in derselben Anwendung landen, in der die Belegschaft intern kommuniziert. Anfragen lassen sich Warteschlangen und Abteilungen zuordnen, an zuständige Personen verteilen, mit Gesprächsverläufen und Notizen versehen und nach Abschluss auswerten. Über Kanalanbindungen können zusätzlich verbreitete Messengerdienste, E-Mail oder soziale Kanäle einbezogen werden — je nach Ausprägung und verfügbaren Apps.
Der praktische Gewinn ist der Wegfall eines Systemwechsels: Wer eine Kundenanfrage bearbeitet, kann in derselben Oberfläche einen Kollegen in einem internen Thread hinzuziehen. Zu bedenken ist die Kehrseite: Sobald Kundenkommunikation über Dienste Dritter einläuft, kommen weitere Verarbeiter, weitere Vertragswerke und weitere Datenflüsse ins Spiel. Bei verbreiteten Consumer-Messengern ist die datenschutzrechtliche Bewertung besonders sorgfältig zu führen — die Anbindung an eine selbst betriebene Plattform macht den externen Dienst nicht souverän.
Die Federation zielt in eine andere Richtung: Sie erlaubt es, Personen auf anderen Servern anzusprechen, ohne sie in die eigene Installation einzuladen. Rocket.Chat verfolgt hier die Anbindung an das offene Matrix-Protokoll, das im Bereich souveräner Kommunikation eine zentrale Rolle spielt. Für Szenarien mit vielen externen Partnern, verbundenen Einrichtungen oder Verwaltungsstrukturen ist das ein starkes Argument. Reifegrad, Funktionsdeckung und Konfigurationsaufwand einer solchen Verbindung entwickeln sich jedoch weiter und sollten vor einer Zusage konkret erprobt werden — am besten in einem Testverbund mit einem echten Partnerserver.
Rocket.Chat steht als Webanwendung, als Desktop-Anwendung für die verbreiteten Betriebssysteme und als mobile App für Smartphones und Tablets bereit. Für den Selbstbetrieb ist ein Detail relevant, das gern übersehen wird: Push-Benachrichtigungen auf Mobilgeräten laufen üblicherweise über die Dienste der Plattformbetreiber. Wer diesen Weg vermeiden möchte oder muss, sollte die verfügbaren Optionen und deren Auswirkungen auf die Benachrichtigungsqualität vorab klären, denn eine App, die Nachrichten erst beim Öffnen zeigt, verändert das Nutzungsverhalten deutlich.
Ebenfalls praxisrelevant: Mehrsprachigkeit inklusive deutscher Oberfläche, Anpassbarkeit des Erscheinungsbilds mit eigenem Logo und eigenen Farben, sowie die Möglichkeit, die Anwendung in bestehende Portale einzubetten. Wer Barrierefreiheit als Anforderung führt — für öffentliche Stellen inzwischen der Regelfall —, sollte den aktuellen Stand anhand der Herstellerangaben und eines eigenen Tests mit Screenreader und Tastaturbedienung prüfen, statt sich auf allgemeine Zusicherungen zu verlassen.
Die einfachste und robusteste Form der Automatisierung sind Webhooks. Eingehende Webhooks erlauben es beliebigen Systemen, Nachrichten in einen Kanal zu schreiben — Monitoring-Alarme, Bestellungen aus dem Shop, Ergebnisse eines Buildlaufs, Statusmeldungen einer Maschine. Ausgehende Webhooks reagieren umgekehrt auf Nachrichten oder Schlüsselwörter und rufen ein Zielsystem auf. Beides ist mit überschaubarem Aufwand einzurichten und deckt in der Praxis einen großen Teil der Automatisierungswünsche ab, ohne dass Software entwickelt werden muss.
Eine Stufe darüber stehen Bots als eigenständige Konten, die Befehle verstehen, Rückfragen stellen und Dialoge führen. Typische Anwendungen im Mittelstand sind Urlaubsanträge, Krankmeldungen, Raum- und Fahrzeugbuchungen, das Nachschlagen von Kundendaten, Schichttausch oder das Erfassen von Störmeldungen mit Foto. Der Gewinn liegt darin, dass Mitarbeitende für einfache Vorgänge kein Fachsystem öffnen und keine zusätzliche Anmeldung durchlaufen müssen — sie schreiben dort, wo sie ohnehin sind.
Die Apps-Engine ist der strukturierte Weg für eigene Erweiterungen. Sie erlaubt es, Funktionen als installierbare App zu bauen: mit eigenen Slash-Befehlen, interaktiven Elementen wie Formularen und Schaltflächen, Reaktionen auf Ereignisse und Zugriff auf definierte Schnittstellen der Plattform. Für Organisationen mit eigener Entwicklungskapazität ist das ein erheblicher Hebel, weil sich Fachlogik sauber gekapselt ausliefern und über einen Marktplatz oder privat verteilen lässt, statt den Server selbst zu verändern. Damit bleibt die Plattform aktualisierbar — ein Punkt, an dem individuell angepasste Installationen sonst regelmäßig scheitern.
Die KI-Funktionen zielen auf Aufgaben, die im Chatalltag Zeit kosten: das Zusammenfassen langer Kanäle und Threads nach einer Abwesenheit, das Formulieren und Verbessern von Antworten, das Übersetzen in mehrsprachigen Teams sowie im Servicebereich das Vorschlagen von Antworten auf Basis eigener Wissensbestände. Gerade im Kundenservice liegt hier ein realer Nutzen, weil sich wiederkehrende Fragen schneller beantworten lassen und der Übergang von automatisierter zu persönlicher Bearbeitung im selben Verlauf stattfindet.
Bei der Bewertung ist Nüchternheit angebracht. Zusammenfassungen sind Hilfsmittel, keine Protokolle — Entscheidungen gehören dokumentiert und nicht aus einem Gesprächsverlauf rekonstruiert. Antwortvorschläge im Kundenkontakt brauchen eine menschliche Freigabe, wenn Zusagen, Preise oder rechtlich relevante Auskünfte im Spiel sind. Und jede KI-Funktion verändert die Verarbeitung personenbezogener Daten und gehört deshalb in die Datenschutzdokumentation, gegebenenfalls in eine Folgenabschätzung und in die Abstimmung mit der Arbeitnehmervertretung.
Der aus Souveränitätssicht stärkste Punkt ist die Möglichkeit, KI-Funktionen mit selbst betriebenen Sprachmodellen zu verbinden statt mit einem Dienst in einem Drittland. Technisch geschieht das über die Anbindung eines Modell-Endpunkts, der im eigenen Rechenzentrum oder bei einem europäischen Anbieter läuft. In Kombination mit dem Selbstbetrieb der Plattform entsteht damit ein Aufbau, in dem Gesprächsinhalte die eigene Infrastruktur nicht verlassen — ein Argument, das in regulierten Branchen häufig den Unterschied zwischen Machbarkeit und Ablehnung ausmacht.
Realistisch bleibt festzuhalten, welche Voraussetzungen das mitbringt. Ein lokal betriebenes Modell verlangt geeignete Hardware, Kapazitätsplanung, Modellpflege und Fachwissen für Betrieb und Absicherung. Die Antwortqualität und der Funktionsumfang hängen vom gewählten Modell ab und sind nicht mit den größten kommerziellen Diensten gleichzusetzen. Welche Modelle und Anbindungsarten in welcher Ausprägung unterstützt werden, entwickelt sich schnell weiter und ist beim Anbieter für den geplanten Aufbau konkret zu prüfen.
Ein pragmatischer Zwischenweg hat sich in Projekten bewährt: KI-Funktionen zunächst für klar abgegrenzte, wenig sensible Anwendungsfälle freischalten — etwa Übersetzung in öffentlichen Kanälen oder Antwortvorschläge in einem Servicebereich mit unkritischen Inhalten. Aus diesen Erfahrungen entsteht eine belastbare Grundlage für die Entscheidung, ob und wo ein eigener Modellbetrieb den Aufwand rechtfertigt.
Der erste und wichtigste Integrationspunkt ist die Benutzerverwaltung. Rocket.Chat unterstützt die Anbindung an Verzeichnisdienste über LDAP beziehungsweise Active Directory sowie moderne Anmeldeverfahren über SAML und OpenID Connect. Damit lässt sich die Plattform an einen zentralen Identitätsanbieter hängen — häufig Keycloak in souveränitätsorientierten Umgebungen, alternativ der bestehende Verzeichnisdienst oder ein Cloud-Identitätsdienst. Praktisch relevant sind dabei drei Punkte: automatische Anlage neuer Konten, Zuordnung von Gruppen zu Rollen und Kanälen sowie das zuverlässige Sperren von Konten beim Austritt.
Dieser letzte Punkt entscheidet über die Auditfähigkeit. Eine Chatplattform, in der ausgeschiedene Mitarbeitende noch Konten haben, ist ein Befund in jeder Prüfung. Die belastbare Lösung ist keine Handarbeit, sondern die Kopplung an den führenden Personaldatenbestand über den Identitätsanbieter. Ergänzend sollte die Zwei-Faktor-Authentisierung verpflichtend gemacht werden, mindestens für administrative Rollen und für Zugriffe von außerhalb des Firmennetzes.
Für die gängigen Werkzeuge des Arbeitsalltags existieren Anbindungen, teils als App, teils über Webhooks. Aus dem Aufgaben- und Vorgangsmanagement lassen sich Ereignisse in Kanäle spiegeln — etwa neue Tickets, Statuswechsel oder Kommentare aus einem Vorgangssystem, sodass ein Team über Änderungen informiert ist, ohne dauernd nachzusehen. Aus der Softwareentwicklung sind Meldungen über Änderungen, Prüfanfragen und Ergebnisse von Prüfläufen üblich, wie man sie von Plattformen der Versionsverwaltung kennt.
Bei Dateien und Dokumenten ist die Verbindung mit einer selbst betriebenen Dateiplattform besonders interessant, weil sich damit ein durchgängig souveräner Aufbau ergibt: Kommunikation auf dem eigenen Chatserver, Dokumente auf der eigenen Dateiplattform, Anmeldung über den eigenen Identitätsanbieter. In der Praxis ist diese Kombination bei Behörden und im gehobenen Mittelstand ein verbreitetes Muster und oft der eigentliche Grund, warum Rocket.Chat in die Auswahl kommt.
Im Kundenkontakt ist die Anbindung an CRM- und Servicesysteme der Hebel, der aus dem Livechat mehr macht als einen Nachrichtenkanal. Sinnvoll ist mindestens die Erkennung bekannter Kontakte, das Zurückschreiben von Gesprächsverläufen in den Kundendatensatz und die Erzeugung eines Vorgangs, wenn eine Anfrage nicht sofort gelöst wird. Standardanbindungen existieren für verbreitete Systeme; für Branchensoftware führt der Weg üblicherweise über die Schnittstellen — was gut funktioniert, aber Entwicklungsaufwand bedeutet und in die Kostenrechnung gehört.
Für alles, wofür keine fertige Anbindung existiert, stehen zwei Schnittstellen bereit. Die REST-API deckt die klassischen Verwaltungs- und Nachrichtenoperationen ab: Nutzer und Kanäle anlegen und verwalten, Nachrichten senden und lesen, Dateien hochladen, Einstellungen ändern, Auswertungen abrufen. Sie ist der übliche Weg für Automatisierungsskripte, Bereitstellungsprozesse und die Anbindung von Fachverfahren. Die Realtime-API arbeitet ereignisgetrieben über eine dauerhafte Verbindung und ist die richtige Wahl, wenn eine eigene Anwendung Nachrichten unmittelbar empfangen oder eine eingebettete Oberfläche live aktualisieren soll.
Diese Offenheit ist ein echter Vorzug gegenüber geschlossenen Plattformen, verlangt aber Disziplin. Drei Punkte haben sich als Prüfliste bewährt: Zugangsdaten gehören in eine Geheimnisverwaltung und nicht in Skripte; Berechtigungen für technische Konten sollten minimal geschnitten sein, damit ein kompromittierter Bot nicht die ganze Installation liest; und Versionsstände sind zu beobachten, weil Anpassungen an Schnittstellen mit Aktualisierungen der Plattform brechen können. Eine Testinstanz, auf der Aktualisierungen vor dem Produktivsystem eingespielt werden, ist bei intensiver Schnittstellennutzung nicht optional, sondern Voraussetzung.
Slack gilt vielen als Referenz für Bedienbarkeit und Ökosystem. Es bringt eine sehr große Zahl fertiger Anbindungen, eine ausgereifte Suche und eine hohe Alltagsqualität mit. Der Unterschied zu Rocket.Chat liegt nicht primär in Funktionen, sondern im Modell: Slack ist ein reiner Cloud-Dienst eines US-Anbieters ohne Selbstbetriebsoption. Für Organisationen, die Datenhaltung und Betrieb selbst bestimmen müssen, endet der Vergleich an dieser Stelle unabhängig davon, wie gut das Produkt ist.
Microsoft Teams spielt eine andere Karte: die Integration in eine Umgebung, die viele Unternehmen ohnehin nutzen. Wer mit Microsoft 365 arbeitet, bekommt Chat, Konferenz, Dateien und Kalender in einem Verbund und ohne zusätzlichen Anbieter im Verzeichnis der Verarbeitungstätigkeiten. Das ist ein starkes Argument. Ihm gegenüber stehen die Bindung an einen Anbieter, ein je nach Zuschnitt hoher Ressourcenbedarf auf Endgeräten und die Tatsache, dass Datenhaltung und Betrieb nicht in eigener Hand liegen. Rocket.Chat gewinnt diesen Vergleich dort, wo Souveränität, Anpassbarkeit oder Kundenkommunikation im selben Werkzeug den Ausschlag geben — und verliert ihn dort, wo eine Organisation vollständig auf Microsoft ausgerichtet ist und keine zusätzliche Plattform betreiben will.
Mattermost ist der direkteste Vergleichskandidat: ebenfalls selbst betreibbar, ebenfalls quelloffen im Kern, ebenfalls auf Unternehmen ausgerichtet. Die Unterschiede liegen im Schwerpunkt. Mattermost positioniert sich stark bei technischen Teams und in sicherheitskritischen Betriebsabläufen, mit ausgeprägten Funktionen für strukturierte Abläufe und Vorfallsbearbeitung. Rocket.Chat deckt dagegen den Bereich Kundenkommunikation und Omnichannel ab, den Mattermost so nicht adressiert. Wer beides braucht — internen Chat und Kundenkanal —, findet bei Rocket.Chat eine Antwort aus einer Hand.
Element ist die bekannteste Anwendung für das Matrix-Protokoll und setzt am konsequentesten auf Föderation und Ende-zu-Ende-Verschlüsselung. Für Szenarien, in denen die Verschlüsselung des Inhalts nicht verhandelbar ist und viele unabhängige Organisationen zusammenarbeiten, ist das ein Vorzug, den man ernst nehmen muss. Die Kehrseite ist, dass durchgängige Verschlüsselung serverseitige Verarbeitung erschwert — von der Volltextsuche über Bots bis zur maschinellen Auswertung. Rocket.Chat wählt hier bewusst einen anderen Punkt auf der Skala und bietet gleichzeitig eine Anbindung an Matrix, um beide Welten zu verbinden.
Zulip verfolgt ein eigenständiges Ordnungsmodell mit konsequenter Themenstruktur innerhalb von Kanälen. In großen, verteilten und asynchron arbeitenden Gruppen ist das nachweislich lesbarer als ein reiner Nachrichtenstrom. Der Preis ist Umstellungsbereitschaft: Teams müssen die Themenlogik verstehen und mitmachen. Wo Nutzende die Slack-ähnliche Bedienung erwarten, ist Rocket.Chat der geringere kulturelle Bruch.
Die häufigste Fehlerquelle bei dieser Auswahl ist eine Bewertung nach Funktionslisten. Weil alle Kandidaten Kanäle, Threads, Dateien und Suche bieten, wirken die Listen ähnlich — und die Entscheidung fällt am Ende nach Sympathie. Belastbar wird sie erst durch drei Fragen in dieser Reihenfolge: Erstens, welche Anforderungen sind Ausschlusskriterien und nicht verhandelbar, etwa Datenhaltung im Inland oder eine bestimmte Identitätsanbindung? Zweitens, wer betreibt die Plattform verlässlich über Jahre? Drittens, welche Arbeitsabläufe sollen konkret besser werden und wie sieht das im Werkzeug aus?
Erst danach lohnt eine Erprobung, und diese sollte mit echten Inhalten und echten Menschen stattfinden — nicht als Vorführung, sondern als vierwöchiger Parallelbetrieb in einem Team, das den Anwendungsfall repräsentiert. In dieser Zeit zeigt sich, was in keinem Vergleich steht: ob die Suche im eigenen Sprachgebrauch findet, ob mobile Benachrichtigungen ankommen, ob Externe ohne Rückfragen hineinfinden.
Rocket.Chat wird üblicherweise als Container betrieben, im einfachsten Fall mit Docker und einer Zusammenstellung aus Anwendung, Datenbank und einem vorgeschalteten Webserver, der die Verschlüsselung der Verbindung übernimmt. Für größere Installationen und höhere Verfügbarkeitsanforderungen kommt Kubernetes ins Spiel, mit mehreren Instanzen hinter einem Lastverteiler. Als Datenhaltung dient MongoDB, im Produktivbetrieb sinnvollerweise als Replikationsverbund, weil die Anwendung Änderungsereignisse der Datenbank nutzt und der Verbund gleichzeitig Ausfallsicherheit schafft.
Die Auslegung folgt drei Größen: Zahl gleichzeitig verbundener Nutzender, Nachrichtenaufkommen und Datenvolumen der Anhänge. Konkrete Zahlen nennen wir hier nicht, weil sie stark von Version, Nutzungsmuster und Infrastruktur abhängen; belastbar sind nur die Empfehlungen des Anbieters für die jeweilige Größenklasse und eigene Lasttests. Zwei Erfahrungswerte lassen sich dennoch benennen: Der Speicherbedarf für Anhänge wird fast immer unterschätzt, weshalb ein separater Objektspeicher statt lokaler Ablage die bessere Wahl ist. Und die Datenbank ist der Punkt, an dem Leistungsprobleme zuerst sichtbar werden — schnelle Datenträger und ausreichender Arbeitsspeicher zahlen sich hier unmittelbar aus.
Die Aktualisierung ist die wichtigste Betriebsdisziplin, weil eine öffentlich erreichbare Kommunikationsplattform ein attraktives Ziel ist. Praktisch bedeutet das: Sicherheitsmeldungen des Projekts verfolgen, ein Wartungsfenster etablieren, Aktualisierungen erst auf einer Testinstanz einspielen und Versionssprünge nicht überspringen, weil Datenbankmigrationen aufeinander aufbauen können. Wer die Aktualisierung nicht als festen Termin führt, verschiebt sie — und stellt nach anderthalb Jahren fest, dass mehrere Hauptversionen und angepasste Anbindungen gleichzeitig zu bewältigen sind.
Die Sicherung muss drei Bestandteile umfassen: die Datenbank, die abgelegten Dateien und die Konfiguration inklusive Umgebungsvariablen und Zertifikaten. Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung — ein Wiederherstellungstest auf einer separaten Umgebung gehört mindestens jährlich in den Kalender. Für die Überwachung reicht ein Ping auf die Startseite nicht aus; sinnvoll sind Kennzahlen der Anwendung und der Datenbank, Belegung der Datenträger, Zustand der Sitzungen, Zertifikatslaufzeiten und ein Alarmweg, der nicht über die überwachte Plattform selbst läuft.
Bewährt hat sich ein Vorgehen in fünf Schritten. Es klingt aufwendiger als es ist, spart aber die typische Nachbesserungsrunde, in der man Kanalstrukturen im Nachhinein ordnet und Nutzende ein zweites Mal umgewöhnen muss.
Zum Betriebsaufwand eine offene Einschätzung: Eine kleine Installation für ein Unternehmen mit überschaubarer Nutzerzahl ist mit wenigen Stunden im Monat zu halten, solange sie standardnah aufgebaut ist und niemand am Server bastelt. Der Aufwand steigt sprunghaft, sobald hohe Verfügbarkeit gefordert ist, viele eigene Anbindungen bestehen oder eine abgeschottete Umgebung betrieben wird. Wer diesen Aufwand nicht im eigenen Haus abbilden kann, sollte ihn einkaufen — entweder als betreuten Betrieb bei einem Dienstleister in Deutschland oder als Herstellerangebot mit geklärtem Serverstandort.
Für Unternehmen mit erklärungsbedürftigen Produkten ist der Omnichannel-Ansatz der stärkste Einzelgrund für Rocket.Chat. Der typische Ablauf: Eine Kundin stellt über das Widget auf der Website eine Frage, die Anfrage landet in der Warteschlange der zuständigen Abteilung, wird von einer Servicekraft angenommen, benötigt eine technische Rückfrage — und diese findet in einem internen Thread statt, während das Gespräch offen bleibt. Ohne Systemwechsel, ohne Weiterleitung per Mail, ohne Kontextverlust.
Damit dieser Ablauf trägt, sind drei Dinge vorab zu klären. Erstens die Erreichbarkeit: Ein Chat, der zu Geschäftszeiten unbeantwortet bleibt, schadet mehr als er hilft — deshalb Zeiten kommunizieren, Abwesenheitsverhalten definieren und eine Übergabe an E-Mail oder Rückruf vorsehen. Zweitens die Zuständigkeit: Abteilungen und Verteilungslogik müssen den realen Organisationsschnitt abbilden. Drittens die Datenverarbeitung: Der Livechat verarbeitet personenbezogene Daten von Kunden, also braucht er einen Hinweis in der Datenschutzerklärung, eine geregelte Aufbewahrung und eine Entscheidung darüber, was in das CRM zurückgeschrieben wird.
Kaum ein mittelständisches Unternehmen ist frei davon: In Werkstatt, Baustelle, Pflege, Gastronomie oder Außendienst haben sich Gruppen auf privaten Telefonnummern etabliert, weil sie einfach funktionierten. Aus Sicht des Datenschutzes und der Informationssicherheit ist das eine unangenehme Lage — dienstliche Inhalte und teils personenbezogene Daten liegen bei einem Dienst ohne Vertrag, auf privaten Geräten, und beim Austritt einer Person gibt es keinen geordneten Weg, den Zugriff zu beenden.
Eine selbst betriebene Plattform löst das strukturell: dienstliche Konten, geregelte Berechtigungen, sauberer Austrittsprozess, keine privaten Telefonnummern im Umlauf. Die Umstellung gelingt allerdings nur, wenn sie den Beteiligten einen Vorteil bringt und nicht bloß eine Vorschrift erfüllt. Wirksam sind drei Dinge: die App muss auf privaten Geräten unaufdringlich funktionieren, es braucht klare Regeln zur Erreichbarkeit außerhalb der Arbeitszeit — ein Punkt, der ohne Betriebsvereinbarung schnell strittig wird —, und die alten Gruppen müssen zu einem angekündigten Termin geschlossen werden. Wer beides parallel laufen lässt, hat nach drei Monaten zwei Kanäle und mehr Aufwand als vorher.
Ein oft übersehener Vorteil zeigt sich bei Beschäftigten ohne festen Arbeitsplatz am Rechner. Für diese Gruppe sind lizenzkostenintensive Arbeitsplatzpakete häufig unwirtschaftlich, gleichzeitig fehlt ihnen der Zugang zu Information, die andere selbstverständlich haben. Eine Kommunikationsplattform mit brauchbarer mobiler Anwendung schließt diese Lücke — für Schichtübergaben, Sicherheitshinweise, Störmeldungen mit Foto, Materialanforderungen oder das Nachschlagen von Arbeitsanweisungen.
Zwei Hinweise aus Projekten: Erstens lohnt der Einsatz von Bots für einfache Vorgänge besonders in dieser Gruppe, weil das Öffnen eines Fachsystems auf dem Smartphone in der Halle praktisch nicht stattfindet — eine kurze Chatabfrage dagegen schon. Zweitens ist die Frage der Geräte vorab zu klären: Werden dienstliche Smartphones gestellt oder wird private Nutzung erlaubt? Beide Wege sind machbar, verlangen aber unterschiedliche Regelungen zu Absicherung, Kostenbeteiligung und Erreichbarkeit — und beide gehören in die Abstimmung mit der Arbeitnehmervertretung.
Eine belastbare Kostenrechnung umfasst mindestens fünf Posten. Erstens, sofern eine kommerzielle Ausprägung gewählt wird, die Subskription, üblicherweise nach Nutzerzahl gestaffelt — Konditionen sind beim Anbieter zu erfragen. Zweitens die Infrastruktur: Server oder Container-Umgebung, Datenbank, Objektspeicher, Datensicherung, Netzanbindung, Zertifikate. Drittens der Betriebsaufwand in Personenstunden für Aktualisierungen, Überwachung, Fehlerbehebung und Anfragen der Nutzenden. Viertens die Einführung: Konzeption, Anbindung des Identitätsanbieters, Integrationen, Schulung, Kommunikation. Fünftens der Compliance-Aufwand: Datenschutzdokumentation, Verzeichnis der Verarbeitungstätigkeiten, Abstimmung mit der Arbeitnehmervertretung.
Der häufigste Rechenfehler besteht darin, den quelloffenen Kern als kostenlos zu verbuchen und daraus einen Kostenvorteil gegenüber einem Abonnement abzuleiten. Bei kleinen Nutzerzahlen ist der Selbstbetrieb häufig nicht günstiger, weil der Betriebsaufwand kaum mit der Nutzerzahl skaliert: Aktualisierungen und Überwachung kosten bei dreißig Nutzenden fast so viel wie bei dreihundert. Umgekehrt kippt die Rechnung mit wachsender Zahl deutlich zugunsten des Selbstbetriebs, weil dort keine Kosten je Nutzer entstehen, während Abonnements linear mitwachsen. Wer Beschäftigte ohne Schreibtischarbeitsplatz einbeziehen möchte, erreicht diesen Kipppunkt oft schneller als erwartet.
Ein zweiter Punkt betrifft Lizenzklarheit. Bei quelloffener Software mit kommerziellen Zusatzmodulen ist zu dokumentieren, welche Funktionen genutzt werden und unter welchen Bedingungen. Wer Erweiterungen selbst entwickelt oder den Quellcode anpasst, sollte die Lizenzbedingungen des Kerns und der eingebundenen Bestandteile prüfen — das ist keine akademische Frage, sondern relevant, sobald eigene Anpassungen weitergegeben oder in Produkte eingebettet werden.
Der entscheidende Vorteil einer selbst betriebenen Installation in einem Rechenzentrum in Deutschland oder der EU ist die Einfachheit der Argumentation. Die Inhaltsdaten liegen in der eigenen Verantwortungssphäre, ein Drittlandtransfer entsteht durch den Betrieb nicht, Aufbewahrung und Löschung folgen eigenen Vorgaben, und im Verzeichnis der Verarbeitungstätigkeiten steht kein zusätzlicher Verarbeiter für die Kernfunktion. Wird der Betrieb an einen Dienstleister übergeben, ist dieser Auftragsverarbeiter — dann braucht es einen Auftragsverarbeitungsvertrag mit dokumentierten technischen und organisatorischen Maßnahmen, aber der Kreis der Beteiligten bleibt überschaubar und der Ort der Verarbeitung eindeutig.
Wird stattdessen ein vom Hersteller betriebener Cloud-Dienst gewählt, sind vier Punkte konkret zu klären und schriftlich festzuhalten: der Serverstandort für Inhaltsdaten und für Sicherungen; die Verarbeitung von Metadaten, Protokollen und Supportzugriffen, die abweichend geregelt sein kann; die Liste der Unterauftragsverarbeiter und deren Standorte; sowie der Transfermechanismus, falls Verarbeitung oder Zugriff außerhalb der EU möglich sind. Pauschale Aussagen sind hier unangebracht: Verfügbarkeit von Regionen und Vertragsdetails entwickeln sich weiter und sind für den geplanten Aufbau beim Anbieter zu prüfen.
Unabhängig vom Modell bleiben Restpunkte, die auch bei Selbstbetrieb bestehen. Dazu zählen Push-Benachrichtigungen, die üblicherweise über Dienste der Mobilplattformen laufen, eingebundene Apps und Erweiterungen Dritter, angebundene Konferenzdienste und externe Sprachmodelle. Jeder dieser Bausteine ist gesondert zu bewerten. Ein selbst betriebener Server mit einem Dutzend externer Anbindungen ist datenschutzrechtlich nicht automatisch souverän — Souveränität ist eine Eigenschaft der gesamten Kette.
Eine Kommunikationsplattform protokolliert notwendigerweise, wer wann welche Nachricht geschrieben hat, wer online war und wer worauf reagiert hat. Damit ist sie geeignet, Verhalten und Leistung zu überwachen — unabhängig davon, ob das beabsichtigt ist. In Betrieben mit Betriebsrat löst diese Eignung in Deutschland die Mitbestimmung nach § 87 BetrVG aus. Der pragmatische Weg ist eine frühe Einbindung und eine Betriebsvereinbarung, die festhält, wofür Daten genutzt werden und wofür ausdrücklich nicht: kein individuelles Leistungsprofil, keine Auswertung von Anwesenheitsstatus zur Arbeitszeitkontrolle, keine Auswertung privater Nachrichten. Ebenfalls hierher gehören Erreichbarkeitsregeln außerhalb der Arbeitszeit und der Umgang mit privaten Geräten. Für Österreich und die Schweiz gelten sinngemäß eigene Regelungen, die separat zu prüfen sind.
Technisch sind vier Stellschrauben entscheidend. Die Aufbewahrung: Wie lange bleiben Nachrichten und Dateien erhalten, und wird automatisch gelöscht? Eine klare, dokumentierte Aufbewahrungsfrist ist datenschutzrechtlich wertvoll und reduziert gleichzeitig das Risiko im Fall eines Vorfalls — allerdings sind Aufbewahrungspflichten aus anderen Rechtsgebieten zu berücksichtigen, wenn geschäftsrelevante Korrespondenz im Chat stattfindet. Die Berechtigungen: minimal geschnitten, mit besonderer Aufmerksamkeit für administrative Rollen und Konten, die Verläufe einsehen können. Der Umgang mit Externen: Gastzugänge zeitlich begrenzen, nur auf benötigte Kanäle berechtigen, Austritt regeln. Und die Freigabe von Apps: eine Liste zugelassener Erweiterungen führen, alles Übrige sperren, jede Erweiterung als möglichen eigenen Verarbeiter bewerten.
Der einfachste und wirksamste Grundsatz bleibt Datensparsamkeit im Inhalt: keine besonderen Kategorien personenbezogener Daten, keine Gesundheits- oder Bewerberdetails, keine Zugangsdaten und keine vertraulichen Vertragsinhalte im Chat. Diese Regel gehört in die Handreichung für Nutzende — verständlich formuliert und mit Beispielen, nicht als Paragraphenzitat.
