Etherpad 2026 selbst hosten: Pads, Plugins und Datenbank-Backups

Wenn du bereits versucht hast, Etherpad selbst zu hosten, kommt dir dieser frustrierende Zustand wahrscheinlich bekannt vor: Die Benutzeroberfläche erscheint, aber Sitzungen werden getrennt, weil die Proxy-Timeouts zu kurz sind. Den Container neu zu erstellen, behebt nur selten einen Widerspruch zwischen URLs, Status und Abhängigkeiten.

Diese Anleitung verwendet ein konkretes Abnahmekriterium: Öffne ein Pad in zwei Browsern, bearbeite es gleichzeitig, prüfe die Revisionen und exportiere das Ergebnis im erforderlichen Format. Jede Konfigurationsentscheidung wird an diesem Kriterium gemessen und nicht an einem grünen Container-Status.

Die kleinste praktikable Etherpad-Topologie wählen

Die kleinste verantwortbare Etherpad-Topologie besteht aus einem privaten Listener auf Port 9001, einer Ingress-Route und einer dokumentierten Zustandsgrenze. Der Netzwerkvertrag für Etherpad ist PostgreSQL oder eine andere unterstützte Datenbank für eine dauerhafte Nutzung mit mehreren Benutzern. Halte private Endpunkte im internen DNS, erlaube nur erforderliche ausgehende Verbindungen und gib Etherpad ein Service-Credential mit eingeschränktem Geltungsbereich.

Validiere die Topologie, indem du einen sauberen Client bittest, ein Pad in zwei Browsern zu öffnen, es gleichzeitig zu bearbeiten, die Revisionen zu prüfen und das Ergebnis im erforderlichen Format zu exportieren. Beobachte währenddessen WebSocket-Sitzungen, die Anzahl der Revisionen, Datenbankschreibvorgänge und die Plugin-Ausführung. Das Ergebnis zeigt dir, ob die nächste Verbesserung den Speicher, den Storage, das Netzwerk oder einen separaten Worker betrifft, statt dich zu einer beliebigen Dimensionierung des Containers zu verleiten.

Einen austauschbaren Etherpad-Container erstellen

Verwende den Container als austauschbare Runtime und nicht als Quelle der Wahrheit.

docker run -d \
  --name etherpad \
  --restart unless-stopped \
  -p 127.0.0.1:9001:9001 \
  -v etherpad-data:/opt/etherpad-lite/var \
  -e ADMIN_PASSWORD=replace-with-a-long-random-value \
  etherpad/etherpad:latest

Ergänze die geprüften Verbindungseinstellungen für PostgreSQL oder eine andere unterstützte Datenbank für eine dauerhafte Nutzung mit mehreren Benutzern. Verwende für private Services private Namen. Prüfe den Benutzer des Containers, die beschreibbaren Pfade und den gebundenen Listener, bevor du ihn öffentlich erreichbar machst. Führe die vollständige Aktion aus – öffne ein Pad in zwei Browsern, bearbeite es gleichzeitig, prüfe die Revisionen und exportiere das Ergebnis im erforderlichen Format – und speichere die exakte Image-Referenz, mit der das Ergebnis erzeugt wurde.

Verhindern, dass ein erfolgreicher Proxy die Fehlfunktion der Anwendung verdeckt

Browser, API-Client und Etherpad müssen sich auf einen gemeinsamen Origin verständigen. Setze dafür die öffentliche URL und aktiviere die WebSocket-Unterstützung im Proxy. Leite den ursprünglichen Host und das ursprüngliche Protokoll weiter und stelle gleichzeitig sicher, dass Port 9001 nicht als konkurrierende öffentliche Adresse verfügbar ist.

Die Anleitung zur Fehlersuche bei ausgefallenen Websites hilft dabei, eine nicht erreichbare Route von einer antwortenden Anwendung zu unterscheiden. Diese Unterscheidung ist hier wichtig: Sitzungen werden getrennt, weil die Proxy-Timeouts zu kurz sind. Nur der erste Fall lässt sich durch Änderungen am Ingress beheben; der zweite erfordert eine Prüfung der Etherpad-Logs, des Zustands oder der Workload.

