Deployments
Deployment strategies
Classic stop-and-start, zero-downtime blue-green, rolling, and canary or progressive rollouts - and how Phelix selects between them.
Strategies
phelix rebuild supports five deployment paths. All of them compile a new versioned build and start an instance; they differ in when traffic moves and whether downtime is possible.
| Strategy | Downtime | Mechanism |
|---|---|---|
| classic (default) | Brief, during restart | Stop the current instance, start the new build |
| blue-green | None | Start on the inactive slot, health check, atomic proxy switch |
| rolling | None | Replace N replicas one at a time through the proxy |
| canary | None | Route a traffic share to the new version, verify, then promote |
| progressive | None | Increase traffic step by step, verifying each step, until 100% |
Classic deployment
Classic deployment is the lifecycle:
stop → rebuild → startThe current instance is stopped, the project is rebuilt into a new version, and the new instance starts on the configured port. This is the default when no strategy is configured and the simplest path when the app is not served through the Phelix proxy. Brief downtime is inherent: there is a window between stopping the old instance and the new instance accepting requests.
Selecting a strategy
The deployment path is resolved in this order: explicit --blue-green / --replicas flags, then --strategy, then deploy.strategy in phelix.yaml, then the strategy the app is currently deployed with, then classic.
| Selection | Result |
|---|---|
| --blue-green flag | blue-green deploy (same as deploy.strategy: blue-green) |
| --replicas N flag | rolling deploy over N replicas (same as deploy.strategy: rolling) |
| --canary N flag | canary rollout at N percent traffic, then promotion |
| --strategy flag | One-off strategy for this rebuild only; never written back to phelix.yaml |
| deploy.strategy in phelix.yaml | Used when no flag names a strategy |
| (nothing set) | Keep the strategy the app is already deployed with, else classic |
An app already running blue-green or rolling stays on it unless a classic rebuild is asked for explicitly - demoting a live zero-downtime app tears its instances down and drops its deployment state, so it has to be asked for. A rolling rebuild inherited this way keeps the replica count the app is running at.
Blue-green, rolling, and canary require the proxy daemon, which the deploy commands auto-start if it is not already running. Canary and progressive rollouts run on the blue-green topology - see Canary & progressive rollouts. phelix rollback needs no configuration: it inspects the recorded deploy state and automatically uses classic or zero-downtime rollback to match how the app was actually deployed.
Safety guarantees
Every strategy runs inside the same versioning contract: a build creates the version on disk with is_current: false, and the version is promoted (and the current symlink moved) only after the deploy succeeds. A failed deploy leaves the active instance untouched and the pointer uncorrupted - details in the promotion guarantee.