Zum Hauptinhalt springen
Collabase läuft standardmässig auf einem einzelnen Server. Anwendung, Datenbank, Queue, Dokument-Prozessor, Kollaborations-Relay und Reverse Proxy teilen sich eine Maschine. Diese Seite zeigt, wie du diesen Server für dein Team dimensionierst und wie du einzelne Teile auf separate Maschinen verlagerst, wenn ein Server nicht mehr reicht.

​
Was den Ressourcenbedarf bestimmt

Drei Zahlen sind wichtig, und man verwechselt sie leicht: Dimensioniere für die Spitze der gleichzeitigen Aktivität, nicht für die Gesamtzahl der Members.

​
Einen einzelnen Server dimensionieren

Wähle deine Edition und die Zahl der Benutzer, dann siehst du, was wir für den Produktivbetrieb empfehlen. Der Rechner empfiehlt nach Lizenz und Benutzerzahl. Die Tabelle darunter dimensioniert nach den Personen, die gleichzeitig arbeiten, und davon hängt die Last ab. Nutze sie, um die Empfehlung fein abzustimmen. Das sind Ausgangswerte für die Standardinstallation auf einem Server. Beginne hier und passe die Werte an, sobald das Monitoring zeigt, was wirklich gebraucht wird. Ein dokumentenlastiges Team mit ständigen PDF-Exporten braucht mehr als ein Team, das hauptsächlich liest.
Die 4 GB Minimum gelten bei eingeschalteter Live-Zusammenarbeit. Schaltest du sie aus, entfällt das Relay und die Untergrenze sinkt bei einer kleinen Installation auf 2 GB.
Der Speicherplatz wächst mit Uploads, Datenbank und täglichen Backups. Behalte ihn im Blick und vergrössere das Volume, bevor es voll ist. Siehe Speicherbedarf.

​
Über einen Server hinaus skalieren

Reicht ein einzelner Server nicht mehr, verteilst du Collabase auf mehrere Maschinen. Das ist der Fall bei dauerhaft hoher CPU-Last, bei Speicherdruck, den eine grössere Maschine nur hinausschieben würde, oder wenn du Redundanz brauchst. Geh in dieser Reihenfolge vor. Jeder Schritt nimmt dem Anwendungsserver einen Grund, gross zu sein. Horizontale Skalierung mit mehreren Anwendungs-Replikaten gibt es mit Kubernetes (Helm) und Docker Swarm. Die Docker-Installation auf einem Server skaliert nach oben (eine grössere Maschine), nicht nach aussen.

​
Uploads in einen Objektspeicher verlagern

Richte den Dateispeicher auf einen S3-kompatiblen Bucket aus statt auf die lokale Platte. Uploads liegen dann im Bucket und nicht auf dem Server. Der Anwendungsserver braucht kaum noch Datenplatte, und beliebig viele Replikate teilen sich dieselben Dateien. Setze STORAGE_DRIVER=s3 (Docker) oder storage.driver: s3 (Helm). Die vollständigen Schritte stehen unter Dateispeicher. Ein Objektspeicher ist auch Voraussetzung für mehr als ein Anwendungs-Replikat, weil nicht jedes Replikat eine eigene Kopie der Uploads halten darf.

​
Die Datenbank auf einen eigenen Server verlagern

Betreibe PostgreSQL auf einem eigenen oder verwalteten Server und richte Collabase darauf aus. Das entlastet Arbeitsspeicher und CPU des Anwendungsservers, und du kannst die Datenbank unabhängig dimensionieren und sichern.
  • Kubernetes: setze postgresql.enabled: false und postgresql.externalUrl auf die Verbindungs-URL deiner Datenbank.
  • Docker Swarm: richte DATABASE_URL auf die externe Datenbank aus und entferne den Postgres-Dienst aus dem Stack.
Die Datenbank muss PostgreSQL 16 oder neuer sein und die Erweiterung pgvector enthalten (für die KI-Suche).

​
Mehrere Anwendungs-Replikate betreiben

Liegen die Uploads in S3 und läuft die Datenbank extern, hat der Anwendungsserver keinen eigenen Zustand mehr. Dann kannst du ihn als mehrere identische Replikate hinter dem Reverse Proxy betreiben. Sie teilen sich die Last, und der Ausfall eines Replikats bleibt ohne Folgen.
1

Voraussetzungen erfüllen

Du brauchst einen Objektspeicher (storage.driver: s3) und einen eigenen Worker, damit Hintergrundjobs an genau einer Stelle laufen. Setze bei Helm workers.separate: true.
2

Replikatzahl erhöhen

Setze bei Helm replicaCount auf die gewünschte Zahl von Anwendungsinstanzen. Docker Swarm nutzt die Einstellung replicas des Dienstes. Das Chart verweigert replicaCount > 1 ohne Objektspeicher, weil lokale Uploads nicht geteilt werden können.

​
Das Kollaborations-Relay im grossen Massstab

Das Relay ist ein einzelner Prozess und verarbeitet auf einer Instanz sehr viele Verbindungen über alle Dokumente hinweg. Für typische Installationen braucht es weder einen Cluster noch Redis. Die praktische Grenze liegt pro Dokument: Eine Seite mit Dutzenden gleichzeitigen Bearbeitenden ist unproblematisch. Erst sehr grosse Sitzungen auf einer einzigen Seite (etwa hundert Personen gleichzeitig) erreichen den Punkt, an dem der Cursor-Verkehr überwiegt. Brauchst du mehr als eine Relay-Instanz, zur Redundanz oder bei extremer Last, braucht das Relay ein gemeinsames Redis zur Abstimmung. Das ist ein Setup für eine Skalierungsberatung und keine Standardeinstellung.
Zuletzt geändert am 5. November 2026