Deployments
Deployment strategies
Classic stop-and-start, zero-downtime blue-green, and rolling deploys - and how Phelix selects between them.
Three strategies
phelix rebuild supports three 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 |
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
deploy.strategy in phelix.yaml selects which existing deployment path phelix rebuild uses - it does not introduce a new deployment system. Explicit flags always override the config.
| Selection | Result |
|---|---|
| (nothing set) | classic stop → rebuild → start |
| --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) |
| deploy.strategy in phelix.yaml | used when the flags are not passed |
Blue-green and rolling require the proxy daemon. Both flags auto-start it if it is not already running. 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.