Komodo mit Docker Compose installieren und betreiben

Wer Docker-Container auf mehr als einem Server betreibt, kennt das Problem: Portainer und Dockge sind auf einer einzelnen Maschine schnell eingerichtet, aber sobald drei oder fünf Hosts dazukommen, wird aus der Verwaltung ein Sammelsurium aus Browser-Tabs und SSH-Sitzungen. Komodo setzt genau hier an. Das quelloffene Werkzeug verwaltet Builds, Deployments und Stacks über beliebig viele Server hinweg und bringt dafür eine eigene Agent-Komponente mit. Diese Anleitung zeigt die vollständige Einrichtung per Docker Compose, den Betrieb im Alltag, Backup und Wiederherstellung sowie die typischen Fehlerbilder.

Was Komodo leistet und wo die Grenzen liegen

Komodo ist eine Weboberfläche zum Bauen und Ausrollen von Software auf vielen Servern gleichzeitig. Es liest Git-Repositories, baut Images, startet Compose-Stacks und zeigt Logs und Ressourcenverbrauch der angebundenen Hosts. Die Anzahl der verbundenen Server ist nicht begrenzt. Das Projekt steht unter der GPL-3.0 und wird unter github.com/moghtech/komodo entwickelt.

Die Entwickler weisen im README selbst darauf hin, dass es keine Gewährleistung gibt und die Nutzung auf eigenes Risiko erfolgt. Das ist bei einem Werkzeug, das faktisch Vollzugriff auf mehrere Docker-Hosts erhält, kein Nebensatz, sondern eine Planungsgrundlage.

Wann sich der Aufwand lohnt und wann nicht:

• Ein einzelner Docker-Host, wenige Stacks, keine Build-Pipeline: Dockge oder Portainer reichen aus und sind in Minuten eingerichtet.
• Zwei bis drei Server ohne gemeinsame Deployment-Logik: Portainer mit Agents deckt das gut ab.
• Mehrere Server, Images sollen aus Git gebaut und automatisch ausgerollt werden: hier spielt Komodo seine Stärke aus.
• Zentrale Ansicht über Container, Logs, Ressourcen und geplante Prozeduren auf allen Hosts: dafür ist Komodo gemacht.
• Kubernetes-Cluster: falsches Werkzeug, Komodo verwaltet Docker, nicht Kubernetes.
• Streng regulierte Umgebungen mit Auditpflicht: die fehlende Gewährleistung und die weitreichenden Docker-Rechte müssen vorher bewertet werden.

Architektur: Core, Periphery und Datenbank

Komodo besteht aus zwei Programmteilen. Der Core liefert die Weboberfläche und die API und spricht mit einer Datenbank. Die Periphery ist der Agent, der auf jedem verwalteten Server läuft und dort die Docker-Befehle ausführt. Auf dem Server, auf dem der Core läuft, wird üblicherweise gleich eine Periphery mitinstalliert, damit dieser Host ebenfalls verwaltet werden kann.

Komponente	Image	Port	Aufgabe
Core	ghcr.io/moghtech/komodo-core	9120	Weboberfläche, API, Zeitplanung, Datenbankzugriff
Periphery	ghcr.io/moghtech/komodo-periphery	8120 (intern)	Agent auf jedem verwalteten Server, führt Docker-Befehle aus
CLI	ghcr.io/moghtech/komodo-cli	keiner	Backup und Wiederherstellung der Datenbank, auch entfernt nutzbar
Datenbank	MongoDB oder FerretDB auf Postgres	27017 (intern)	Speichert Ressourcen, Berechtigungen, Updates und Statistiken

Core und Periphery tauschen über ein gemeinsames Volume unter /config/keys Schlüssel aus. Der Core bekommt dazu die Variable KOMODO_PERIPHERY_PUBLIC_KEY=file:/config/keys/periphery.pub, die Periphery entsprechend den öffentlichen Schlüssel des Core. Auf einem einzelnen Host erledigt die offizielle Compose-Datei das automatisch.

Voraussetzungen und Ressourcen

Die Installation wurde am 12. September 2026 auf einem Ubuntu-Testsystem mit Docker 29.1.3 und Docker Compose 2.40.3 durchgeführt. Benötigt werden:

