v0.65.0 is out
read the release notes
The process manager for busy people.
systemg is an agent-friendly process composer. Services start in dependency order, restart with backoff, and log to one stream — from a single YAML file, with no daemon to install alongside it.
supervise
Dependency-ordered startup
Independent branches start in parallel; dependents wait on a health check, not a sleep.
recover
Restart with backoff
Unsuccessful exits retry on a doubling delay and reset once the process stays healthy.
observe
One prefixed log stream
Every service writes to the same stream, so ordering across processes is preserved.
measured
three of eight benchmarks
Faster, lighter, and recovers better
We ran systemg against Supervisor and Docker Compose across eight benchmarks, and against systemd on installed size — the one metric it compares on without being PID 1. sysg booted a ten-service dependency graph 1.2× faster than Docker Compose — a graph Supervisor cannot express at all — held it on 28× less supervisor overhead than Compose and 1.5× less than Supervisor, and was the only one of the three to recover from its own kill -9 without losing or duplicating the workload.
6.91
s
ten-service graph cold boot
Ten services, five levels deep
Two independent roots and a five-wide fan-in, where every unit whose dependencies are already satisfied is dispatched at once — so the graph boots in five waves rather than ten steps.
1.2× faster than Docker Compose · Supervisor cannot express the graph
sysg 0.65.0
6.91s
Docker Compose
8.31s
1.20× slower
sysg 0.64.4
13.83s
2.00× slower
Supervisor
cannot express this graph
Supervisor has no dependency edges — priority orders starts but never gates on readiness. Compose ran each unit as a container against the host daemon while sysg ran processes in a container, so that lane is indicative rather than controlled.
12.4
MB
supervisor overhead at ten services
What the supervisor itself costs
Memory for the supervisor itself, minus the same ten near-idle services run bare — orders of magnitude apart, so each block is sized against the largest rather than on a shared axis.
28× less supervisor overhead than Docker Compose · 1.5× less than Supervisor
sysg
12.4 MB
Supervisor
18.1 MB
Docker Compose
354 MB
area ∝ MB
Compose is dockerd + containerd + one containerd-shim per container, measured inside the VM; on macOS Docker Desktop adds a further 476 MB host-side. Per added service Supervisor is cheaper than sysg — 0.020 MB against 0.035 MB.
5
/5
recovery checks passed Supervisor 4 · Compose 1
When the supervisor itself is killed
kill -9 the supervisor — dockerd for Compose, not the CLI — then start it again and look at what happened to the workload underneath it.
Supervisor starts a duplicate · Compose terminates the workload
sysg
sysg (new pid)
└─ web pid 77
re-adopted, same pid
Supervisor
supervisord (new)
├─ web pid 77 orphan
└─ web pid 91 duplicate
duplicate started
Docker Compose
dockerd (manual)
└─ web exited
workload terminated
Five checks: services survive, visible while down, no duplicate started, workload kept, recovers unattended. sysg passes five, Supervisor four, Docker Compose one. Docker tested at its default live-restore: false and restarted by hand; Supervisor's services keep running, but supervisord has no record of them and starts a second copy beside the orphan.
Start with the quickstart
One binary, one file, five minutes.