Philosophy
Positioning Against Process Managers
Systemg occupies the sweet spot between heavyweight system managers and simplistic process runners—it's a userspace process supervisor designed for modern application architectures. Unlike systemd which requires root privileges and deep OS integration, systemg runs entirely in userspace with a single YAML file (sysg start --config app.yaml), making it perfect for containers, development environments, and situations where you lack system access. Unlike supervisord which hasn't evolved much since 2004, systemg provides modern deployment strategies (rolling restarts with health checks), native webhook support, and cron scheduling without external dependencies or Python runtime overhead.
Technical Architecture
Where systemd manages the entire system boot and supervisor manages legacy daemon processes, systemg focuses exclusively on application service orchestration with zero assumptions about your environment. It's built in Rust as a single static binary with no runtime dependencies, contrasting sharply with PM2's Node.js requirement or supervisor's Python dependency—you get predictable memory usage, instant startup, and deployment simplicity. The persistent state design (~/.local/share/systemg/) means your services survive supervisor restarts, unlike foreman/overmind which lose all state on exit, while the config_hint mechanism eliminates the need to specify configuration paths repeatedly (a common frustration with supervisor's supervisorctl -c).
Service Model Philosophy
Systemg treats services as first-class declarative resources with explicit dependencies, not just background processes to keep alive—imagine Docker Compose's service definitions but for native processes instead of containers. Each service gets automatic log rotation, structured process groups for clean termination (solving supervisor's infamous orphaned subprocess problem), and lifecycle hooks that actually work without shell scripting gymnastics. The topological dependency resolution ensures services start in the correct order and cascade failures appropriately, unlike supervisor's manual priority system or systemd's complex After=/Wants=/Requires= semantics that often surprise users.
Development & Production Convergence
The same systemg.yaml that orchestrates your local development environment scales to production deployments, eliminating the dev/prod divergence that plagues teams using foreman locally but systemd in production. Built-in deployment strategies like rolling restarts with health checks mean you don't need a separate deployment tool—systemg handles the blue-green swap that would require custom systemd units or supervisor event listeners to achieve. The cron integration runs jobs in the same environment as your services (unlike system cron which runs in a minimal environment), while webhook support enables GitOps workflows without additional middleware.
When to Choose Systemg
Choose systemg when you need more than foreman but less than Kubernetes—it excels at orchestrating 5-50 services in a monorepo, managing microservices on a single host, or providing process supervision inside containers where systemd isn't available. It's particularly powerful for polyglot environments where PM2's Node.js focus or supervisor's Python requirement creates friction, and for teams who want Heroku Procfile simplicity with production-grade features like health checks and zero-downtime deployments. If you're fighting systemd's complexity for application services, debugging supervisor's Python tracebacks, or wishing foreman had state persistence and proper logging, systemg provides the modern alternative you've been seeking.