Komodo mit Traefik: Docker-Server per Weboberfläche verwalten

Komodo ist eine Weboberfläche, mit der du Docker-Container auf einem oder mehreren Servern verwaltest. Du startest Compose-Stacks per Klick, siehst Logs und Statistiken, holst Stacks aus einem Git-Repository, lässt Updates automatisch einspielen und bekommst Benachrichtigungen, wenn etwas ausfällt. In dieser Anleitung installiere ich Komodo hinter Traefik auf einem Debian-Server, deploye meine ersten Stacks und gehe einige Funktionen durch.

Was ist Komodo?

Komodo ist eine Oberfläche für Docker, wie es auch Portainer ist, dem ich früher eine Anleitung gewidmet habe. Bei den bekannten Alternativen hat sich die Lage verschoben:

• Portainer hat im September 2026 Version 3.0 angekündigt. Die neue Entwicklung ist Kubernetes-first und Closed Source. Die Community Edition bleibt auf dem Stand 2.45 LTS.
• Dockhand hat im September 2026 seine BSL-1.1-Lizenz überarbeitet. Wer es produktiv in einem Unternehmen einsetzt, braucht eine kostenpflichtige Lizenz. Für den Privatgebrauch bleibt es erstmal kostenlos.
• Übrig bleiben freie Projekte: Arcane steht unter BSD-3-Clause, Komodo unter GPL-3.0.

Komodo denkt in Stacks, Git-Repositories und Abläufen:

• Ein Stack ist eine Compose-Datei, die du in der Oberfläche schreibst, vom Server liest oder aus Git holst.
• Prozeduren verketten Aktionen, zum Beispiel „Stack A aktualisieren, dann Stack B”, und laufen auf einem Zeitplan.
• Variablen und Geheimnisse legst du einmal an und nutzt sie in vielen Stacks.
• Die Konfiguration lässt sich als TOML exportieren und in einem Git-Repository versionieren.

Dafür ist Komodo etwas größer: Neben der Oberfläche läuft eine MongoDB. Außerdem dauert die Einarbeitung länger.

Glossar

Voraussetzungen

1. Ein Server mit Docker Ich habe einen kleinen VPS mit 2 vCPU und 4 GB RAM genutzt. Nach der Installation von Traefik, Komodo und zwei Beispiel-Stacks belegte das System etwa 1 GB RAM. Mit weniger als 2 GB wird es eng, weil allein MongoDB etwa 275 MB verbraucht.
2. Eine Domain oder Subdomain, deren A-Record auf die IP deines Servers zeigt. Ich nutze hier {{domain}}.
3. Offene Ports: 80 und 443.
4. Traefik oder einen anderen Reverse Proxy. Wenn du ihn noch nicht hast, richte ich ihn im nächsten Schritt in Kurzform ein. Die ausführliche Variante mit Middlewares und Authentifizierung steht in der Traefik-Anleitung.

Prüfe vorher, ob der DNS-Eintrag stimmt:

dig +short {{domain}}

Die Ausgabe muss die IP deines Servers sein. Brauchst du Hilfe beim Einstieg in SSH, hilft dir mein Beitrag zu den VPS-Grundlagen.

Schritt 1: Docker installieren

Alles als root auszuführen ist eine schlechte Angewohnheit: Ein Tippfehler oder ein kompromittierter Dienst hat dann vollen Zugriff auf die Maschine. Ich nutze root nur für den ersten Login, um einen normalen Benutzer anzulegen. Wenn dein Anbieter dir schon einen Benutzer mit sudo eingerichtet hat, überspringe den ersten Block.

apt update && apt upgrade -y
apt install -y sudo
adduser deploy
usermod -aG sudo deploy

Melde dich ab und als deploy wieder an (ssh deploy@{{domain}}). Nutzt du SSH-Schlüssel, kopiere deinen vorher mit ssh-copy-id deploy@{{domain}} zum neuen Benutzer. Ab hier braucht kein Befehl dieser Anleitung mehr einen root-Login. Jetzt installiere ich Docker aus der offiziellen Paketquelle von Docker, wie es die Docker-Dokumentation für Debian beschreibt. So bekommt Docker seine Updates später über apt upgrade:

