EU-Cowork selbst hosten

Was ihr braucht

Für EU-Cowork braucht ihr eine Ubuntu-Maschine mit Docker Engine und Compose v2, einen DNS-Eintrag darauf und einen API-Schlüssel eures Modell-Gateways. Der Stack läuft vollständig auf diesem einen Host, denn die Rechenlast der Sprachmodelle liegt beim Inferenz-Anbieter.

Server und Systemanforderungen

Das Minimum sind 2 vCPU, 4 GB RAM, 40 GB Platte und Ubuntu 22.04 LTS. Für den Produktivbetrieb empfohlen sind 4 vCPU, 16 GB RAM und 200 GB Platte auf Ubuntu 24.04 LTS; die Aufteilung nach Team-Grösse steht in der Tabelle unten. Die gehärtete Code-Sandbox setzt zusätzlich nested Virtualisierung voraus.

Unter Last wächst praktisch nur der Speicher der Chat-Anwendung, die CPU-Auslastung bleibt nahe null. Die Images belegen einmalig rund 5 bis 6 GB und werden zwischen Instanzen auf derselben Maschine geteilt. Danach wachsen vor allem die Uploads: Die erste Grenze im Betrieb ist der Plattenplatz.

Was ihr nicht braucht

• Kein Kubernetes. Docker Compose ist die unterstützte Bauform, ein Helm-Chart wird nicht mitgeliefert.
• Keine GPU für den App-Tier. GPU-Hardware braucht nur, wer Sprachmodelle zusätzlich lokal ausführen will.
• Kein Konto bei uns. Die Installation läuft ohne Registrierung, ohne Lizenzschlüssel und ohne Lizenzserver.
• Keinen Hyperscaler und keine verwaltete Datenbank. Jede Ubuntu-VM genügt, Datenbank und Suchindex laufen im selben Stack.

Installation in drei Schritten

Die Installation von EU-Cowork besteht aus zwei Skripten und einem Eintrag in der .env. Auf einer Maschine, auf der Docker bereits läuft, entfällt der erste Schritt.

Schritt 1: Server vorbereiten

Das Release-Repository wird mit dem Launch veröffentlicht. Wer heute schon testen will, fordert den Zugang über die Warteliste an. Die Befehle zeigen, wie die Installation danach aussieht: Repository klonen, in das Verzeichnis distribution wechseln, Vorbereitungsskript starten.

cd distribution
./setup-server.sh

Das Skript ist idempotent und installiert Docker Engine samt Compose v2 aus der offiziellen Docker-Quelle, weil das Ubuntu-Paket docker.io kein Compose v2 mitbringt. Dazu kommen Log-Rotation, Firewall-Regeln für die Ports 22, 80 und 443, Swap, Zeitzone und automatische Security-Updates. Danach einmal neu einloggen.

Schritt 2: Stack installieren

./install.sh --profiles production

Der Installer prüft Docker und Compose v2, erzeugt die .env aus der Vorlage, generiert alle Secrets, legt Datenverzeichnisse und Sandbox-Netz an, zieht die Images und startet den Stack. Das Profil production bringt den Reverse-Proxy mit, der das TLS-Zertifikat automatisch holt.

Schritt 3: Modell-Zugang eintragen

# .env
EUROUTER_API_KEY=<euer-api-key>

docker compose up -d

Ohne Schlüssel startet der Stack, aber der Chat meldet einen fehlenden API-Schlüssel. Der Zugang ist frei wählbar, denn EU-Cowork spricht jedes OpenAI-kompatible Gateway an. Über EuRouter stehen über 100 Modelle mit EU-Verarbeitung unter einem Zugang, alternativ tragt ihr euren eigenen Endpunkt ein.

Aus welchen Diensten der Stack besteht

Der Stack besteht aus einer docker-compose.yml; mehrere Dienste liegen hinter optionalen Profilen und starten nur, wenn ihr sie einschaltet. Jeder Dienst ist ein bekanntes Open-Source-Projekt und lässt sich einzeln inspizieren, ersetzen oder abschalten.

Die Chat-Anwendung basiert auf LibreChat unter MIT-Lizenz und liefert Oberfläche, Konten, Konversationen, Datei-Uploads und die Modell-Anbindung. EU-Cowork hält diesen Teil nah am Upstream, damit Sicherheits-Updates des Projekts übernehmbar bleiben.

