orch

01 · The problem

Make the workflow clear.

A small Docker fleet still needs scheduling, reconciliation, and a clear deployment history. Running containers by hand leaves those responsibilities scattered across scripts and individual machines.

02 · The approach

Give each part a job.

A CLI talks to the server API. The control plane schedules work and reconciles desired state; node agents poll for assignments and operate Docker. Logs, events, and rollout status expose what each component actually observed.

1. 1Operator CLI
2. 2Server API
3. 3Scheduler + reconciler
4. 4Node agent
5. 5Docker Engine

03 · A practical starting point

Try the documented workflow.

./scripts/dev-up.sh
go run ./cmd/orch service ls
go run ./cmd/orch events --service http-api

Run from a repository checkout after following its quickstart. The event command assumes the demo service exists.

04 · The result

Something you can inspect.

The repository provides a local development stack, operator commands, and a concrete separation between control-plane decisions and node execution. The README identifies restart-safe server state wiring as further work; a PostgreSQL store alone is not evidence of a durable runtime.