Komodo verwaltet Docker-Builds, Deployments und Compose-Stacks auf mehreren Servern über eine gemeinsame Weboberfläche. Diese Anleitung beschreibt die Einrichtung von Komodo 2.3.3 per Docker Compose mit FerretDB, den Betrieb, Backup, Wiederherstellung und typische Fehlerbilder.

Was Komodo leistet und wo die Grenzen liegen

Komodo baut Images aus Git, startet Compose-Stacks und zeigt Logs und Ressourcen der angebundenen Hosts. Das Projekt steht unter der GPL-3.0 und wird unter github.com/moghtech/komodo entwickelt. Laut README ohne Gewährleistung.

Ein Host oder wenige Server ohne Build-Pipeline: Dockge oder Portainer genügen.
Mehrere Server, Images aus Git bauen und automatisch ausrollen: Einsatzgebiet von Komodo.
Kubernetes: nicht unterstützt.

Architektur: Core, Periphery und Datenbank

Der Core liefert Weboberfläche und API und spricht mit der Datenbank. Die Periphery ist der Agent, der auf jedem verwalteten Server die Docker-Befehle ausführt.

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 ihre Schlüssel über das gemeinsame Volume /config/keys aus; auf einem Host erledigt das die Compose-Datei.

Voraussetzungen und Ressourcen

Linux-Host (x86_64 oder ARM64) mit Docker Engine und Compose-Plugin; der Befehl lautet docker compose.
2 CPU-Kerne und 4 GB RAM für Core, Datenbank und Periphery, für Image-Builds mehr.
Root-Rechte oder ein Benutzer in der Gruppe docker, weil Periphery den Docker-Socket einbindet.
Freier Port 9120 für die Weboberfläche.
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, Speicherplatz für Repo-Cache, Images und Backups.

Plattformen und die MongoDB-Einschränkung

Komodo unterstützt MongoDB (Empfehlung) oder FerretDB auf Postgres. Aktuelle MongoDB-Builds setzen die CPU-Erweiterung AVX voraus, die ältere oder virtualisierte Prozessoren nicht melden. Auf dem Testsystem endete die offizielle mongo.compose.yaml deshalb in einer Neustart-Schleife mit Exit-Code 132 und Illegal instruction (core dumped); die FerretDB-Variante lief ohne Anpassung.

# Keine Ausgabe = kein AVX, MongoDB scheidet aus
grep -o -w avx /proc/cpuinfo | head -n 1
docker --version
docker compose version

Bleibt die erste Ausgabe leer, nutzen Sie FerretDB. Liefert sie avx, wählen Sie frei.

Verifizieren: docker compose version meldet Version 2.x, und Sie wissen, ob die CPU AVX meldet.

Geprüfter Versionsstand

Stand 12. September 2026 ist v2.3.3 (1. September 2026) aktuell. Der Tag 2 aus der offiziellen Variablen-Datei folgt der Major-Version und zieht jede neue Minor-Version automatisch nach. Diese Anleitung schreibt deshalb 2.3.3 fest.

Installation Schritt für Schritt

Legen Sie das Arbeitsverzeichnis an und laden Sie die offiziellen Dateien:

mkdir -p /opt/komodo /etc/komodo/backups
cd /opt/komodo

curl -fsSL -o compose.yaml \
  https://raw.githubusercontent.com/moghtech/komodo/main/compose/ferretdb.compose.yaml
curl -fsSL -o compose.env \
  https://raw.githubusercontent.com/moghtech/komodo/main/compose/compose.env
chmod 600 compose.env

Erzeugen Sie die Secrets mit openssl, statt eigene Zeichenketten abzutippen:

# Drei Zufallswerte fuer compose.env
openssl rand -base64 32
openssl rand -base64 32
openssl rand -base64 32

Tragen Sie die Ausgaben in KOMODO_WEBHOOK_SECRET, KOMODO_JWT_SECRET und KOMODO_DATABASE_PASSWORD ein und ersetzen Sie KOMODO_INIT_ADMIN_PASSWORD=changeme durch ein eigenes Passwort.

Verifizieren: ls -l /opt/komodo zeigt compose.yaml und compose.env (Rechte -rw-------), und grep -E 'changeme|a_random' compose.env liefert keine Treffer mehr.

Die Compose-Datei im Überblick

Die FerretDB-Variante mit den vier Diensten Postgres, FerretDB, Core und Periphery, wie sie am 12. September 2026 getestet wurde:

# compose.yaml (FerretDB-Variante, Stand v2.3.3)
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:

Periphery bindet /var/run/docker.sock und /proc ein und braucht diesen Zugriff. /etc/komodo ist auf beiden Seiten des Doppelpunkts identisch. Das Backup-Verzeichnis hängt über ${COMPOSE_KOMODO_BACKUPS_PATH}:/backups im Core; fehlt der Mount, liegen Backups nur im Container. Gleichen Sie die offizielle Datei vor der Installation ab, sie ändert sich mit neuen Versionen.

Die Variablen-Datei compose.env

Fast alle Einstellungen stehen in compose.env. Kommentierte Fassung mit Beispielwerten:

# compose.env (Beispielwerte ersetzen)
COMPOSE_KOMODO_IMAGE_TAG=2.3.3
COMPOSE_KOMODO_BACKUPS_PATH=/etc/komodo/backups

KOMODO_DATABASE_USERNAME=beispiel_db_user
KOMODO_DATABASE_PASSWORD=BEISPIEL_DB_PASSWORT_ERSETZEN

TZ=Europe/Berlin
KOMODO_HOST=https://komodo.example.com
KOMODO_TITLE=Komodo
KOMODO_LOCAL_AUTH=true
KOMODO_INIT_ADMIN_USERNAME=admin
KOMODO_INIT_ADMIN_PASSWORD=BEISPIEL_ADMIN_PASSWORT_ERSETZEN
KOMODO_FIRST_SERVER_NAME=Local

# Secrets mit openssl rand -base64 32 erzeugen
KOMODO_WEBHOOK_SECRET=BEISPIEL_WEBHOOK_SECRET_ERSETZEN
KOMODO_JWT_SECRET=BEISPIEL_JWT_SECRET_ERSETZEN
KOMODO_JWT_TTL=1-day
KOMODO_DISABLE_CONFIRM_DIALOG=false
KOMODO_DEFAULT_PAGINATION_LIMIT=50

Variable	Standard	Bedeutung
`COMPOSE_KOMODO_IMAGE_TAG`	2	Image-Tag; hier fest 2.3.3
`COMPOSE_KOMODO_BACKUPS_PATH`	/etc/komodo/backups	Host-Pfad für `/backups` im Core
`KOMODO_DATABASE_USERNAME`	admin	Datenbankbenutzer für Postgres, FerretDB und Core
`KOMODO_DATABASE_PASSWORD`	admin	Datenbankpasswort, per `openssl` erzeugen
`TZ`	Etc/UTC	Zeitzone für Logs und Zeitpläne
`KOMODO_HOST`	Beispiel-URL	Adresse der Oberfläche, für Webhook- und OAuth-Links
`KOMODO_TITLE`	Komodo	Titel im Browser-Tab
`KOMODO_LOCAL_AUTH`	true	Anmeldung mit Benutzername und Passwort
`KOMODO_INIT_ADMIN_USERNAME`	admin	Erster Administrator
`KOMODO_INIT_ADMIN_PASSWORD`	changeme	Vor dem ersten Start ersetzen
`KOMODO_FIRST_SERVER_NAME`	Local	Anzeigename des ersten Servers
`KOMODO_WEBHOOK_SECRET`	Beispielwert	Prüft eingehende Webhooks
`KOMODO_JWT_SECRET`	Beispielwert	Signiert Anmelde-Token; Änderung beendet alle Sitzungen
`KOMODO_JWT_TTL`	1-day	Token-Gültigkeit: 1-hr bis 2-wk
`KOMODO_DISABLE_CONFIRM_DIALOG`	false	Sicherheitsabfrage vor Aktionen; auf false lassen
`KOMODO_DEFAULT_PAGINATION_LIMIT`	50	Einträge pro Listenseite

Start und Erstanmeldung

Geben Sie die Variablen-Datei bei jedem Aufruf mit. Ohne --env-file compose.env bleiben KOMODO_DATABASE_USERNAME, KOMODO_DATABASE_PASSWORD und COMPOSE_KOMODO_BACKUPS_PATH leer, und der Start schlägt fehl.

docker compose --env-file compose.env up -d
docker compose --env-file compose.env ps
docker compose --env-file compose.env logs core

Im Test liefen danach komodo-core, komodo-ferretdb (healthy), komodo-periphery und komodo-postgres. Das Core-Log meldete Successfully created init admin user.

Öffnen Sie http://SERVER-IP:9120 auf und melden Sie sich mit KOMODO_INIT_ADMIN_USERNAME und KOMODO_INIT_ADMIN_PASSWORD an. Danach:

Administrator-Passwort in der Oberfläche neu setzen und aus compose.env entfernen.
Verbindungsstatus des ersten Servers (KOMODO_FIRST_SERVER_NAME) prüfen.
Prozedur Backup Core Database öffnen und den Zeitplan bestätigen.
Weitere Benutzer nur mit den nötigen Rechten anlegen.

Verifizieren: docker compose --env-file compose.env ps zeigt vier Container mit Status Up, die Anmeldung gelingt, und der Server erscheint als verbunden.

Funktions- und Healthcheck

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9120
docker ps --filter name=komodo --format "{{.Names}}\t{{.Status}}"

Erwartet wird HTTP-Status 200. Bei leerer Antwort oder Verbindungsfehler prüfen Sie die Logs:

docker compose --env-file compose.env logs -f core
docker compose --env-file compose.env logs postgres
docker compose --env-file compose.env ps -a

Persistente Daten und Rechte

pg-data: die Datenbank. Ohne dieses Volume ist die Installation leer.
repo-cache: ausgecheckte Git-Repositories, wird bei Bedarf neu befüllt.
keys: Schlüssel zwischen Core und Periphery.
/etc/komodo auf dem Host: Arbeitsverzeichnis der Periphery und Backups unter /etc/komodo/backups.