• Ein Linux-Host mit installierter Docker Engine und dem Compose-Plugin. Der Befehl lautet docker compose, nicht docker-compose.
• Root-Rechte oder ein Benutzer in der Gruppe docker, weil Periphery den Docker-Socket einbindet.
• Freier Port 9120 auf dem Host für die Weboberfläche.
• Ein Verzeichnis /etc/komodo für Periphery-Daten und Backups. Der Pfad muss innerhalb und außerhalb des Containers identisch sein.
• Ausgehender Zugriff auf ghcr.io und raw.githubusercontent.com.
• Mindestens 2 GB Arbeitsspeicher für Core und Datenbank zusammen, mehr wenn Images gebaut werden sollen.
• Plattenplatz für den Repo-Cache und die Backups. Backups sind gzip-komprimiert und bleiben klein, gebaute Images nicht.

Plattformen und die MongoDB-Einschränkung

Komodo bietet laut offizieller Dokumentation zwei Datenbank-Varianten an: MongoDB als Empfehlung oder FerretDB auf Postgres als Alternative. Die Dokumentation weist ausdrücklich darauf hin, dass manche Systeme die neueren MongoDB-Versionen nicht unterstützen und betroffene Nutzer FerretDB verwenden sollen. Der praktische Hintergrund: aktuelle MongoDB-Builds setzen CPU-Erweiterungen voraus, die ältere Prozessoren nicht bieten.

Auf dem Testsystem war genau das der Fall. Der erste Versuch mit der offiziellen mongo.compose.yaml endete in einer Neustart-Schleife des MongoDB-Containers mit Exit-Code 132. Im Log stand ein Hinweis auf fehlende CPU-Unterstützung sowie die Meldung Illegal instruction (core dumped). Die Prüfung mit grep -o -w avx /proc/cpuinfo lieferte keine Ausgabe, die CPU meldet also kein AVX-Flag. Danach lief der Wechsel auf die ferretdb.compose.yaml ohne weitere Anpassung durch.

Prüfen Sie das vor der Installation:

# Pruefen, ob die CPU das AVX-Flag meldet
# Keine Ausgabe bedeutet: kein AVX, MongoDB scheidet aus
grep -o -w avx /proc/cpuinfo | head -n 1

# Docker- und Compose-Version pruefen
docker --version
docker compose version

Liefert der erste Befehl keine Ausgabe, wählen Sie direkt die FerretDB-Variante. Liefert er avx, können Sie zwischen beiden Varianten frei wählen. Diese Anleitung nutzt durchgehend FerretDB, weil sie auf jeder CPU funktioniert.

Geprüfter Versionsstand

Alle Angaben wurden am 12. September 2026 gegen das offizielle Repository und die Dokumentation geprüft:

• Aktuelles Release: v2.3.3, veröffentlicht am 1. September 2026.
• Vorherige Releases: v2.3.2 vom 11. August 2026, v2.3.1 vom 31. Juli 2026.
• Letzter Push ins Repository: 1. September 2026. Das Projekt wird also aktiv gepflegt und ist nicht archiviert.
• Popularität: 12.222 Sterne auf GitHub, Stand 12. September 2026, Quelle ist das Repository moghtech/komodo.
• Lizenz: GPL-3.0, ohne Gewährleistung, Nutzung auf eigenes Risiko.

Der Image-Tag 2 aus der offizielen Variablen-Datei folgt der Major-Version. Wer einen festen Stand möchte, trägt stattdessen 2.3.3 ein. Auf dem Testsystem bestätigte das Core-Log die Zeile Komodo Core version: v2.3.3.

Installation Schritt für Schritt

Die folgenden Schritte legen ein Arbeitsverzeichnis an, holen die offiziellen Dateien und bereiten die Verzeichnisse vor.

# Arbeitsverzeichnis anlegen
mkdir -p /opt/komodo
cd /opt/komodo

# Verzeichnis fuer Periphery-Daten und Backups anlegen
mkdir -p /etc/komodo/backups

# Offizielle Compose-Datei mit FerretDB herunterladen
curl -fsSL -o compose.yaml \
  https://raw.githubusercontent.com/moghtech/komodo/main/compose/ferretdb.compose.yaml

# Offizielle Variablen-Datei herunterladen
curl -fsSL -o compose.env \
  https://raw.githubusercontent.com/moghtech/komodo/main/compose/compose.env

# Variablen-Datei gegen fremde Leserechte schuetzen
chmod 600 compose.env

Anschließend werden die Zufallswerte für die Secrets erzeugt. Tippen Sie keine eigenen Zeichenketten ab, sondern nutzen Sie openssl:

# Drei getrennte Zufallswerte erzeugen
# Die Ausgabe jeweils in die passende Zeile der compose.env eintragen
openssl rand -base64 32
openssl rand -base64 32
openssl rand -base64 32