sudo apt install -y ca-certificates curl dnsutils git
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER

Der letzte Befehl erlaubt deinem Benutzer, Docker ohne sudo zu nutzen. Melde dich dafür einmal ab und wieder an. Beachte, dass die Mitgliedschaft in der Gruppe docker praktisch Root-Rechte bedeutet. Füge also nur Benutzer hinzu, denen du vertraust.

Zur Kontrolle:

docker --version
docker compose version

Docker version 29.9.3, build 5457199
Docker Compose version v5.7.0

Schritt 2: Traefik einrichten

Alle Docker-Projekte landen bei mir unter ~/docker. Traefik bekommt ein eigenes Verzeichnis, und alle Dienste, die er ausliefern soll, hängen im gemeinsamen Docker-Netzwerk web.

mkdir -p ~/docker/traefik/acme
cd ~/docker
touch traefik/acme/acme.json
chmod 600 traefik/acme/acme.json

Die Datei acme.json speichert die Zertifikate. Sie muss 600 als Rechte haben, sonst verweigert Traefik den Start. Jetzt die statische Konfiguration ~/docker/traefik/traefik.yml:

global:
    checkNewVersion: true
    sendAnonymousUsage: false
    aliasHeadersStrategy: delete

api:
    dashboard: true

ping: {}

log:
    level: INFO

entryPoints:
    http:
        address: ":80"
        http:
            redirections:
                entryPoint:
                    to: https
                    scheme: https
    https:
        address: ":443"
        http:
            tls:
                certResolver: letsencrypt

providers:
    docker:
        exposedByDefault: false
        network: web

certificatesResolvers:
    letsencrypt:
        acme:
            email: deine@mail.de
            storage: /acme.json
            httpChallenge:
                entryPoint: http

Ersetze deine@mail.de durch deine Adresse. Die Optionen im Einzelnen:

• exposedByDefault: false sorgt dafür, dass Traefik nur Container ausliefert, die ausdrücklich traefik.enable=true tragen.
• Der Einstiegspunkt http leitet alles auf https um.
• Die Zertifikate holt Traefik per HTTP-Challenge, dafür muss Port 80 offen sein.

Die Compose-Datei ~/docker/docker-compose.yml:

networks:
    web:
        name: web

services:
    traefik:
        image: traefik:v3.7
        container_name: traefik
        restart: unless-stopped
        security_opt:
            - no-new-privileges:true
        ports:
            - "80:80"
            - "443:443"
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock:ro
            - ./traefik/traefik.yml:/etc/traefik/traefik.yml:ro
            - ./traefik/acme/acme.json:/acme.json
        networks:
            - web
        healthcheck:
            test: ["CMD", "traefik", "healthcheck", "--ping"]
            interval: 30s
            timeout: 5s
            retries: 3

cd ~/docker
docker compose up -d
docker compose ps

Bis der Status healthy zeigt, vergehen ein paar Sekunden.

Schritt 3: Komodo mit Docker Compose starten

Komodo besteht aus drei Containern:

• mongo speichert die gesamte Konfiguration.
• core ist die Weboberfläche und die API.
• periphery führt Docker-Befehle auf dem Server aus, auf dem Komodo selbst läuft.

Das Verzeichnis dafür:

mkdir -p ~/docker/komodo
cd ~/docker/komodo

Die Datei .env

Die .env enthält Passwörter und Einstellungen. Ich nenne sie bewusst .env, weil Docker Compose diese Datei automatisch liest und du später keine Warnungen wie „variable is not set” bekommst. Die Geheimnisse erzeuge ich direkt auf dem Server:

cat > .env <<EOF
COMPOSE_KOMODO_IMAGE_TAG=2
COMPOSE_KOMODO_BACKUPS_PATH=/etc/komodo/backups

KOMODO_DATABASE_USERNAME=komodo
KOMODO_DATABASE_PASSWORD=$(openssl rand -hex 16)