MongoDB speichert Konversationen, Konten, Rollen und Einstellungen, als Container im selben Stack und auf eurer Platte. Einen externen Datenbankdienst, an den Inhalte abfliessen könnten, gibt es nicht.

Meilisearch liefert die Volltextsuche über die eigenen Konversationen. Der Index liegt lokal und lässt sich neu aufbauen; die Telemetrie von Meilisearch ist ab Werk abgeschaltet.

Die RAG-API mit pgvector ist optional und kommt über das Profil filesearch dazu. Die RAG-API bettet Dateien ein, die Nutzer in den Chat hochladen, und liefert dem Modell beim Antworten die passenden Stellen zurück.

Das MCP-Gateway sitzt zwischen der Chat-Anwendung und jedem angebundenen System und entscheidet pro Tool-Aufruf, ob er erlaubt ist. Ausgewertet wird in dieser Reihenfolge: einzelner Nutzer, Rolle, Gruppe, Voreinstellung des Servers. Jeder Aufruf wird protokolliert, und fällt die Prüfung aus, wird der Zugriff verweigert.

Das Admin-Panel ist die Oberfläche für Nutzer, Rollen, Gruppen, Zugriffsregeln, Audit-Log und Budget. Es gehört zum Stack, lauscht nur lokal und ist von aussen ausschliesslich über den Reverse-Proxy erreichbar.

Die Code-Sandbox führt den vom Modell erzeugten Code aus, damit aus einer Anfrage eine echte Datei zum Herunterladen wird. Sie wird als eigener Compose-Stack danebengestellt und über ein eigenes Docker-Netz angebunden. Zwei Backends stehen zur Wahl: ein leichtgewichtiges als Voreinstellung und ein gehärtetes auf Basis einer microVM, das nested Virtualisierung auf dem Host voraussetzt. Ein Egress-Proxy mit Freigabeliste ist in Arbeit.

SearXNG liefert die Websuche aus eurem eigenen Stack, ohne Konto bei einem Suchdienst. Ehrlich dazugesagt: SearXNG reicht die Suchbegriffe an externe Suchmaschinen weiter, ohne die Identität des Nutzers mitzugeben. Konversationen und Dateien verlassen die Maschine nicht.

Caddy terminiert TLS, holt die Zertifikate automatisch, sobald der DNS-Eintrag auf die Maschine zeigt, und ist der einzige Dienst auf den Ports 80 und 443. Für den Betrieb hinter einer WAF oder mit interner Zertifizierungsstelle liegen Varianten bei.

Drei Betriebsmodelle, eine Bauform

Es gibt drei Betriebsmodelle und nur eine Bauform: selbst betrieben, in eurer Cloud, wahlweise durch euren IT-Dienstleister, oder von uns betreut. Der Stack ist in allen drei Fällen derselbe. Unterschiedlich ist nur, wer Root hat, wer die Schlüssel verwaltet und wer Updates und Backups fährt.

Selbst betrieben

Ihr betreibt die Maschine, haltet Root, verwaltet eure Schlüssel und fahrt Updates und Backups selbst. Die Software kostet nichts, ein Support-Abo ist optional. Dieses Modell ist der Massstab: Was ein fremder Administrator in zwei Kommandos hochbekommt, trägt auch die anderen Modelle.

In eurer Cloud

EU-Cowork läuft auf jeder Ubuntu-VM, im eigenen Rechenzentrum ebenso wie bei einem Schweizer oder europäischen Cloud-Anbieter. Eine Bindung an einen Hyperscaler gibt es nicht. Wer als IT-Dienstleister für seine Kunden hostet, nutzt dieselbe Bauform: pro Kunde ein Stack.

Von uns betreut

Wir übernehmen Installation, Updates, Backups und Monitoring und betreiben die Instanz in ISO-27001-zertifizierten Rechenzentren von Green in Lupfig, Schweiz. Die Zertifikate liegen bei Green, nicht bei EU-Cowork; die eigene ISO-27001-Zertifizierung von EU-Cowork ist in Arbeit.

Mehrere Instanzen auf einer Maschine

Die Mandanten-Grenze ist der Compose-Stack, nicht die VM: Jede Instanz hat eigene Datenbank, eigenen Suchindex, eigene Uploads, eigene Secrets, eigenes Docker-Netz und eigene Code-Sandbox. Für kleine Teams dürfen deshalb drei bis fünf Instanzen dieselbe VM teilen.