Die drei Ausgaben kommen in KOMODO_WEBHOOK_SECRET, KOMODO_JWT_SECRET und KOMODO_DATABASE_PASSWORD. Zusätzlich brauchen Sie ein eigenes Passwort für KOMODO_INIT_ADMIN_PASSWORD. Der ausgelieferte Standardwert lautet changeme und muss zwingend ersetzt werden, bevor der Stack das erste Mal startet.

Die Compose-Datei im Überblick

So sieht die FerretDB-Variante aus. Sie entspricht der offiziellen Datei aus dem Repository und enthält die vier Dienste Postgres, FerretDB, Core und Periphery.

# ferretdb.compose.yaml
# Offizielle Komodo-Compose-Datei mit FerretDB auf Postgres
# Quelle: https://raw.githubusercontent.com/moghtech/komodo/main/compose/ferretdb.compose.yaml
services:
  postgres:
    image: ghcr.io/ferretdb/postgres-documentdb:17-0.107.0-ferretdb-2.5.0
    container_name: komodo-postgres
    labels:
      komodo.skip: ""
    restart: unless-stopped
    logging:
      driver: local
    volumes:
      - pg-data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: ${KOMODO_DATABASE_USERNAME}
      POSTGRES_PASSWORD: ${KOMODO_DATABASE_PASSWORD}
      POSTGRES_DB: postgres

  ferretdb:
    image: ghcr.io/ferretdb/ferretdb:2.5.0
    container_name: komodo-ferretdb
    labels:
      komodo.skip: ""
    restart: unless-stopped
    depends_on:
      - postgres
    logging:
      driver: local
    environment:
      FERRETDB_POSTGRESQL_URL: postgres://${KOMODO_DATABASE_USERNAME}:${KOMODO_DATABASE_PASSWORD}@postgres:5432/postgres

  core:
    image: ghcr.io/moghtech/komodo-core:${COMPOSE_KOMODO_IMAGE_TAG:-latest}
    container_name: komodo-core
    labels:
      komodo.skip: ""
    restart: unless-stopped
    depends_on:
      - ferretdb
    ports:
      - 9120:9120
    env_file: ./compose.env
    environment:
      KOMODO_DATABASE_ADDRESS: ferretdb:27017
      KOMODO_DATABASE_USERNAME: ${KOMODO_DATABASE_USERNAME}
      KOMODO_DATABASE_PASSWORD: ${KOMODO_DATABASE_PASSWORD}
      KOMODO_PERIPHERY_PUBLIC_KEY: file:/config/keys/periphery.pub
    volumes:
      - repo-cache:/repo-cache
      - keys:/config/keys
      - ${COMPOSE_KOMODO_BACKUPS_PATH}:/backups

  periphery:
    image: ghcr.io/moghtech/komodo-periphery:${COMPOSE_KOMODO_IMAGE_TAG:-latest}
    container_name: komodo-periphery
    labels:
      komodo.skip: ""
    restart: unless-stopped
    env_file: ./compose.env
    environment:
      PERIPHERY_ROOT_DIRECTORY: /etc/komodo
      PERIPHERY_DISABLE_TERMINALS: ${PERIPHERY_DISABLE_TERMINALS:-false}
      PERIPHERY_CORE_PUBLIC_KEY: file:/config/keys/core.pub
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /proc:/proc
      - /etc/komodo:/etc/komodo
      - keys:/config/keys

volumes:
  pg-data:
  repo-cache:
  keys:

Drei Details verdienen Aufmerksamkeit. Erstens bindet der Periphery-Container /var/run/docker.sock und /proc ein, er braucht diesen Zugriff zwingend. Zweitens ist das Verzeichnis /etc/komodo auf beiden Seiten des Doppelpunkts identisch. Drittens hängt das Backup-Verzeichnis über ${COMPOSE_KOMODO_BACKUPS_PATH}:/backups im Core, sonst landen Backups nur im Container und sind beim nächsten Neustart weg.

Die Variablen-Datei compose.env

Die Compose-Datei allein reicht nicht. Fast alle Einstellungen kommen aus compose.env. Hier eine kommentierte Fassung mit klar erkennbaren Beispielwerten:

# compose.env
# Variablen-Datei fuer Komodo Core und Periphery
# Quelle: https://raw.githubusercontent.com/moghtech/komodo/main/compose/compose.env

# Image-Tag der Komodo-Images. "2" folgt der Major-Version 2.
COMPOSE_KOMODO_IMAGE_TAG=2

# Host-Pfad, in den Core seine Datenbank-Backups schreibt
COMPOSE_KOMODO_BACKUPS_PATH=/etc/komodo/backups

# Zugangsdaten der Datenbank. Beispielwerte, unbedingt ersetzen.
KOMODO_DATABASE_USERNAME=beispiel_db_user
KOMODO_DATABASE_PASSWORD=BEISPIEL_DB_PASSWORT_ERSETZEN

# Zeitzone fuer Logs und geplante Prozeduren
TZ=Europe/Berlin

# Adresse, unter der die Oberflaeche spaeter erreichbar ist
KOMODO_HOST=https://komodo.example.com
KOMODO_TITLE=Komodo

# Lokale Benutzername-Passwort-Anmeldung aktivieren
KOMODO_LOCAL_AUTH=true

# Initialer Administrator. Passwort vor dem ersten Start ersetzen.
KOMODO_INIT_ADMIN_USERNAME=admin
KOMODO_INIT_ADMIN_PASSWORD=BEISPIEL_ADMIN_PASSWORT_ERSETZEN

# Name, unter dem der erste Server in der Oberflaeche auftaucht
KOMODO_FIRST_SERVER_NAME=Local

# Secrets. Mit openssl erzeugen, nicht abtippen.
KOMODO_WEBHOOK_SECRET=BEISPIEL_WEBHOOK_SECRET_ERSETZEN
KOMODO_JWT_SECRET=BEISPIEL_JWT_SECRET_ERSETZEN

# Gueltigkeit der Anmelde-Token: 1-hr, 12-hr, 1-day, 3-day, 1-wk, 2-wk
KOMODO_JWT_TTL=1-day

# Sicherheitsabfragen vor destruktiven Aktionen beibehalten
KOMODO_DISABLE_CONFIRM_DIALOG=false

# Standardgroesse der Listen-Seiten in der Oberflaeche
KOMODO_DEFAULT_PAGINATION_LIMIT=50

Die wichtigsten Variablen im Einzelnen:

Variable	Standard	Bedeutung
COMPOSE_KOMODO_IMAGE_TAG	2	Image-Tag der Komodo-Images. Feste Version eintragen, wenn Updates kontrolliert erfolgen sollen.
COMPOSE_KOMODO_BACKUPS_PATH	/etc/komodo/backups	Host-Pfad, der im Core nach /backups gemountet wird.
KOMODO_DATABASE_USERNAME	leer	Benutzername der Datenbank. Wird von Postgres, FerretDB und Core gleichermaßen genutzt.
KOMODO_DATABASE_PASSWORD	leer	Passwort der Datenbank. Per openssl rand -base64 32 erzeugen.
TZ	leer	Zeitzone für Logs und geplante Prozeduren, zum Beispiel Europe/Berlin.
KOMODO_HOST	leer	Vollständige Adresse der Oberfläche. Wird unter anderem für Webhook-Links gebraucht.
KOMODO_TITLE	Komodo	Titel, der in der Oberfläche angezeigt wird.
KOMODO_LOCAL_AUTH	false	Schaltet die Anmeldung mit Benutzername und Passwort frei.
KOMODO_INIT_ADMIN_USERNAME	admin	Benutzername des beim ersten Start angelegten Administrators.
KOMODO_INIT_ADMIN_PASSWORD	changeme	Passwort des ersten Administrators. Muss vor dem ersten Start geändert werden.
KOMODO_FIRST_SERVER_NAME	Local	Anzeigename des ersten Servers in der Oberfläche.
KOMODO_WEBHOOK_SECRET	leer	Gemeinsames Geheimnis, mit dem eingehende Webhooks geprüft werden.
KOMODO_JWT_SECRET	leer	Signaturschlüssel der Anmelde-Token. Ändern macht alle Sitzungen ungültig.
KOMODO_JWT_TTL	1-day	Gültigkeitsdauer der Token. Mögliche Werte: 1-hr, 12-hr, 1-day, 3-day, 1-wk, 2-wk.
KOMODO_DISABLE_CONFIRM_DIALOG	false	Schaltet die Sicherheitsabfrage vor Aktionen ab. Im Produktivbetrieb auf false lassen.
KOMODO_DEFAULT_PAGINATION_LIMIT	50	Anzahl der Einträge pro Seite in Listenansichten.

Start und Erstanmeldung

Wichtig: Der Aufruf muss die Variablen-Datei ausdrücklich mitgeben. Ohne --env-file compose.env bleiben KOMODO_DATABASE_USERNAME, KOMODO_DATABASE_PASSWORD und COMPOSE_KOMODO_BACKUPS_PATH leer, und der Start schlägt fehl oder erzeugt eine Datenbank ohne Zugangsdaten.