TZ=Europe/Berlin
KOMODO_HOST=https://{{domain}}
KOMODO_TITLE=Komodo
KOMODO_PERIPHERY_PUBLIC_KEY=file:/config/keys/periphery.pub
KOMODO_LOCAL_AUTH=true
KOMODO_FIRST_SERVER_NAME=Local
KOMODO_WEBHOOK_SECRET=$(openssl rand -hex 16)
KOMODO_JWT_SECRET=$(openssl rand -hex 32)

PERIPHERY_CORE_ADDRESS=ws://core:9120
PERIPHERY_CONNECT_AS=Local
PERIPHERY_CORE_PUBLIC_KEYS=file:/config/keys/core.pub
PERIPHERY_ROOT_DIRECTORY=/etc/komodo
PERIPHERY_INCLUDE_DISK_MOUNTS=/etc/hostname
EOF
chmod 600 .env

Die wichtigsten Einträge:

Die Datei compose.yaml

networks:
    web:
        external: true

services:
    mongo:
        image: mongo:8
        restart: unless-stopped
        labels:
            komodo.skip:
        command: --quiet --wiredTigerCacheSizeGB 0.25
        volumes:
            - mongo-data:/data/db
            - mongo-config:/data/configdb
        environment:
            MONGO_INITDB_ROOT_USERNAME: ${KOMODO_DATABASE_USERNAME}
            MONGO_INITDB_ROOT_PASSWORD: ${KOMODO_DATABASE_PASSWORD}

    core:
        image: ghcr.io/moghtech/komodo-core:${COMPOSE_KOMODO_IMAGE_TAG:-2}
        init: true
        restart: unless-stopped
        depends_on:
            - mongo
        env_file: ./.env
        environment:
            KOMODO_DATABASE_ADDRESS: mongo:27017
        volumes:
            - keys:/config/keys
            - ${COMPOSE_KOMODO_BACKUPS_PATH}:/backups
        networks:
            - default
            - web
        labels:
            komodo.skip:
            traefik.enable: "true"
            traefik.http.routers.komodo.rule: Host(`{{domain}}`)
            traefik.http.routers.komodo.entrypoints: https
            traefik.http.services.komodo.loadbalancer.server.port: "9120"

    periphery:
        image: ghcr.io/moghtech/komodo-periphery:${COMPOSE_KOMODO_IMAGE_TAG:-2}
        init: true
        restart: unless-stopped
        depends_on:
            - core
        env_file: ./.env
        volumes:
            - keys:/config/keys
            - /var/run/docker.sock:/var/run/docker.sock
            - /proc:/proc
            - ${PERIPHERY_ROOT_DIRECTORY:-/etc/komodo}:${PERIPHERY_ROOT_DIRECTORY:-/etc/komodo}
        labels:
            komodo.skip:

volumes:
    mongo-data:
    mongo-config:
    keys:

Ein paar Stellen zum Verstehen:

• Der Core hängt an zwei Netzwerken. default verbindet ihn mit MongoDB und dem Agenten, web mit Traefik.
• Die Labels am Core sind das komplette Traefik-Setup: Domain, HTTPS und der interne Port 9120. Eine Datei für Traefik musst du dafür nicht anfassen.
• Das Label komodo.skip sagt Komodo, dass es diese Container nicht selbst neu starten oder aktualisieren darf. Sonst würde sich Komodo beim Update gegenseitig den Boden wegziehen.
• Core und Agent teilen sich das Volume keys. Dort legt Komodo beim ersten Start die Schlüsselpaare ab, mit denen sich beide gegenseitig erkennen.
• --wiredTigerCacheSizeGB 0.25 begrenzt den Cache von MongoDB, sonst nimmt sich die Datenbank viel RAM.
• Der Ordner /etc/komodo wird mit demselben Pfad in den Agenten gehängt. Das ist wichtig, weil Docker-Befehle des Agenten auf dem Host ausgeführt werden und dieselben Pfade brauchen.

Starten und prüfen:

