sencho: Self-hosted Docker Compose management platform. For single or multi-host compose-first workflow.

Compose-Verwaltung für eine Maschine oder eine Flotte | sencho

Sencho ist eine selbst gehostete Docker-Compose-Verwaltungsplattform für DevOps-Ingenieure, Plattformteams, Systemadministratoren und Homelab-Benutzer. Es läuft als einzelner Container auf Ihrer Hardware und bietet eine grafische Oberfläche für gängige Compose-Operationen: Bereitstellen von Stacks, Bearbeiten von Compose-Dateien, Anzeigen von Logs, Neustarten von Containern, Durchsuchen von Volumes und Wiederherstellen nach Fehlern. Die Compose-Dateien bleiben auf dem Host-Dateisystem und bleiben die Quelle der Wahrheit; Sencho ersetzt nicht den Datei-auf-Disk-Workflow. Das Projekt ist Pre-1.0, und die README warnt, dass es sich schnell weiterentwickelt. Benutzer sollten die bekannten Einschränkungen überprüfen und vor der Bereitstellung auf kritischer Infrastruktur gegen ihr eigenes Setup validieren.

Bei Studio-Saelix/sencho sollte dieser Punkt direkt anhand der README-Beispiele geprüft werden. Der dokumentierte Befehl, die genannte Konfigurationsdatei und die sichtbare Ausgabe bilden dabei die konkrete Vergleichsbasis; allgemeine Versprechen des Projektnamens ersetzen diese Beobachtung nicht. Prüfpunkt 1 für sencho.

Multi-Node ohne SSH | sencho

Multi-Node-Unterstützung war von Anfang an Teil der Architektur. Jede Sencho-Instanz ist derselbe autonome Knoten, ob allein oder als Teil einer Flotte. Um eine andere Maschine zu verwalten, installieren Sie ein zweites Sencho darauf und verbinden die beiden mit einem langlebigen API-Token; das primäre Dashboard fungiert dann als authentifizierter HTTP- und WebSocket-Proxy über die Flotte. Der Remote-Knoten führt kein SSH für Sencho aus, setzt seinen Docker-Socket nicht im Netzwerk aus und führt keinen separaten Agentenprozess aus. Für Knoten hinter NAT oder strengen Firewalls stellt der Pilot Agent einen einzelnen ausgehenden WebSocket-Tunnel zum Primärknoten her, sodass der Remote-Host keinen eingehenden Port öffnet. Die README empfiehlt die Verwendung von TLS, VPN oder einem privaten Netzwerk für jede nicht vertrauenswürdige Verbindung.

Bei Studio-Saelix/sencho sollte dieser Punkt direkt anhand der README-Beispiele geprüft werden. Der dokumentierte Befehl, die genannte Konfigurationsdatei und die sichtbare Ausgabe bilden dabei die konkrete Vergleichsbasis; allgemeine Versprechen des Projektnamens ersetzen diese Beobachtung nicht. Prüfpunkt 2 für sencho.

Stack-Lebenszyklus, Beobachtbarkeit und Flottenwerkzeuge | sencho

