systemg

An agent-friendly general-purpose program orchestrator for busy people.

1. Read the Docs
2. Getting Started
   • 2.1 Installation
3. Why systemg
   • 3.1 Features
4. How systemg compares

$ curl --proto '=https' --tlsv1.2 -fsSL https://sh.sysg.dev/ | sh

Or with Homebrew, on macOS and Linux:

$ brew install ra0x3/tap/sysg

For system-wide deployments, scripts/install-systemg.sh sets up /usr/bin/sysg, /etc/systemg, and /var/lib/systemg — see the security guide.

Nothing supervises the supervisor, so a reboot leaves the machine bare until a service manager starts one. sysg install-boot writes that unit — a systemd unit or a launchd daemon, for the machine or for your own account:

$ sysg install-boot --config /opts/app/sysg.prod.yaml --write --enable

You declare your processes, their dependencies, and their health checks in one file. systemg starts them in topological order, restarts them according to policy, and won't call a rolling deploy done until the new process passes its health check.

It sits in the gap between systemd and Docker Compose. systemd wants to own the whole machine. Compose has the right composition model but makes you adopt containers to get it. Supervisor is close, but has no dependency graph and needs a Python runtime. systemg is one static binary that runs the same in a VM, a container, or on a Raspberry Pi — and everything it knows is readable back out through sysg status and sysg inspect, so scripts and coding agents can drive it as easily as you can.

• Dependency-ordered startup, gated on health checks
• One resident supervisor for many isolated projects
• Rolling deployments: blue-green process swap, health-validated
• Restart policies with backoff
• Cron jobs with overlap detection
• Foreground multiplexed logs with per-service prefixes
• Same-PID live upgrades within a compatible release line
• Process hooks on successful starts and unsuccessful exits
• .env file propagation
• Tracks child processes your services spawn
• CPU/RSS metrics built into status and inspect
• Privileged mode: per-service user/group, capabilities, rlimits, namespaces
• Uses systemd/cgroups when present; needs neither

Full documentation lives at sysg.dev. Maintainers and agents investigating supervisor behavior should begin with DEBUGGING.md.