docker compose up -d
docker compose ps

NAME                 IMAGE                                 STATUS          PORTS
komodo-core-1        ghcr.io/moghtech/komodo-core:2        Up 35 minutes   9120/tcp
komodo-mongo-1       mongo:8                               Up 35 minutes   27017/tcp
komodo-periphery-1   ghcr.io/moghtech/komodo-periphery:2   Up 35 minutes   8120/tcp

Ein Blick ins Log des Cores zeigt, dass alles geklappt hat:

docker compose logs core | tail -5

CoreStartup: Komodo Core version: v2.3.4
Writing private key to /config/keys/core.key
Server starting on http://[::]:9120

Nach etwa einer Minute hat Traefik das Zertifikat geholt. Prüfen kannst du es mit:

curl -vI https://{{domain}} 2>&1 | grep -E "issuer|HTTP/"

*  issuer: C=US; O=Let's Encrypt; CN=YR1
< HTTP/2 200

Schritt 4: Erster Login

Öffne https://{{domain}} im Browser. Beim ersten Aufruf gibt es noch keinen Benutzer.

Klicke auf „Sign Up” und lege Benutzername und Passwort an. Der erste Benutzer, der sich registriert, wird automatisch Administrator. Danach solltest du keine weiteren Registrierungen zulassen: Setze KOMODO_DISABLE_USER_REGISTRATION=true in die .env und starte den Core mit docker compose up -d neu. Weitere Benutzer legst du danach im Admin-Bereich selbst an.

Möchtest du den Admin lieber per Konfiguration anlegen, kennt Komodo dafür die Variablen KOMODO_INIT_ADMIN_USERNAME und KOMODO_INIT_ADMIN_PASSWORD.

Die Oberfläche im Überblick

Komodo ist nach dem Login schon nicht mehr leer. Der Server Local wurde durch KOMODO_FIRST_SERVER_NAME angelegt, und der Agent hat sich verbunden.

Links in der Seitenleiste findest du:

• Dashboard: Zusammenfassung aller Ressourcen.
• Containers: Alle Container aller Server in einer Liste.
• Terminals: Shells in Containern und auf Servern.
• Stats: Auslastung der Server.
• Servers, Swarms, Stacks, Deployments, Builds, Repos, Procedures, Actions, Syncs: Die Ressourcen, die Komodo verwaltet. Ich gehe die wichtigsten gleich durch.
• Alerts und Updates: Benachrichtigungen und ein Protokoll aller Änderungen.

Die Serverliste

Unter „Servers” siehst du den Server Local mit dem Status OK.

Ein Klick darauf öffnet die Detailseite mit Konfiguration, Statistiken, Docker-Objekten und Terminals.

Der Reiter „Stats” zeigt CPU, RAM und Festplatte über die Zeit.

Im Reiter „Docker” findest du alle Container, Netzwerke, Volumes und Images des Servers.

Oben auf der Seite gibt es außerdem Knöpfe wie „Prune System”, um ungenutzte Images und Container zu löschen. Sei damit vorsichtig, wenn du gestoppte Container noch brauchst.

Den ersten Stack per Oberfläche starten

Ein Stack ist eine Compose-Datei. Zum Ausprobieren nutze ich traefik/whoami, einen winzigen Webserver, der Informationen über die Anfrage zurückgibt.

Gehe auf „Stacks” und klicke auf „New Stack”.

Gib einen Namen ein, wähle den Server Local und bestätige. Der Stack ist angelegt, aber noch leer.

Unter „Choose Mode” wählst du, woher die Compose-Datei kommt:

Wir nehmen „UI Defined” und fügen im Editor diese Compose-Datei ein. Ersetze whoami.deinedomain.de durch eine Domain, die auf deinen Server zeigt:

services:
    whoami:
        image: traefik/whoami
        restart: unless-stopped
        networks:
            - web
        labels:
            - "traefik.enable=true"
            - "traefik.http.routers.whoami.rule=Host(`whoami.deinedomain.de`)"
            - "traefik.http.routers.whoami.entrypoints=https"
            - "traefik.http.services.whoami.loadbalancer.server.port=80"