Geteilt werden dürfen die Docker-Images und ein gemeinsamer Reverse-Proxy. Nie geteilt werden Datenbank, Uploads, Secrets, Sandbox-Netz und der Schlüssel des Modell-Anbieters: Ein geteilter Schlüssel macht den Verbrauch pro Mandant unauflösbar, ein geteiltes Sandbox-Netz hebt die Trennung dort auf, wo fremder Code läuft.

Wie Updates laufen und was im Betrieb zählt

Updates sind reproduzierbar, weil das Anwendungs-Image auf einen Digest gepinnt ist statt auf einen beweglichen Tag und die übrigen Dienste auf festen Versionsständen laufen. Ein EU-Cowork-Release ist damit eine getestete Kombination aus Anwendungs-Image und Diensten, und zwei Instanzen auf derselben Maschine dürfen unterschiedliche Stände fahren.

git pull
./backup.sh backup
./install.sh --migrate

Die Option --migrate lässt die .env unangetastet und baut die eigenen Dienste neu. Vor jedem Update gehört ein Backup, danach ein kurzer Funktionstest. Zurück geht es über den vorherigen Stand der Compose-Datei.

Im laufenden Betrieb sind zwei Dinge wichtig: die Log-Rotation, die setup-server.sh einrichtet, und der Plattenplatz mit einem Alarm ab 70 Prozent Belegung. Wiederkehrende Fragen zu Betrieb, Updates und Datensicherung beantworten die häufigen Fragen.

Ein Skript für Sicherung, Wiederherstellung und Umzug

Ein einziges Skript deckt Sicherung, Wiederherstellung und Serverumzug ab: backup.sh erzeugt ein Archiv aus Datenbank-Dump, .env und hochgeladenen Dateien und spielt es auch wieder zurück. Ein Umzug ist damit Backup auf dem alten Server, Archiv kopieren, Wiederherstellung auf dem neuen.

./backup.sh backup            # Archiv erzeugen
./backup.sh list              # vorhandene Archive
./backup.sh restore <archiv>  # ersetzt die Datenbank, fragt vorher nach

Das Archiv enthält Secrets und Konversationen und wird mit engen Dateirechten abgelegt. Es gehört nie in ein Repository und nie unverschlüsselt in eine fremde Cloud. Der Suchindex wird nicht mitgesichert, weil er sich aus der Datenbank neu aufbauen lässt.

Der teuerste Fehler beim Umzug ist, die Verschlüsselungs-Schlüssel neu generieren zu lassen statt sie aus der alten .env zu übernehmen. Danach sind alle in der Datenbank abgelegten Zugangsdaten unlesbar. Mit übernommenen Werten bleibt der Umzug ein Wartungsfenster von 15 bis 30 Minuten.

Zwei Regeln aus dem Betrieb: das Backup-Ziel ausserhalb der Maschine spiegeln und den Restore einmal testen.

Lizenz: was MIT konkret bedeutet

EU-Cowork steht unter der MIT-Lizenz, ebenso die zugrunde liegende Chat-Anwendung LibreChat. Self-Hosting ist gratis, ab einem Nutzer und ohne Registrierung bei uns. Was das im Einzelnen bedeutet, und warum es im Vergleich mit anderen Plattformen der entscheidende Unterschied ist:

• Kein Seat-Limit. Ob 3 oder 300 Personen auf der Instanz arbeiten, ändert an der Lizenz nichts.
• Kein Branding-Zwang. Name, Logo und Farben sind Konfiguration, auch für den kommerziellen Einsatz.
• Kein Feature-Gating. Rechteverwaltung, Audit-Log, Budgets und Systemanbindungen stammen aus derselben offenen Quelle.
• Offener Quellcode. Die Basis LibreChat ist heute öffentlich einsehbar; Stack, Skripte und Dienste erscheinen mit dem Launch unter MIT und sind dann einsehbar, forkbar und prüfbar, statt auf Zusage zu beruhen.

Kommerziell tragen wir das Modell über Betrieb und Betreuung, nicht über Lizenzen. Deshalb ist auch der Weg vom betreuten Betrieb zurück in den Selbstbetrieb offen: dieselbe Bauform, dasselbe Archiv.

Häufige Fragen zum Selbstbetrieb