Zero-downtime deploys

Reverse proxy

The phelix proxy daemon binds each app's public port and routes traffic to the active internal instance. Blue-green and rolling deploys switch the target atomically through a control socket - no dropped connections.

phelix proxy                # start in background (detaches and returns)phelix proxy status         # show enrolled apps + routingphelix proxy stop           # shut the daemon down (drains up to 30s)phelix proxy --foreground   # run attached (for process supervisors / systemd)

phelix rebuild --blue-green / --replicas will also auto-start the daemon if it is not already running. Canary and progressive rollouts run on the blue-green topology and need the proxy too - see Canary & progressive rollouts.

Proxy persistence

Enrolled apps and their active targets are persisted (~/.phelix/proxy-state.json) and restored automatically when the daemon restarts, so backend instances keep serving through daemon crashes or reboots without any redeploy.

Blue-green

Blue-green keeps two slots per app. The proxy routes public traffic to whichever slot is active; the other slot is the staging area for the next deploy. The full lifecycle:

build  ↓start inactive slot  ↓health check  ↓proxy switch (atomic)  ↓drain previous instance  ↓stop previous instance

A rebuild builds a new binary, starts it on the inactive slot (blue ↔ green) with its own internal PORT, waits until the configured health tier passes, then atomically switches the proxy. The previous instance is drained and stopped.

phelix rebuild myapp --blue-greenphelix rebuild myapp --blue-green --port 8080

Two cleanup behaviors protect the slots: a deploy that loses the proxy mid-flight shuts down its unproven new instance instead of leaking it, and slots left behind by crashed deploys are reclaimed on the next run.

Rolling

A rolling deploy replaces N replicas one at a time. Each replacement starts on a fresh internal port alongside the instance it replaces and joins the proxy only after passing its health check; the old instance is then drained from rotation and stopped. No request is ever routed to a dead port during the roll, and old and new instances coexist until each individual replacement is healthy.

phelix rebuild myapp --replicas 3

Shrinking - passing --replicas N smaller than the current replica count - drains the surplus replicas at the end of the rollout.

Observing deploys

Deploy mode and proxy routing are visible in phelix list and phelix status.

Failure behavior

Rollback for zero-downtime apps follows the identical path - see how rollback works.