Die Funktionsliste deckt Stack-Lebenszyklus, Beobachtbarkeit, Flottenverwaltung, Automatisierung, Sicherheit und Betrieb ab. Zu den Stack-Tools gehören atomare Bereitstellungen mit automatischem Rollback bei Fehlern, ein Monaco-Editor mit Diff-Vorschau und Ein-Klick-Rollback zu früheren Bereitstellungen, Health-Gated-Updates, die Rollouts bis zum Bestehen der Prüfungen zurückhalten, Git-basierte Stacks, Drift-Erkennung, die laufende Container mit dem effektiven Compose-Modell vergleicht, Umgebungs- und Geheimnis-Schutzmaßnahmen, Speicherportabilitätsprüfungen, Vorabprüfungen über Compose Doctor, Stack-Labels und einen App-Store mit LinuxServer.io-Vorlagen. Beobachtbarkeit umfasst aggregierte Logsuche und -streaming über die Flotte, Live-Container-Statistiken, Health-Checks, Image-Update-Benachrichtigungen, Schwellenwertalarme für CPU, Speicher und Netzwerk, ein schreibgeschütztes Audit-Log, Netzwerktopologieansichten und Dokumentationsdrift-Flags. Flottenfunktionen umfassen Raster- und Topologielayouts, Flotten-Snapshots von Compose und Env, Cordoning und Pinning über Fleet Federation, Massen-Label-Operationen, flottenweites Stoppen und Pruning, Flotten-Dossier-Export, Docker Label Audit, Remote-Updates und Knoten-Labels. Automatisierung umfasst Auto-Heal-Richtlinien, Auto-Update-Richtlinien, geplante Operationen auf Cron, Webhooks und deklarative Blueprints mit Drift-Erkennung. Sicherheitsfunktionen umfassen SSO mit OIDC und Presets, Zwei-Faktor-Authentifizierung mit TOTP, RBAC mit Admin- und Viewer-Rollen, Schwachstellenscanning über Trivy mit VEX-Unterdrückung und SARIF-Export, einen Compose-Netzwerkinspektor und Unterstützung für private Registries. Betrieb umfasst Off-Site-Stack-Archive auf S3-kompatiblen Speicher, Benachrichtigungsrouting zu Slack und Discord, globale Suche und eine Ressourcenansicht für Images, Volumes und Netzwerke.

Bei Studio-Saelix/sencho sollte dieser Punkt direkt anhand der README-Beispiele geprüft werden. Der dokumentierte Befehl, die genannte Konfigurationsdatei und die sichtbare Ausgabe bilden dabei die konkrete Vergleichsbasis; allgemeine Versprechen des Projektnamens ersetzen diese Beobachtung nicht. Prüfpunkt 3 für sencho.

Zugriffskontrolle und der Docker-Socket | sencho

Sencho kommuniziert mit Docker über den /var/run/docker.sock des Hosts. Die README stellt fest, dass das Mounten dieses Sockets Sencho die gleichen Rechte wie sudo docker auf dem Host gewährt, was dasselbe Modell ist, das auch Portainer, Dockge und Komodo verwenden. Für strengere Isolation beschreibt die Dokumentation die Ausführung mit einem Nicht-Root-Container-Benutzer und die Platzierung eines Reverse-Proxys, der Authentifizierung erzwingt, vor Sencho. Die oben aufgeführten Zugriffskontrollfunktionen, einschließlich SSO, 2FA, RBAC und API-Tokens, sind Teil dieser Geschichte, aber die README behauptet nicht, dass Sencho selbst eine Sicherheitsgrenze ist; sie weist darauf hin, dass der Benutzer das Risiko des Socket-Zugriffs verwalten muss. Der Lizenzauszug sagt nichts über Sicherheitshaltung, Support oder Garantie aus; es ist nur eine Softwarelizenz.

Bei Studio-Saelix/sencho sollte dieser Punkt direkt anhand der README-Beispiele geprüft werden. Der dokumentierte Befehl, die genannte Konfigurationsdatei und die sichtbare Ausgabe bilden dabei die konkrete Vergleichsbasis; allgemeine Versprechen des Projektnamens ersetzen diese Beobachtung nicht. Prüfpunkt 4 für sencho.

Telemetrie und Datenverarbeitung | sencho

Die README besagt, dass Sencho keine Telemetrie, Analysen oder Absturzberichte aussendet und keine ausgehenden Aufrufe an von Sencho kontrollierte Endpunkte macht. Stack-Metadaten, Container-Inventar und Benutzeraktivität verlassen Ihre Instanz nie. Diese Behauptung gilt nur für das Projekt selbst; Drittanbieterkomponenten wie der optionale Trivy-Scanner können ein eigenes Verhalten haben, aber die README diskutiert das nicht. Die Repository-Metadaten listen 394 Sterne und 16 Forks auf, aber die README liefert keine Leistungs- oder Zuverlässigkeits-Benchmarks.

