Sencho: a self-hosted Compose control plane that keeps files on disk

The gap Sencho fills between raw Compose and a full orchestrator

Docker Compose is a file format and a CLI. That is enough for one host and one operator, and it stops being enough the moment a second machine enters the picture. The usual workarounds are SSH into each box, a VPN so every host is reachable, or exposing a remote Docker socket on the network, which is a large attack surface for the convenience it buys. Sencho's stated audience is DevOps engineers, platform teams, system administrators and homelab users who run services on Compose and want a graphical interface without giving up file-on-disk workflows. The README is explicit about the boundary it refuses to cross: compose files stay on the host filesystem and remain the source of truth. That single design decision separates it from panels that import a stack into an internal database and then treat the database as authoritative. If your mental model of a deployment is a directory of YAML that you can also edit with vim, Sencho is built for that model rather than against it.

Every instance is a node, and the primary is a proxy

Multi-node was not added later. According to the README, every Sencho instance is the same autonomous node whether it runs alone or as one of many. To manage another machine you install a second Sencho on it and connect the two with a long-lived API token. The primary dashboard then acts as an authenticated HTTP and WebSocket proxy across the fleet. Each node still talks to its own local Docker socket, so there is no remote Docker socket exposed on the network and no SSH requirement. For hosts behind NAT or a strict firewall, the Pilot Agent opens a single outbound WebSocket tunnel to the primary, which means the remote host listens on no inbound port at all. The docker-compose.yml in the repository also documents Sencho Mesh: a Docker network named sencho_mesh that Sencho creates and joins on boot, with a default subnet of 172.30.0.0/24 that can be overridden with SENCHO_MESH_SUBNET. Cross-stack mesh routing therefore needs no extra host ports or firewall rules. The trade-off is honest: node-to-node traffic is a plain HTTP and WebSocket link, and the README tells you to put TLS, a VPN or a private network under any untrusted hop.

Installing Sencho from the saelix/sencho image

The repository ships a docker-compose.yml that runs Sencho as a single container. The image is saelix/sencho:latest and the UI and API are published on port 1852. Three mounts matter. The Docker socket is required for container orchestration. A host directory maps to /app/data for Sencho's internal database of alerts and settings. The compose root must be mounted so that the host path and the container path are identical, which the compose file calls the 1:1 compose path rule. The .env.example file mirrors this with COMPOSE_DIR and DATA_DIR, and DATA_DIR defaults to /app/data inside the container.

services:
  sencho:
    image: saelix/sencho:latest
    container_name: sencho
    restart: unless-stopped
    ports:
      - "1852:1852"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
      - /path/to/your/docker/folder:/path/to/your/docker/folder

Replace the placeholder on the left and the right of that last line with the same real path. If they differ, Compose inside Sencho resolves mounts against a path that does not exist on the host. After the container starts, the UI answers on port 1852 and the first screen is the stack list built from the mounted directory.

The .env.example also exposes operational knobs worth knowing before you scale up. API_RATE_LIMIT defaults to 200 requests per minute per user session, keyed by user ID when authenticated and by IP when not, and node-to-node traffic using node_proxy tokens bypasses it entirely. API_POLLING_RATE_LIMIT defaults to 300 and covers dashboard and status polling, which is the one to raise if many browser sessions sit behind a shared NAT. TRIVY_BIN points at a host-installed Trivy binary, but Sencho first looks for a managed install under DATA_DIR/bin/trivy, and once that exists it takes precedence.

What the deploy path actually guarantees, and what it does not

Sencho advertises atomic deployments with automatic rollback on failure, a Monaco editor with diff preview before save, and one-click rollback to any prior deploy. Health-gated updates hold a rollout until health checks pass, with stalled-update detection and in-app recovery. Compose Doctor runs preflight checks before deploy, and drift detection compares running containers against the effective Compose model. These are the features that make a GUI worth using over a terminal, because they encode a sequence a human would otherwise run by hand. The limitation is that all of it depends on the mounted path being correct and on the Docker socket being reachable. A deployment tool that reads your files and drives your daemon inherits every permission those two things grant. The README treats this as a deployment consideration rather than a defect, and the repository carries a KNOWN_LIMITATIONS.md file alongside SECURITY.md, which is the honest place to look before you trust it with anything you care about. Note also the Node.js engine requirement in package.json: node >=26.0.0. That affects anyone building the image themselves or running the backend outside the published container.