compose.env enthält Datenbankpasswort, JWT-Signaturschlüssel und Webhook-Geheimnis im Klartext: chmod 600, nie in ein Git-Repository. /etc/komodo sollte nur für root lesbar sein, weil die Backups alle Ressourcen und Berechtigungen enthalten.

Sichere Netzwerkfreigabe und Reverse Proxy

Sicherheitshinweis: Periphery bindet den Docker-Socket ein. Wer Zugriff auf Komodo hat, kann auf jedem angebundenen Server beliebige Container mit beliebigen Rechten starten. Eine offen erreichbare Komodo-Instanz entspricht einem offenen Root-Zugang auf allen Hosts.

Port 9120 nie ungefiltert ins Internet freigeben; nur intern oder per VPN erreichbar machen.
Ist Zugriff von außen nötig: Reverse Proxy mit TLS davor, Core nur an 127.0.0.1 binden.

# Ausschnitt compose.yaml: Core nur an localhost
  core:
    ports:
      - 127.0.0.1:9120:9120

Eine passende Nginx-Konfiguration; die Websocket-Weiterleitung ist für Live-Logs und Terminal nötig:

# /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;
    }
}

Backup der Datenbank

Neue Installationen legen die Prozedur Backup Core Database an, die täglich läuft. Komodo behält standardmäßig die 14 neuesten gzip-komprimierten Backups (KOMODO_CLI_MAX_BACKUPS). Jedes Backup liegt in einem Ordner mit Zeitstempel, eine .gz-Datei je Collection. Voraussetzung ist der Mount von COMPOSE_KOMODO_BACKUPS_PATH nach /backups.

docker compose --env-file compose.env exec -T core km database backup -y
ls -1 /etc/komodo/backups

Im Test endete der Befehl mit Finished backing up database und legte einen Ordner wie 2026-09-12_04-50-28 an.

Komodo verschlüsselt Backups nicht; verschlüsseln Sie sie vor der Ablage auf fremdem Speicher selbst. Für ein Backup von einem anderen Host betreiben Sie die Komodo-CLI als eigenen Dienst:

# remote-backup.compose.yaml
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

Ohne weitere Angabe spielt die CLI das neueste Backup zurück, --restore-folder wählt einen bestimmten Ordner.

# 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 Befehle wurden im Test nicht ausgeführt. Testen Sie die Wiederherstellung auf einem separaten System, bevor Sie sich im Ernstfall darauf verlassen.

Updates und Rollback-Grenzen

# 1. Backup ziehen
docker compose --env-file compose.env exec -T core km database backup -y

# 2. COMPOSE_KOMODO_IMAGE_TAG in compose.env auf die neue Version setzen,
#    Release Notes und offizielle Compose-Datei vorher abgleichen

# 3. Images holen und Stack neu starten
docker compose --env-file compose.env pull
docker compose --env-file compose.env up -d

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

Ein Rollback ist kein bloßes Zurücksetzen des Image-Tags, weil Schemaänderungen einer neuen Version bleiben. Zurück geht es nur mit dem Backup von vor dem Update. Ein Update von einer älteren Version auf v2.3.3 wurde nicht getestet.

Typische Fehler und ihre Diagnose

Datenbank-Container startet mit Exit-Code 132 neu, Log zeigt Illegal instruction (core dumped): CPU ohne AVX. Mit grep -o -w avx /proc/cpuinfo prüfen, bei leerer Ausgabe FerretDB nutzen.
Datenbank ohne Zugangsdaten oder leere Pfade: Start ohne --env-file compose.env. Die Option bei up, logs, ps und down immer mitgeben.
Port 9120 belegt: Bind-Fehler beim Start. Mit ss -tlnp | grep 9120 den Prozess finden oder den Host-Port ändern.
Periphery meldet den Server als nicht erreichbar: Container-Status und Mount des keys-Volumes prüfen. Ein neu erzeugtes Volume ohne passende Gegenstücke verhindert die Verbindung.
Anmeldung scheitert: KOMODO_LOCAL_AUTH=true gesetzt? Init-Admin im Core-Log angelegt?
Keine Backups auf der Platte: Mount von ${COMPOSE_KOMODO_BACKUPS_PATH} nach /backups fehlt oder der Host-Pfad existiert nicht.

Was praktisch geprüft wurde und was nicht

Getestet am 12. September 2026 (Ubuntu, Docker 29.1.3): Installation mit FerretDB, Anmeldung, Backup. Nur dokumentiert: Wiederherstellung, zweiter Server, Reverse Proxy, Updates.

Saubere Deinstallation

Achtung: down entfernt nur die Container. down -v löscht zusätzlich die Datenbank unwiderruflich. Ziehen Sie vorher ein Backup und prüfen Sie, dass es 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

# Danach bei Bedarf: rm -rf /opt/komodo /etc/komodo

Fazit

Komodo lohnt sich ab mehreren Servern. Entscheidend für die Einrichtung sind die Datenbankwahl nach CPU und der Parameter --env-file. Wegen des Docker-Vollzugriffs bleibt der Zugang zur Oberfläche eng begrenzt.

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, 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.