Die Etherpad-Wiederherstellung vor dem Start planen

Schütze den Zustand von Etherpad, bevor du den Container optimierst. Zum erforderlichen Umfang gehören die Datenbank, hochgeladene Plugins und Einstellungen. Binde /opt/etherpad-lite/var vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Wenn mehrere Stores konsistent bleiben müssen, dokumentiere die Reihenfolge, in der Schreibvorgänge pausiert und Backups erstellt werden.

Bewahre Kopien außerhalb des Deployment-Servers auf und verschlüssele Material, das Credentials oder private Inhalte enthält. Eine Wiederherstellung ist erfolgreich, wenn Pads, Autoren, Revisionen und Plugins zurückkehren und gleichzeitige Bearbeitungen weiterhin konsistent zusammengeführt werden. Die Unterscheidung zwischen einem persistenten Mount und einer unabhängigen Kopie wird unter persistentem Storage und Snapshots erläutert.

Die Vertrauensgrenze von Etherpad festlegen

Schließe das Bootstrap-Fenster, sobald der erste vertrauenswürdige Administrator vorhanden ist. Die konkrete Falle bei Etherpad besteht darin, ein bekanntes Admin-Passwort auszuliefern oder Pads für alle beschreibbar zu lassen. Die sicherere Grenze ist ein echtes Admin-Passwort, eine bewusste Entscheidung darüber, wer Pads erstellen darf, und die Annahme, dass eine schwer zu erratende Pad-URL nicht privat ist.

Ersetze ADMIN_PASSWORD unverzüglich durch das Beispielpasswort, speichere es außerhalb des Images und rotiere es wie ein Administrator-Credential, falls es offengelegt wurde. Die private Vernetzung sollte Credentials für Abhängigkeiten transportieren, und Rollen innerhalb von Etherpad sollten nur die kleinstmögliche sinnvolle Aktion erlauben. Halte sensible Request-Bodies und Provider-Antworten aus den regulären Logs heraus.

Etherpad ohne Raten aktualisieren

Beobachte die Arbeit, die Etherpad ausführt: WebSocket-Sitzungen, die Anzahl der Revisionen, Datenbankschreibvorgänge und die Plugin-Ausführung. Setze Limits mit ausreichendem Puffer für diese Arbeit und vermeide einen Liveness-Probe, der mit ihr konkurriert. Der Operator-Check sollte weiterhin planmäßig versuchen, ein Pad in zwei Browsern zu öffnen, es gleichzeitig zu bearbeiten, die Revisionen zu prüfen und das Ergebnis im erforderlichen Format zu exportieren.

Denke bei Updates daran, dass Plugin-Versionen, Syntax der Einstellungen und Datenbankmigrationen von Etherpad gemeinsam getestet werden sollten. Deploye den Kandidaten gegen eine wiederhergestellte Kopie und wiederhole den bekannten Test. Wenn Sitzungen getrennt werden, weil die Proxy-Timeouts zu kurz sind, nutze Runtime-Logs und den tatsächlichen Netzwerk-Request, um herauszufinden, welche Annahme sich geändert hat.

Was vor dem Eintreffen echter Etherpad-Daten erfolgreich sein muss

Definiere für Etherpad vor dem Start eine bekannte funktionierende Transaktion: Öffne ein Pad in zwei Browsern, bearbeite es gleichzeitig, prüfe die Revisionen und exportiere das Ergebnis im erforderlichen Format. Lege ihre Voraussetzungen, die erwartete Antwort und die Bereinigungsschritte ohne Secret-Werte in der Versionsverwaltung ab. Pinne das Image, mit dem diese Referenz hergestellt wurde.