# Stack starten. Die Variablen-Datei muss explizit mitgegeben werden.
docker compose --env-file compose.env up -d

# Status aller vier Container pruefen
docker compose --env-file compose.env ps

# Log von Core ansehen
docker compose --env-file compose.env logs core

Auf dem Testsystem zeigten sich danach vier laufende Container: komodo-core mit Status Up, komodo-ferretdb mit Status Up und healthy, komodo-periphery mit Status Up und komodo-postgres mit Status Up. Das Core-Log enthielt die Zeilen Komodo Core version: v2.3.3, Creating init admin user..., Successfully created init admin user. und Server starting on http://[::]:9120.

Danach die Oberfläche unter http://SERVER-IP:9120 aufrufen und mit den Werten aus KOMODO_INIT_ADMIN_USERNAME und KOMODO_INIT_ADMIN_PASSWORD anmelden. Direkt nach der ersten Anmeldung sollten Sie:

• Das Administrator-Passwort in der Oberfläche erneut setzen, damit es nicht dauerhaft in der Variablen-Datei steht.
• Den ersten Server unter dem Namen aus KOMODO_FIRST_SERVER_NAME prüfen und seinen Verbindungsstatus kontrollieren.
• Die vorhandene Prozedur Backup Core Database öffnen und den Zeitplan bestätigen.
• Weitere Benutzer nur mit den Rechten anlegen, die sie wirklich brauchen.
• Prüfen, dass KOMODO_DISABLE_CONFIRM_DIALOG auf false steht.

Funktions- und Healthcheck

Nach dem Start gehören zwei Prüfungen zur Routine: antwortet die Oberfläche, und laufen alle Container stabil.

# HTTP-Status der Weboberflaeche pruefen, erwartet wird 200
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9120

# Laufende Container mit Status anzeigen
docker ps --filter name=komodo --format "{{.Names}}\t{{.Status}}"

Auf dem Testsystem antwortete die Weboberfläche mit HTTP-Status 200 und lieferte die HTML-Seite aus. Wenn stattdessen eine leere Antwort oder ein Verbindungsfehler kommt, lohnt der Blick in die Logs:

# Log eines einzelnen Dienstes verfolgen
docker compose --env-file compose.env logs -f core

# Log der Datenbank pruefen
docker compose --env-file compose.env logs postgres

# Zusammengefasster Status mit Exit-Codes
docker compose --env-file compose.env ps -a

Achten Sie besonders auf Container, die in ps -a mit einem Exit-Code auftauchen oder deren Status zwischen Restarting und Up wechselt. Eine Neustart-Schleife ist immer ein Hinweis auf ein Problem beim Start, nicht auf eine langsame Initialisierung.

Persistente Daten und Rechte

Komodo legt seine Daten an vier Stellen ab. Wer davon eine übersieht, verliert beim nächsten Umzug Daten.

• pg-data: Docker-Volume mit der eigentlichen Datenbank. Das ist der Kern, ohne dieses Volume ist die Installation leer.
• repo-cache: Docker-Volume mit ausgecheckten Git-Repositories. Kann bei Bedarf verworfen werden, wird neu befüllt.
• keys: Docker-Volume mit den Schlüsseln zwischen Core und Periphery.
• /etc/komodo auf dem Host: Arbeitsverzeichnis der Periphery und Ablageort der Backups unter /etc/komodo/backups.

Die Datei compose.env enthält Datenbankpasswort, JWT-Signaturschlüssel und Webhook-Geheimnis im Klartext. Sie gehört mit chmod 600 gegen fremde Leserechte gesichert und niemals in ein Git-Repository. Das Verzeichnis /etc/komodo sollte ebenfalls nur für root lesbar sein, weil dort Backups mit allen Ressourcen und Berechtigungen liegen.

Sichere Netzwerkfreigabe und Reverse Proxy

Das Wichtigste vorweg als Sicherheitshinweis: Der Periphery-Container bindet den Docker-Socket ein. Wer Zugriff auf Komodo hat, hat damit faktisch Zugriff auf den Docker-Daemon des jeweiligen Servers und kann darauf beliebige Container mit beliebigen Rechten starten. Eine offen im Internet erreichbare Komodo-Instanz ist deshalb gleichbedeutend mit einem offen erreichbaren Root-Zugang auf allen angebundenen Hosts.

Daraus folgen drei Regeln:

• Port 9120 niemals ungefiltert ins Internet veröffentlichen. Entweder nur im internen Netz erreichbar machen oder über VPN anbinden.
• Wenn eine Erreichbarkeit von außen nötig ist, einen Reverse Proxy mit TLS davorsetzen und den Core nur an 127.0.0.1 binden.
• Zugangsdaten nicht teilen, sondern pro Person einen eigenen Benutzer mit passenden Rechten anlegen.