Bei Studio-Saelix/sencho sollte dieser Punkt direkt anhand der README-Beispiele geprüft werden. Der dokumentierte Befehl, die genannte Konfigurationsdatei und die sichtbare Ausgabe bilden dabei die konkrete Vergleichsbasis; allgemeine Versprechen des Projektnamens ersetzen diese Beobachtung nicht. Prüfpunkt 5 für sencho.

Schnellstart mit einem einzelnen Container | sencho

Der Schnellstart verwendet einen einzelnen Container. Die README bietet eine Docker-Compose-Servicedefinition mit dem Image saelix/sencho:latest, einer Portzuordnung von 1852:1852, einem Volume-Mount des Docker-Sockets und eines Datenverzeichnisses sowie den Umgebungsvariablen COMPOSE_DIR und DATA_DIR. Sie spezifiziert auch eine 1:1-Compose-Pfadregel: Der Host-Pfad muss mit dem Container-Pfad für das Compose-Verzeichnis übereinstimmen. Nach dem Ausführen von docker compose up -d öffnen Sie http://your-server:1852 und erstellen ein Admin-Konto. Die README empfiehlt, Sencho in Produktionsumgebungen immer mit einem TLS-terminierenden Reverse-Proxy abzusichern. Es gibt auch eine docker-run-Alternative, aber die README beschreibt keine Konfiguration über diese Grundlagen hinaus; für die vollständige Anleitung verweist sie auf den Schnellstart-Leitfaden.

Bei Studio-Saelix/sencho sollte dieser Punkt direkt anhand der README-Beispiele geprüft werden. Der dokumentierte Befehl, die genannte Konfigurationsdatei und die sichtbare Ausgabe bilden dabei die konkrete Vergleichsbasis; allgemeine Versprechen des Projektnamens ersetzen diese Beobachtung nicht. Prüfpunkt 6 für sencho.

Lizenz, Community-Tier und Admiral | sencho

Sencho ist freie Open-Source-Software unter AGPL-3.0. Die README besagt, dass das Community-Tier alles Aufgeführte mit unbegrenzten Knoten und Benutzern umfasst. Ein kostenpflichtiger Plan namens Admiral fügt einen Hardened Build, Recovery Vault mit verwalteten Off-Site-Snapshots, Priority-Support und Governance-Funktionen wie erweiterte RBAC, LDAP/Active Directory, vollständigen Audit-Log-Export und Anomalieerkennung hinzu. Fleet Sync Policy-Replikation und AWS-ECR-Anmeldeinformationen erfordern derzeit ebenfalls Admiral, obwohl die README diese als temporäre Verfügbarkeitsbeschränkungen bezeichnet. Der Lizenzauszug (Präambel und Bedingungen der AGPL-3.0) gewährt das Recht, die Software zu kopieren, zu verbreiten und zu modifizieren, und verlangt, dass modifizierte Versionen, die auf einem Netzwerkserver laufen, den Benutzern zugänglich gemacht werden. Es sagt nichts über Garantie oder Support; die Lizenz lehnt sie in ihren Standardbedingungen ausdrücklich ab, aber der Auszug enthält diesen Text nicht. Die README erwähnt auch Marken und eine separate TRADEMARKS.md-Datei.

Bei Studio-Saelix/sencho sollte dieser Punkt direkt anhand der README-Beispiele geprüft werden. Der dokumentierte Befehl, die genannte Konfigurationsdatei und die sichtbare Ausgabe bilden dabei die konkrete Vergleichsbasis; allgemeine Versprechen des Projektnamens ersetzen diese Beobachtung nicht. Prüfpunkt 7 für sencho.

Redaktionelles Fazit

Geeignet ist sencho für Teams, deren Aufgabe zu den im README beschriebenen Eingaben, Laufzeiten und Integrationen passt. Nicht geeignet ist das Projekt als Ersatz für ungeprüfte Produktionsannahmen. Zuerst sollten der dokumentierte Einstieg, die zentrale Ausgabe und der für sencho genannte Integrationspunkt in einer kleinen Testumgebung ausgeführt werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes