Phase 2b of the open-core hybrid extraction. After Phase 2a (PR #880) wired the public-side loader to dynamic-import the private package, this PR makes production Docker builds actually install the package so the runtime path uses it. Single image; saelix/sencho remains the only published image (the original ADR's dual-image plan was rejected because customers buying paid tiers would otherwise need GitHub auth to pull a second image, breaking the purchase flow). Dockerfile (prod-deps stage): a new RUN block after npm ci installs @studio-saelix/sencho-pro using a BuildKit secret-mounted github_token for npm.pkg.github.com auth. The .npmrc carrying the token is written and removed inside the same RUN, plus /root/.npm is wiped to scrub any verbose-log artifacts that npm might otherwise stash. The token never enters an image layer (BuildKit excludes secret content from both layer filesystems and cache keys; docker history shows the literal $(cat /run/secrets/...) command, not the substituted value). PRO_PACKAGE_VERSION is a build arg pinned by CI to a literal SemVer (0.1.0 today) so the scan build and the publish build resolve to the same package version. Default of `latest` keeps local builds convenient. When the pro package ships a new version, bump the value in docker-publish.yml in the same PR that ships the matching public Sencho release; release-please does not coordinate the two cadences. Empty-secret branch (no github_token provided, e.g. local dev or fork PRs) skips the install and prints a notice. The resulting image runs through the loader's in-tree LicenseService fallback, so PR validation builds and contributor builds work without any GitHub auth setup. docker-publish.yml: both build-push-action invocations (the pre-publish scan and the multi-arch publish) pass the github_token secret and PRO_PACKAGE_VERSION build arg. The auto-provisioned GITHUB_TOKEN's packages:read scope is sufficient because the public Sencho repo and the private package live in the same Studio-Saelix GitHub org. Moving the package to a different org would silently break this contract; the Dockerfile comment block records the invariant. ci.yml is intentionally not changed. The PR-time Docker validation job builds without the secret and exercises the loader's in-tree fallback path, which is correct for fork PRs (no token access) and useful for catching fallback-path regressions. Test plan: tsc clean (no TS changes). The dockerfile install path is exercised by the next release's pre-publish scan + smoke test, both of which boot the actual image and call /api/health. Failed dynamic import or constructor throw would block bootstrap before the listener binds, so the existing smoke test covers the runtime contract.
Self-hosted Docker Compose management with self-healing infrastructure, atomic deployments, and multi-network fleet control. Built for engineers who want Kubernetes-grade reliability without the complexity.
Why Sencho?
Works across every network
Pilot Agent tunnels through NAT and firewalls so every node in your fleet is reachable from the dashboard, regardless of network topology. No port-forwarding. No VPN. No SSH.
Containers crash. Sencho fixes them.
Auto-heal policies watch your stacks and take action (restart, redeploy, notify) before you even open your laptop. Define the rules once; the recovery runs itself.
Deploy safely without Kubernetes
Atomic deployments mean a failed stack never leaves you in a broken half-up state. Rollback is one click. Deploy enforcement policies block non-compliant images before they ever run.
Define behavior, not procedures
Auto-update policies, scheduled operations, webhooks, and deploy enforcement let you codify how your infrastructure behaves. The UI is for oversight; the engine runs the work.
Features
Stack Management
- Monaco editor with syntax highlighting and multi-file support
- Atomic deployments with live progress tracking and one-click rollback
- Git-sourced stacks: pull and sync from any repository
- Stack file explorer and label management
Monitoring & Observability
- Live log streaming with search and filtering across all containers
- CPU, RAM, and disk threshold alerts with configurable actions
- Container stats, health checks, and image update notifications
- Global observability view across all nodes in your fleet
Fleet Management
- Multi-node via authenticated HTTP/WebSocket proxy (no SSH, no remote socket)
- Fleet view and sync for coordinated updates across nodes
- Pilot Agent for NAT traversal and firewall-crossing connections
- Node compatibility checks before deploying
Automation
- Auto-heal policies: detect and recover from container failures automatically
- Auto-update policies: roll out new image versions on your terms
- Scheduled operations with cron expressions
- Webhooks and deploy enforcement rules
Security
- SSO: custom OIDC (any spec-compliant provider), Google/GitHub/Okta presets, LDAP/Active Directory
- Two-factor authentication and RBAC with deployer, node-admin, and auditor roles
- Audit log, vulnerability scanning with VEX suppression, and private registry support
- Deploy enforcement to block non-compliant images
Operations
- App Store with one-click LinuxServer.io template deployments
- Sencho Cloud Backup for off-site stack archives
- Notification routing to Slack, Discord, email, and webhooks
- Global search across stacks and containers
Architecture
Sencho's architecture combines a Distributed API model with an optional Pilot Agent for complex networks.
- Distributed API: Remote nodes are managed by proxying authenticated HTTP/WebSocket requests to autonomous Sencho instances running on each server. No SSH. No remote Docker socket exposure. No polling agent. Each node speaks the same Sencho API, so the dashboard is just another client.
- Pilot Agent: For nodes behind NAT or strict firewalls, the Pilot Agent establishes secure outbound tunnels to the primary dashboard instance. This guarantees full fleet visibility and management without requiring port-forwarding, VPNs, or inbound network access.
Quick Start
Docker run (quickest):
docker run -d --name sencho \
-p 1852:1852 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v sencho_data:/app/data \
-e COMPOSE_DIR=/opt/docker \
saelix/sencho:latest
Docker Compose (recommended for production):
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
# 1:1 Compose Path Rule: the host path MUST match the container path
- /opt/docker:/opt/docker
environment:
- COMPOSE_DIR=/opt/docker
- DATA_DIR=/app/data
docker compose up -d
Then open http://your-server:1852 and create your admin account.
See the full documentation for configuration details, multi-node setup, and more.
Documentation
Development
# Backend (Express + TypeScript)
cd backend && npm install && npm run dev
# Frontend (React + Vite)
cd frontend && npm install && npm run dev
The frontend dev server proxies /api requests to the backend on port 1852.
Contributing
See CONTRIBUTING.md for development setup and PR guidelines.
Security
See SECURITY.md for vulnerability reporting. Do not open public issues for security vulnerabilities.
License
Sencho is licensed under the Business Source License 1.1. Production use is allowed; the only restriction is offering Sencho as a competing hosted or managed service. On 2030-03-25, the license automatically converts to Apache 2.0.