Die Bindung an localhost wird in der Compose-Datei angepasst:

# Ausschnitt aus compose.yaml
# Core nur an localhost binden, damit der Reverse Proxy davor sitzt
  core:
    ports:
      - 127.0.0.1:9120:9120

Danach sieht eine passende Nginx-Konfiguration so aus. Die Websocket-Weiterleitung ist nötig, weil Komodo Live-Logs über Websockets ausliefert.

# /etc/nginx/sites-available/komodo.conf
server {
    listen 443 ssl http2;
    server_name komodo.example.com;

    ssl_certificate     /etc/letsencrypt/live/komodo.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/komodo.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9120;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Websockets fuer Live-Logs und Terminal
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600s;
    }
}

Dieser Abschnitt beschreibt den dokumentierten Weg. Der Reverse Proxy mit TLS wurde auf dem Testsystem nicht selbst aufgesetzt und ist damit nicht praktisch geprüft.

Backup der Datenbank

Komodo sichert die Datenbank nach Zeitplan. Die Backups sind gzip-komprimiert, und standardmäßig werden die 14 neuesten Backups behalten. Dieser Wert lässt sich über max_backups beziehungsweise die Variable KOMODO_CLI_MAX_BACKUPS ändern. Neue Installationen ab Version 1.19.0 legen automatisch eine Prozedur namens Backup Core Database an, die täglich läuft.

Jedes Backup landet in einem eigenen Ordner, dessen Name der Zeitstempel ist. Darin liegt je eine .gz-Datei pro Collection. Die Stats-Collection ist wegen ihrer Größe und ihrer geringen Bedeutung nicht in den datierten Backups enthalten, nur der jeweils neueste Stand liegt als Stats.gz auf oberster Ebene. Damit die Dateien überhaupt auf der Platte landen, muss ein Host-Pfad nach /backups im Core-Container gemountet sein. Genau das erledigt COMPOSE_KOMODO_BACKUPS_PATH.

Ein Backup lässt sich jederzeit manuell auslösen:

# Datenbank-Backup sofort ausloesen
docker compose --env-file compose.env exec -T core km database backup -y

# Erzeugte Backup-Ordner auflisten
ls -1 /etc/komodo/backups

# Inhalt des neuesten Backup-Ordners ansehen
ls -1 /etc/komodo/backups/$(ls -1 /etc/komodo/backups | grep -E '^[0-9]{4}-' | tail -n 1)

Auf dem Testsystem lief dieser Befehl real durch. Die Ausgabe endete mit Finished backing up database und No backups to prune. Im Backup-Verzeichnis entstand ein Ordner mit einem Zeitstempel-Namen im Format 2026-09-12_04-50-28 sowie eine Stats.gz auf oberster Ebene. Im Zeitstempel-Ordner lagen unter anderem Action.gz, Alert.gz, Alerter.gz, ApiKey.gz, Build.gz, Builder.gz, Deployment.gz, GitProviderAccount.gz, ImageRegistryAccount.gz, OnboardingKey.gz, Permission.gz, Procedure.gz, Repo.gz, ResourceSync.gz und Server.gz. Das Log zeigte unter anderem Backed up 1 items für User und Tag, Backed up 5 items für Update und Backed up 3 items für Procedure.

Ein Punkt ist ausdrücklich zu beachten: Es gibt keine eingebaute Verschlüsselung. Die offizielle Dokumentation empfiehlt, die Dateien vor einem entfernten Backup selbst zu verschlüsseln. Wer die Backups auf einen fremden Speicher schiebt, muss also selbst für Verschlüsselung sorgen.

Für ein Backup von außerhalb lässt sich die Komodo-CLI als eigener Dienst betreiben:

# remote-backup.compose.yaml
# Eigener CLI-Dienst, der die Datenbank von aussen sichert
services:
  komodo-backup:
    image: ghcr.io/moghtech/komodo-cli:2
    container_name: komodo-backup
    restart: unless-stopped
    environment:
      KOMODO_DATABASE_ADDRESS: ferretdb.intern.example.com:27017
      KOMODO_DATABASE_USERNAME: beispiel_db_user
      KOMODO_DATABASE_PASSWORD: BEISPIEL_DB_PASSWORT_ERSETZEN
      KOMODO_DATABASE_DB_NAME: komodo
      KOMODO_CLI_MAX_BACKUPS: 14
    volumes:
      - /srv/komodo-backups:/backups
    entrypoint: ["km", "database", "backup", "-y"]

