Pillar guide
Zero-downtime deployment for Go
What zero-downtime deployment means for a Go service, and how Phelix delivers it: a reverse proxy, blue-green and rolling releases, canary rollouts, health gating, and rollback.
Released Phelix hosts: Linux and macOS. Builds Go and Rust with your host toolchain.
What zero-downtime deployment means
Releasing a new version without a window where requests fail.
A naive deploy stops the running process and starts the new one. For the seconds in between, requests have nowhere to go. Zero-downtime deployment removes that gap: the new version comes up and proves itself before any traffic moves to it, and the old version keeps serving until the switch is complete.
Phelix treats this as the default path rather than an add-on. It picks from classic, blue-green, rolling, and canary strategies, described in deployment strategies, and only classic accepts a brief interruption.
A reverse proxy in front of your app
Traffic reaches a host-local proxy, which routes it to the healthy instance.
The proxy is what makes an atomic, safe switch possible. Clients connect to the proxy; the proxy forwards to whichever instance is currently healthy. During a deploy, Phelix changes proxy membership rather than restarting your listener, so the public endpoint never goes down. The proxy model and its persistence are covered in zero-downtime deploys.
Blue-green and rolling releases
Start the new version beside the old one, health-check it, then switch.
Blue-green brings up a full candidate, health-checks it, and cuts the proxy over in one move while the old version drains. Rolling replaces replicas one at a time, so capacity stays up throughout the release. Both are detailed in zero-downtime deploys.
Canary and progressive rollouts
Send a share of traffic to the new version, verify it, then promote.
A canary routes a slice of live traffic to the new version and compares it against the stable baseline using verification thresholds. A progressive rollout steps the share up as it keeps passing, and backs out automatically if it does not. See canary and progressive rollouts.
Health gating decides the cutover
A version takes traffic only after it passes its checks.
Every proxy-based strategy is gated on health. Phelix supports explicit HTTP readiness with automatic HTTP, TCP, and PID fallbacks, so a candidate that never becomes ready never receives requests, and an instance that goes unhealthy later can trigger bounded recovery. The tiers and modes are in health checks.
Health checks reduce risk; they do not prove that every behavior of your application is correct. A candidate that passes its checks can still be wrong, which is exactly why rollback matters.
Rollback is a first-class command
Return to a retained version through the same topology, binary and environment together.
When a release is wrong, roll back to a retained valid version. Phelix reuses the application's current deployment topology, runs the applicable health checks, and records the outcome. Proxy-based rollback can health-gate the switch; classic rollback can have brief downtime. The mechanics and retention rules are in versions and rollback.
The binary and its encrypted environment snapshot roll back together, so a restored version runs with the configuration it was built against. That model is described in environment and security.
Zero-downtime FAQ
Short answers, with the full detail in the docs.
Does Phelix deploy applications without downtime?
Blue-green and rolling deployments start and health-check a candidate before changing HTTP proxy membership. Classic deployment is stop → start and can have brief downtime. Health checks reduce risk but do not prove that every application behavior is correct.
What happens when an application becomes unhealthy?
Repeated endpoint-health failures can trigger bounded restart attempts with an attempt cap. During deployment, an unhealthy candidate stays off traffic. If restoration fails, Phelix records a degraded state that requires manual intervention.
Can I roll back an application?
Yes, to a retained valid native version. Phelix reuses the application's current deployment topology, runs applicable health checks, and records the outcome. Proxy-based rollback can health-gate traffic switching; classic rollback can have downtime.
One binary between git push and production.
Install the CLI, verify the host, and follow the quick start to build your first application.