Fleet features that assume more than one host

Once a second node exists, a set of capabilities switches on that are meaningless on a single machine. Fleet Federation cordons nodes and pins Blueprints to specific hosts. Fleet Actions do bulk label operations, fleet-wide stop-by-label and fleet-wide prune. Fleet Secrets let you author environment-variable bundles once and push them to the stacks on labeled nodes, with an audit trail of every change. Fleet Sync pushes scan policies, CVE suppressions and misconfig acknowledgements from a control instance to its replicas. Fleet Dossier exports the whole fleet as a single browsable Markdown archive, and Fleet snapshots capture compose and env across the fleet. Remote updates pull the latest image and recreate any node from the Fleet view without an SSH session. The pattern is consistent: configuration authored centrally, applied by label, recorded in an audit log. That is a coherent model, but it only pays off at three or more hosts. On a single machine, most of this is surface area you will never open, and the App Store, which ships LinuxServer.io templates by default and accepts any Portainer-compatible registry, is the part a one-host user will actually touch.

Komodo and Portainer are the comparisons that matter

Sencho sits between Portainer and Komodo, and the difference is where the source of truth lives. Portainer's App Store is the closest analogue to Sencho's, and Sencho accepts Portainer-compatible registries, so templates are not a reason to pick one over the other. The divergence is the fleet model: Sencho's nodes are peers running the same software, connected by a long-lived token and proxied through the primary, with the Pilot Agent covering NAT. Komodo takes a different route to the same problem, driving Compose and other workloads through its own agent and resource model rather than proxying a peer dashboard. If you have already standardized on Komodo's resource abstraction, Sencho's file-on-disk stance will feel like a step backwards. If you have a directory of compose files you refuse to give up, it will feel like the point. Against plain Compose plus a terminal, the honest answer is that Sencho buys you a UI, an audit log with a 14-day recent-activity window, aggregated log search across the fleet and threshold alerts on CPU, memory and network. If none of those change your day, you are paying container overhead for a wrapper.

Licence, maintenance and the cost of upgrading

Sencho is licensed AGPL-3.0-only, per package.json and the LICENSE file. The practical consequence for most readers is that running it internally on your own hardware is unaffected, while offering a modified version to users over a network triggers the source-availability obligation. That is a description of the licence text, not legal advice; if you plan to embed Sencho in something you distribute, read the licence and the CLA.md and TRADEMARKS.md files in the repository. On maintenance, the last push was on 2026-08-09, and the latest release is v0.97.1 from the same day, following v0.97.0 on 2026-08-06 and v0.96.0 on 2026-07-26. That is a fast release cadence in the weeks before that push. The version number is also the upgrade warning: at 0.97.x the project has not committed to a stable interface, and the README states plainly that as a pre-1.0 project it still evolves quickly. Budget for reading CHANGELOG.md before each bump, and for the fact that release-please and commitlint configuration in the repository signal conventional-commit-driven releases, which means frequent small versions rather than rare large ones. The Community tier is described as including unlimited nodes and users, so the upgrade cost here is operational attention, not licensing.

Editorial conclusion

Adopt Sencho if you already run Compose on one or more hosts and want a GUI that leaves the compose files as the source of truth, and if you can absorb pre-1.0 churn: the README itself says to validate against your own setup before using it on critical infrastructure. Skip it if you need a stable 1.0 API, if your workloads are Kubernetes-shaped rather than Compose-shaped, or if you cannot mount the Docker socket and the compose directory at identical host and container paths. Before deploying, read KNOWN_LIMITATIONS.md, confirm the 1:1 path rule holds for your compose root, and check whether the mesh subnet 172.30.0.0/24 collides with anything you already run.

Frequently asked questions

Official sources

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