Feature
Zero-downtime deployment
A zero-downtime deploy starts the new version beside the old one, proves it healthy, and only then moves traffic. Phelix does that with a host-local reverse proxy, four strategies, and a rollback path that uses the same topology.
simulated
candidate starting on the inactive slot
Four strategies, one safety contract
Classic deploy is stop-then-start and can drop traffic for a moment. Blue-green starts a full candidate on the inactive slot and switches the proxy atomically. Rolling replaces replicas one at a time, each joining the proxy only after its health check passes. Canary and progressive rollouts send a share of live traffic to the new version and promote it as it keeps passing.
Whichever strategy runs, the version pointer moves only after the deploy succeeds: a failed candidate is killed and the old version keeps serving.
- Blue-green: full candidate, one atomic proxy switch
- Rolling: N replicas replaced behind the proxy
- Canary: a traffic share, verified before promotion
- Progressive: stepped rollout with verification at each step
simulated
0/3 replaced · health before rotation
Health gates decide the cutover
A candidate never receives traffic before it passes its health tier: an explicit HTTP readiness path returning 2xx is strongest, with automatic HTTP, TCP, and PID fallbacks when the app has no endpoint. Without a real readiness endpoint Phelix warns you, because a TCP-accepting process can still be serving errors.
After deploy, repeated endpoint failures can trigger bounded restart attempts; an instance that cannot be restored is recorded as degraded instead of restarting forever.
simulated
a deploy takes the strongest signal the app supports
A way back from every release
Every build is a numbered version with a build report and an encrypted environment snapshot. Rollback inspects how the app was deployed and uses the matching topology, so proxy-based apps roll back with health-gated switching rather than a restart.
A dry-run preview shows the target, strategy, and traffic transition without changing state; a deploy lock keeps rollback from racing another deploy on the same app.
Frequently asked questions
Short answers; the docs go deeper.
What is the difference between blue-green and rolling deployment?
Blue-green runs two full slots and switches all traffic in one atomic move, so a bad candidate is rejected before any request reaches it. Rolling replaces replicas one at a time behind the proxy, which suits services already running more than one instance.
Does zero-downtime deployment require Docker or Kubernetes?
No. Phelix deploys native Go and Rust binaries directly on the host, and the reverse proxy performs the cutover. Docker is optional and used only when you choose to run app instances as containers.
What happens if the new version fails its health check?
The deploy aborts, the candidate is killed, and the currently active version keeps serving. The version pointer is promoted only after a successful deploy.
One binary between git push and production.
Install the CLI, verify the host, and follow the quick start to build your first application.