Wiederherstellung

Die Wiederherstellung läuft ebenfalls über die Komodo-CLI. Ohne weitere Angabe wird das neueste Backup zurückgespielt. Mit --restore-folder lässt sich ein bestimmter Ordner auswählen.

# Wiederherstellung aus dem neuesten Backup
docker compose --env-file compose.env exec -T core km database restore -y

# Wiederherstellung aus einem bestimmten Ordner
docker compose --env-file compose.env exec -T core \
  km database restore -y --restore-folder 2026-09-12_04-50-28

Diese beiden Befehle stammen aus der offiziellen Dokumentation und wurden auf dem Testsystem nicht ausgeführt. Planen Sie einen Wiederherstellungstest deshalb selbst ein, bevor Sie sich im Ernstfall darauf verlassen. Sinnvoll ist ein separates Testsystem, auf dem ein Backup eingespielt und die Vollständigkeit der Ressourcen geprüft wird.

Updates und Rollback-Grenzen

Ein Update besteht aus vier Schritten: Compose-Datei erneuern, Backup ziehen, Images holen, Stack neu starten.

# Aktuelle Compose-Datei erneut herunterladen
curl -fsSL -o compose.yaml \
  https://raw.githubusercontent.com/moghtech/komodo/main/compose/ferretdb.compose.yaml

# Vor dem Update ein Backup ziehen
docker compose --env-file compose.env exec -T core km database backup -y

# Neue Images holen
docker compose --env-file compose.env pull

# Stack mit den neuen Images neu starten
docker compose --env-file compose.env up -d

# Version im Log kontrollieren
docker compose --env-file compose.env logs core | grep -i "Komodo Core version"

Zwei Einschränkungen sollten Sie kennen. Erstens ist ein Rollback auf eine ältere Komodo-Version nicht einfach ein Zurücksetzen des Image-Tags, weil Datenbankschema-Änderungen einer neuen Version nicht automatisch rückgängig gemacht werden. Wer zurück muss, braucht in der Regel das Backup von vor dem Update. Zweitens gilt der lose Tag 2 zwar als bequem, er zieht aber jede neue Minor-Version automatisch nach. In Produktivumgebungen ist ein fester Tag wie 2.3.3 die berechenbarere Wahl.

Das Update von einer älteren Komodo-Version auf v2.3.3 wurde auf dem Testsystem nicht durchgespielt. Die Installation erfolgte direkt mit v2.3.3.

Typische Fehler und ihre Diagnose

Diese Fehlerbilder treten in der Praxis am häufigsten auf.

• Datenbank-Container startet neu mit Exit-Code 132. Im Log steht ein Hinweis auf fehlende CPU-Unterstützung und Illegal instruction (core dumped). Ursache ist eine CPU ohne AVX-Flag. Prüfung mit grep -o -w avx /proc/cpuinfo. Bleibt die Ausgabe leer, auf die FerretDB-Variante wechseln. Genau dieser Fall trat auf dem Testsystem auf.
• Datenbank ohne Zugangsdaten oder leere Pfade. Ursache ist ein Start ohne --env-file compose.env. Die Variablen werden dann nicht geladen. Immer docker compose --env-file compose.env up -d verwenden, auch bei logs, ps und down.
• Port 9120 bereits belegt. docker compose bricht mit einem Bind-Fehler ab. Mit ss -tlnp | grep 9120 den Belegungsgrund suchen oder die Host-Seite der Port-Zuordnung ändern.
• Periphery meldet den Server als nicht erreichbar. Prüfen, ob der Container läuft und ob das gemeinsame Schlüssel-Volume gemountet ist. Ein neu erzeugtes keys-Volume ohne die passenden Gegenstücke führt zu Verbindungsfehlern.
• Docker verhält sich merkwürdig bei Pfaden. Ursache ist ein abweichender PERIPHERY_ROOT_DIRECTORY innerhalb und außerhalb des Containers. Der Pfad muss auf beiden Seiten identisch sein.
• Anmeldung nicht möglich. Prüfen, ob KOMODO_LOCAL_AUTH=true gesetzt ist und ob der Init-Admin im Core-Log wirklich angelegt wurde.
• Sitzungen laufen ständig ab. KOMODO_JWT_TTL prüfen. Ein geänderter KOMODO_JWT_SECRET macht außerdem alle bestehenden Token ungültig.
• Backups liegen nicht auf der Platte. Der Mount von ${COMPOSE_KOMODO_BACKUPS_PATH} nach /backups fehlt oder der Host-Pfad existiert nicht.