Verwende die Transaktion, um einen Austausch und eine unabhängige Wiederherstellung zu validieren. Der wiederhergestellte Service ist nur dann akzeptabel, wenn Pads, Autoren, Revisionen und Plugins zurückkehren und gleichzeitige Bearbeitungen weiterhin konsistent zusammengeführt werden. Beobachte gleichzeitig WebSocket-Sitzungen, die Anzahl der Revisionen, Datenbankschreibvorgänge und die Plugin-Ausführung und verwandle den langsamsten oder am stärksten eingeschränkten Teil in einen Service-Level-Alert.

Der Gate braucht außerdem einen Negativfall: Verweigere der Testidentität vorübergehend den Zugriff auf PostgreSQL oder eine andere unterstützte Datenbank für eine dauerhafte Nutzung mit mehreren Benutzern. Bestätige, dass Etherpad einen aussagekräftigen Fehler erzeugt und dabei die Daten bewahrt, stelle den gültigen Zustand wieder her und wiederhole die bekannte funktionierende Transaktion. Wenn du beide Ergebnisse aufbewahrst, kann ein oberflächlicher Health-Endpunkt nicht zum einzigen Produktionsnachweis werden.

Etherpad auf Dockup deployen, ohne seine Grenzen aufzugeben

Bei Etherpad ist Dockup besonders an der Grenze zwischen einem Image und einem dauerhaften Service nützlich. Die Route zu Port 9001, TLS, Secret-Werte und Storage bleiben bei Container-Ersetzungen erhalten, unabhängig davon, ob die Compute-Ressourcen zu Dockup oder zu deinem angebundenen Server gehören.

Schließe mit anwendungsspezifischem Wissen ab: Setze die öffentliche URL und aktiviere die WebSocket-Unterstützung im Proxy; verbinde PostgreSQL oder eine andere unterstützte Datenbank für eine dauerhafte Nutzung mit mehreren Benutzern und teste die Verbindung; und führe diese Prüfung aus: Öffne ein Pad in zwei Browsern, bearbeite es gleichzeitig, prüfe die Revisionen und exportiere das Ergebnis im erforderlichen Format. Bewahre das Ergebnis als Deployment-Check auf, damit das nächste Image-Update anhand des Verhaltens und nicht anhand des Container-Status bewertet wird.

Häufig gestellte Fragen

Was benötigt Etherpad für ein produktives Deployment?

Leite den Etherpad-Container über einen einzigen HTTPS-Origin auf Port 9001 weiter. Die unterstützende Netzwerkanforderung ist PostgreSQL oder eine andere unterstützte Datenbank für eine dauerhafte Nutzung mit mehreren Benutzern. Erkläre Etherpad erst dann für bereit, wenn du ein Pad in zwei Browsern öffnen, es gleichzeitig bearbeiten, die Revisionen prüfen und das Ergebnis im erforderlichen Format exportieren kannst.

Welche Etherpad-Daten gehören in ein Backup?

Mache /opt/etherpad-lite/var persistent und nimm Datenbank, hochgeladene Plugins und Einstellungen in dasselbe Wiederherstellungsmanifest auf. Eine saubere Etherpad-Wiederherstellung ist nur dann erfolgreich, wenn Pads, Autoren, Revisionen und Plugins zurückkehren und gleichzeitige Bearbeitungen weiterhin konsistent zusammengeführt werden.

Benötigt Etherpad hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für den öffentlichen Etherpad-Origin und halte Port 9001 auf der internen Route. Wende die Etherpad-Einstellung korrekt an: Setze die öffentliche URL und aktiviere die WebSocket-Unterstützung im Proxy. Bei Etherpad schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, vom Origin abhängiges Client-Verhalten.

Wie sollte ein Etherpad-Upgrade getestet werden?

Stelle den aktuellen Etherpad-Zustand in einem isolierten Deployment wieder her, spiele die Kandidatenversion ein und wiederhole die Abnahmetransaktion. Achte besonders darauf, da Plugin-Versionen, Syntax der Einstellungen und Datenbankmigrationen von Etherpad gemeinsam getestet werden sollten. Behalte das vorherige Etherpad-Image, bis die Grenzen der Datenmigration und des Rollbacks geklärt sind.