Mit Docker betreiben

WorkOffice Pro läuft auf dem eigenen Server mit Docker Compose – auf einem Root-Server, im Büro oder bei einem Hoster. Der Aufbau ist derselbe wie bei WorkTime Pro; beide laufen auf demselben Server nebeneinander, hinter einem gemeinsamen Caddy.

Dieser Artikel beschreibt den Aufbau. Die Schritte zur ersten Einrichtung stehen unter Einrichten.

Was der Server braucht

• Linux mit Docker und Docker Compose (Docker 24 oder neuer) und 2 GB Arbeitsspeicher. Die Texterkennung des Belegeingangs braucht je laufender Erkennung kurz einen Prozessorkern und rund 300–500 MB dazu; mit der Vorgabe BELEGEINGANG_GLEICHZEITIG=1 reichen 2 GB.
• Einen Namen im Netz, etwa buero.ihrbetrieb.de, der auf den Server zeigt – für HTTPS.
• Rund 8 GB freien Platz für den ersten Bau. Wird es eng: docker builder prune -af und docker image prune -af.

Die Compose-Dateien

Alle Befehle laufen mit dem Projektnamen -p workoffice:

docker compose -p workoffice -f docker-compose.selfhost.yml up -d --build

Der feste Projektname hält WorkOffice und WorkTime Pro (-p worktime) auseinander: eigene Container, eigene Volumes, eigenes Netz.

Die Dienste

Nur die Oberfläche hat einen Port. Die Datenbank braucht allein die API im selben Netz – ein offener Port 5432 wäre der kürzeste Weg zu allen Rechnungen und Kundendaten. Den Port 3100 bindet WEB_BIND=127.0.0.1 an die Loopback-Adresse, sobald Caddy davor steht (siehe HTTPS mit Caddy).

Die Volumes

Beides gehört in jede Sicherung. Achtung: docker compose down -v wirft die Volumes weg.

Was beim Start der API geschieht

Der Start spielt die Migrationen ein, dann die Mandantentrennung (Row-Level-Security) und die GoBD-Sperren, und legt den Anwendungsbenutzer ohne Sonderrechte an bzw. frischt seine Rechte auf. Ein Handgriff an der Datenbank ist dafür nicht nötig – weder bei der Einrichtung noch bei einer Aktualisierung. Greift die Mandantentrennung danach nicht, bricht die API ab, statt unsicher zu laufen (siehe PostgreSQL).

Am Dienst api hängt ein Zustandstest auf /api/ready. docker compose … ps zeigt den Container damit als healthy – oder als unhealthy, sobald er zwar läuft, aber die Datenbank nicht mehr erreicht. Die ersten 120 Sekunden gelten als Anlaufzeit, denn Migrationen laufen vor dem Start.

Fertige Abbilder statt Bau

Wer eine Lizenz für den eigenen Server hat, kann statt aus dem Quellcode zu bauen die fertigen Abbilder workoffice-api und workoffice-web aus der Registry des Herstellers (ghcr.io) laden. Den Zugang dazu gibt der Hersteller. Dann kommt docker-compose.kunde.yml dazu:

docker login ghcr.io
docker compose -p workoffice -f docker-compose.selfhost.yml -f docker-compose.kunde.yml pull
docker compose -p workoffice -f docker-compose.selfhost.yml -f docker-compose.kunde.yml up -d

Die Ergänzung tut drei Dinge: Sie nimmt die fertigen Abbilder, schaltet die Lizenzprüfung ein und die Abo-Abrechnung aus – auf dem eigenen Server ersetzt die Lizenz das Abo. Eine bestimmte Fassung statt der neuesten legt WORKOFFICE_VERSION=1.2.3 in der .env fest.

Die Skripte für Sicherung und Aktualisierung setzen diesen Aufbau voraus: Projekt workoffice, Container workoffice-*, Verzeichnis /opt/workoffice-pro.