Was praktisch geprüft wurde und was nicht

Diese Anleitung trennt bewusst zwischen eigener Praxisprüfung und dokumentierten Schritten. Alle Tests fanden am 12. September 2026 auf einem Ubuntu-System mit Docker 29.1.3 und Docker Compose 2.40.3 statt.

Selbst ausgeführt und bestätigt:

• Start der offiziellen mongo.compose.yaml. Ergebnis: Neustart-Schleife des MongoDB-Containers mit Exit-Code 132, Ursache fehlendes AVX-Flag der CPU.
• Wechsel auf die offizielle ferretdb.compose.yaml. Ergebnis: erfolgreich, alle vier Container liefen.
• Bestätigung der Version v2.3.3 und der Anlage des Init-Admins im Core-Log.
• Abruf der Weboberfläche, Antwort mit HTTP-Status 200 und ausgelieferter HTML-Seite.
• Ausführung eines Datenbank-Backups über die Komodo-CLI inklusive Kontrolle der erzeugten Dateien.

Nicht selbst geprüft, nur aus der offiziellen Dokumentation übernommen:

• Wiederherstellung aus einem Backup.
• Anbindung eines zweiten Servers per Periphery.
• Reverse Proxy mit TLS vor der Oberfläche.
• Anbindung an einen OIDC-Anbieter.
• Update von einer älteren Komodo-Version auf v2.3.3.

Saubere Deinstallation

Achtung: Der Unterschied zwischen den beiden folgenden Varianten entscheidet über Datenverlust. docker compose down stoppt und entfernt die Container, lässt die Volumes aber bestehen. docker compose down -v löscht zusätzlich alle Volumes und damit die komplette Datenbank samt aller Ressourcen, Berechtigungen und Historie. Dieser Schritt ist nicht umkehrbar. Ziehen Sie vorher ein Backup und prüfen Sie, dass es tatsächlich auf dem Host liegt.

# Variante 1: Stack stoppen, Daten bleiben erhalten
docker compose --env-file compose.env down

# Variante 2: Stack stoppen UND alle Volumes loeschen
# ACHTUNG: loescht die Datenbank unwiderruflich
docker compose --env-file compose.env down -v

# Konfiguration und Backups liegen ausserhalb der Volumes
# und muessen bei Bedarf separat entfernt werden
ls -la /opt/komodo
ls -la /etc/komodo

Konfiguration und Backups liegen außerhalb der Volumes. Wenn die Installation vollständig verschwinden soll, müssen /opt/komodo und /etc/komodo anschließend von Hand entfernt werden. Denken Sie daran, dass in compose.env Zugangsdaten stehen, die auch beim Löschen nicht in einem Papierkorb oder Backup-Snapshot liegen bleiben sollten.

Fazit

Komodo ist kein Ersatz für Portainer oder Dockge auf einem einzelnen Host, sondern die Antwort auf eine andere Frage: wie man Builds und Deployments über viele Server hinweg an einer Stelle steuert. Die Einrichtung per Docker Compose ist geradlinig, sobald zwei Punkte klar sind: die Wahl der Datenbank abhängig von der CPU und der zwingende Parameter --env-file. Wer beides beachtet, hat den Stack in kurzer Zeit laufen. Die sicherheitsrelevante Konsequenz bleibt aber bestehen: Komodo hat Docker-Vollzugriff auf jeden angebundenen Server, und der Zugang zur Oberfläche muss entsprechend eng geführt werden.

Passende Anleitungen auf S-EDV

• Dockge auf dem Synology NAS installieren - die schlanke Alternative, wenn nur ein einzelner Host mit Compose-Stacks verwaltet werden soll.
• Portainer auf dem Synology NAS installieren - der verbreitetste Vergleichspunkt zu Komodo, mit anderem Schwerpunkt bei der Bedienung.
• Traefik als Docker-Reverse-Proxy mit HTTPS einrichten - passend für den Abschnitt zur sicheren Netzwerkfreigabe, wenn Sie statt Nginx auf Traefik setzen.

Quellen

• GitHub: moghtech/komodo - Repository, Lizenz GPL-3.0, Releases und Sternezahl, abgerufen am 12. September 2026.
• Komodo-Dokumentation: Setup - Architektur, Datenbank-Optionen, Compose-Dateien und Variablen, abgerufen am 12. September 2026.
• Komodo-Dokumentation: Backup - Zeitplan, Aufbewahrung, Ordnerstruktur, fehlende Verschlüsselung und Wiederherstellung, abgerufen am 12. September 2026.