networks:
    web:
        external: true

Mit „Save” speicherst du. Komodo zeigt vorher einen Vergleich der Änderung an und fragt nach Bestätigung.

Dann klickst du auf „Deploy”. Alle ausführenden Knöpfe in Komodo fragen mit einem zweiten Klick nach. Der Stack wechselt auf RUNNING.

Unter „Log” siehst du, was Komodo beim Deploy gemacht hat. Das ist der Ablauf von docker compose up:

„Services” zeigt die Container des Stacks, und der Reiter „Log” die Ausgabe der Container selbst.

Ein Test von außen zeigt, dass Traefik die Anfrage an den neuen Container weiterreicht:

curl https://whoami.deinedomain.de

Hostname: be603bb374a5
IP: 127.0.0.1
IP: ::1
IP: 172.18.0.4
RemoteAddr: 172.18.0.2:36224
GET / HTTP/1.1
Host: whoami.deinedomain.de
X-Forwarded-Proto: https

Die Domain brauchst du dafür nicht in Traefik einzutragen. Der Container trägt seine Regeln als Labels selbst, und Traefik liest sie über den Docker-Socket.

Stacks aus einem Git-Repository

Für Stacks, die du versionieren willst, ist der Git-Modus besser. Die Compose-Datei liegt dann in einem Repository, und Komodo holt sie dort. Ich nutze zum Testen das Repository von Uptime Kuma, das eine fertige compose.yaml enthält.

Lege einen neuen Stack an, wähle als Modus „Git Repo” und trage ein:

• Account: leer, bei öffentlichen Repositories brauchst du keinen.
• Repo: louislam/uptime-kuma
• Branch: master (Komodo setzt als Vorgabe main)

Beim Speichern zeigt Komodo wieder den Vergleich.

Nach dem Deploy klont Komodo das Repository nach /etc/komodo/stacks/<Stack-Name> auf dem Server und startet die Compose-Datei daraus.

Für private Repositories hinterlegst du unter Einstellungen → Providers ein Konto mit Zugriffstoken. Das wählst du dann im Feld „Account” aus.

Webhooks: Deploy bei jedem Push

Im Stack findest du den Abschnitt „Webhooks”. Komodo zeigt dort eine URL der Form https://{{domain}}/listener/github/stack/<ID>/deploy. Trägst du diese URL als Webhook in GitHub oder einem kompatiblen Git-Dienst ein (zum Beispiel Forgejo oder Gitea), deployt Komodo den Stack bei jedem Push.

Das Geheimnis aus KOMODO_WEBHOOK_SECRET trägst du beim Git-Dienst als „Secret” ein.

Dateien, die schon auf dem Server liegen

Der Modus „Files On Server” liest eine Compose-Datei aus dem Verzeichnis /etc/komodo/stacks/<Stack-Name>/. Das lohnt sich, wenn du Dateien mit Ansible oder per Hand dorthin legst. Im Feld „Run Directory” gibst du einen Pfad relativ zu diesem Ordner an. Die Datei heißt standardmäßig compose.yaml.

Container verwalten

Unter „Containers” siehst du alle Container aller Server in einer Liste.

Ein Klick auf einen Container öffnet seine Seite mit drei Reitern:

• Log: die Ausgabe des Containers.
• Inspect: das Ergebnis von docker inspect.
• Terminals: eine Shell im Container.

Das Terminal öffnest du mit sh oder bash, je nachdem, was das Image mitbringt. Das ist praktisch, wenn du unterwegs schnell etwas nachsehen willst, ohne SSH.

Variablen und Geheimnisse

Unter Einstellungen → Variables legst du Werte an, die du in mehreren Stacks nutzt, zum Beispiel deine Domain oder ein Passwort.

Eine neue Variable hat Name, Wert und Beschreibung. Mit der Option „Secret” versteckt Komodo den Wert in der Oberfläche.

