Comparison
A systemd alternative for Go apps
systemd reliably runs a Go binary as a service, but it has no build, deploy, versioning, rollback, or health-gated cutover. Phelix adds that deploy layer, and can run alongside systemd.
Released Phelix hosts: Linux and macOS. Builds Go and Rust with your host toolchain.
Where each fits
One keeps a service running; the other manages releases.
Reach for systemd when you want a battle-tested init to keep a binary running as a service on a Linux host, with unit files, restarts, and resource limits you manage directly. It is already on the machine and it is excellent at that job.
Reach for Phelix when hand-written units stop scaling: you want versioned builds, real deploy strategies, health-gated zero-downtime cutover, and one-command rollback across one or many hosts, instead of editing a unit and restarting for every release.
Side by side
A neutral capability comparison for Go services.
| Capability | Phelix | systemd |
|---|---|---|
| Role | Build, deploy, supervise, and roll back Go and Rust apps | Init and service manager for Linux |
| Keep a process alive | Yes, per-host supervision | Yes, via unit files and Restart= |
| Build step | Builds Go and Rust binaries with the host toolchain | None; runs a binary you built elsewhere |
| Deploy strategies | Classic, blue-green, rolling, and canary | Swap the binary and restart the unit |
| Zero-downtime cutover | Health-gated proxy cutover between versions | Not provided for app traffic; a restart drops the listener |
| Versioning and rollback | Retained versions, one-command rollback | You track versions and revert by hand |
| Health | HTTP, TCP, and PID tiers gate traffic | Process liveness and an optional watchdog; no traffic gating |
| Multiple servers | Per-agent metrics and logs across hosts | Per host; no cross-host view |
What Phelix adds on top
The release lifecycle a unit file does not cover.
With a plain unit, a new release means replacing the binary and restarting, which drops the listener for a moment and leaves version history and rollback up to you. Phelix builds and numbers each version, deploys it through a chosen strategy with health-gated cutover, and keeps every version one command from rollback. Health uses HTTP, TCP, and PID tiers rather than liveness alone.
systemd can still run underneath
They are not mutually exclusive.
Phelix operates applications on infrastructure you already control, and its own monitor runs as a Linux service. You can keep systemd for host-level services and let Phelix own the application release lifecycle on top. If all you need is to keep one binary alive on one host, a unit file is still the simplest answer.
One binary between git push and production.
Install the CLI, verify the host, and follow the quick start to build your first application.