Laut Dokumentation setzt du eine Variable mit doppelten eckigen Klammern ein, etwa [[DOMAIN]]. In meinem Test habe ich das nicht bis zum Ende prüfen können, deshalb prüfe nach dem ersten Deploy mit docker inspect, ob der Wert wirklich ersetzt wurde.

Zusätzlich hat jeder Stack einen eigenen Bereich „Environment”. Was du dort im Format NAME=wert einträgst, schreibt Komodo vor dem Deploy in eine .env neben die Compose-Datei, und Compose liest sie wie gewohnt.

Prozeduren und Backups

Prozeduren führen Aktionen in einer festen Reihenfolge aus und können per Zeitplan laufen. Komodo bringt bereits drei mit:

Das Backup solltest du einmal von Hand testen. Öffne „Backup Core Database”.

Klicke auf „Run”. Für Prozeduren verlangt Komodo, dass du zur Bestätigung den Namen der Prozedur eintippst.

Auf dem Server findest du ein Verzeichnis mit Datum, in dem für jeden Typ eine komprimierte Datei liegt:

sudo ls /etc/komodo/backups/
sudo ls /etc/komodo/backups/2026-11-06_20-01-36

2026-11-06_20-01-36
Stats.gz     Action.gz    Alerter.gz   Alert.gz     ApiKey.gz
Builder.gz   Build.gz     Deployment.gz  Procedure.gz  Repo.gz
Server.gz    Stack.gz     Variable.gz  User.gz       UserGroup.gz
...

Die Backups enthalten die Konfiguration von Komodo, also Stacks, Server und Prozeduren. Die Daten deiner Container (Volumes) sind darin nicht enthalten. Kopiere den Ordner regelmäßig auf einen anderen Rechner, zum Beispiel mit rsync.

Automatische Updates

Jeder Stack hat einen Abschnitt „Auto Update”. Dort gibt es drei Schalter:

• Poll for Updates: Komodo prüft regelmäßig, ob es neue Images gibt.
• Auto Update: Komodo deployt, wenn es ein neues Image gibt.
• Full Stack Auto Update: aktualisiert den gesamten Stack, nicht nur die Services mit neuem Image.

Die Prozedur „Global Auto Update” läuft nachts und zieht neue Images, wenn du Auto Update eingeschaltet hast. Bei Containern mit festem Tag wie :2 bekommst du neue Patch-Versionen, bei :latest auch Sprünge auf die nächste Hauptversion. Ich schalte die Funktion nur bei Diensten ein, bei denen ein Update selten etwas kaputt macht.

Benachrichtigungen mit Alertern

Unter Einstellungen → Alerters legst du Ziele für Benachrichtigungen an.

Komodo unterstützt die Endpunkte Custom, Discord, Slack, Ntfy und Pushover.

Du wählst den Typ und trägst die URL ein. In der Konfiguration kannst du außerdem festlegen, bei welchen Ereignissen eine Nachricht kommt, etwa wenn ein Server nicht erreichbar ist, ein Stack ausfällt oder die Festplatte voll wird.

Weitere Funktionen im Kurzüberblick

Diese Bereiche gehen über Stacks hinaus.

Builds und Builder

Komodo kann Docker-Images aus einem Git-Repository bauen und in eine Registry pushen. Der Builder, der die Arbeit macht, ist standardmäßig dein Server („Local”). Unter Einstellungen → Builders kannst du weitere hinzufügen.

Actions

Actions sind kleine TypeScript-Skripte, die gegen die Komodo-API laufen. Du kannst damit Abläufe bauen, die eine Prozedur allein nicht kann.

Syncs und der TOML-Export

Mit einem Resource Sync hältst du die Konfiguration von Komodo in einem Git-Repository. Du beschreibst Stacks, Server und Prozeduren als TOML-Datei, und Komodo gleicht sie ab. Auf vielen Seiten gibt es oben rechts den Knopf „Toml”, der die aktuelle Konfiguration als TOML anzeigt. So kommst du ohne Handarbeit zu einer Startdatei.

Benutzer und Gruppen

Unter Einstellungen → Users legst du weitere Benutzer an und fasst sie in Gruppen zusammen. Die Rechte vergibst du pro Ressource, sodass jemand zum Beispiel nur einen bestimmten Stack sehen darf.

Einen zweiten Server anbinden

Einer der Gründe für Komodo ist, mehrere Server aus einer Oberfläche zu steuern. Dafür installierst du auf dem neuen Server nur den Periphery-Agenten. Docker muss dort vorher laufen (siehe Schritt 1).

Zuerst legst du im Core einen Onboarding-Schlüssel an: Einstellungen → Onboarding → „New Onboarding Key”.

Du gibst dem Schlüssel einen Namen und lässt die Gültigkeit bei einem Tag.

Komodo zeigt den Schlüssel danach genau einmal an. Kopiere ihn sofort. Er beginnt mit O_. Auf dem neuen Server startest du dann das Installationsskript:

curl -sSL https://raw.githubusercontent.com/moghtech/komodo/main/scripts/setup-periphery.py | sudo python3 - \
  --core-address="https://{{domain}}" \
  --connect-as="worker" \
  --onboarding-key="O_DEIN_SCHLÜSSEL"

Das Skript lädt den Agenten herunter, schreibt eine Konfiguration nach /etc/komodo und richtet einen systemd-Dienst namens periphery ein. Ein Pipe-Aufruf wie oben führt Code aus dem Internet aus. Wer das nicht möchte, lädt das Skript zuerst herunter, liest es und startet es dann mit sudo python3 setup-periphery.py und denselben Optionen.

Im Log des Dienstes siehst du, dass die Verbindung geklappt hat:

sudo journalctl -u periphery --no-pager | tail -3

OnboardingFlow: Server onboarding flow for 'worker' successful
Logged in to Komodo Core {{domain}} websocket as Server worker

Im Core taucht der Server in der Liste auf:

Bemerkenswert ist die Richtung der Verbindung: Der Agent ruft den Core an. Auf dem neuen Server musst du deshalb keinen Port öffnen. Der Core braucht nur eine erreichbare Adresse, in unserem Fall die HTTPS-Domain hinter Traefik.

Jetzt kannst du Stacks auf dem zweiten Server anlegen. Ich habe den Uptime-Kuma-Stack aus dem Git-Repository nochmal erstellt, diesmal mit dem Server worker.

Auf dem Worker lief der Container danach mit dem Status healthy:

kuma-worker-uptime-kuma-1  louislam/uptime-kuma:2  Up 12 seconds (healthy)

Dieser Stack hat kein Traefik-Label, weil auf dem Worker kein Traefik läuft. Für einen Dienst mit HTTPS brauchst du dort ebenfalls einen Reverse Proxy.

Komodo aktualisieren

Weil ich das Image mit dem Tag 2 verwende, bleibt Komodo bei der Hauptversion 2 und bekommt Updates innerhalb davon:

cd ~/docker/komodo
docker compose pull
docker compose up -d

Die Daten liegen in Volumes und gehen dabei nicht verloren. Vor einem Sprung auf die nächste Hauptversion (von 2 auf 3) lies die Release Notes und mach ein Backup. Den Agenten auf weiteren Servern hältst du mit periphery-Updates aktuell. Das Installationsskript zieht die neueste Version, wenn du es erneut startest.

Wie viel RAM braucht Komodo?

Mit Traefik, Komodo und zwei Stacks lieferte docker stats diese Werte:

Das System insgesamt belegte etwa 1 GB von 3,8 GB. Für Komodo und Traefik zusammen plane ich mit etwa 750 MB ein.

Probleme und Lösungen

Fazit

Komodo ersetzt bei mir kein SSH, nimmt mir aber viel Handarbeit ab: Compose-Dateien liegen versioniert in Git, ein Push deployt sie, ein nächtlicher Lauf sichert die Konfiguration, und mehrere Server teilen sich eine Oberfläche.

Nutzt du Komodo oder eine andere Oberfläche für Docker? Schreib es gerne in die Kommentare.

FAQ