Versioning and rollback

Versioned builds

Every successful build creates v1, v2, and so on instead of overwriting an existing binary. Each version includes its encrypted environment snapshot and optional tag.

Two-phase promotion guarantee

1. 1
   Create

   Write the binary and encrypted environment snapshot with is_current set to false.
2. 2
   Validate

   Start the candidate and wait for the configured health tier.
3. 3
   Promote

   Only after deployment succeeds, update versions.json and the current symlink.

Rollback

phelix rollback myapp
phelix rollback myapp --to v2
phelix rollback myapp --to 3
phelix rollback myapp --to hotfix-auth-bug
phelix rollback myapp --list

The --to flag accepts a version ID (v3 or 3) or a unique tag name. A tag that matches zero or more than one version returns an error — use a version ID to disambiguate.

Zero-downtime apps recover through health validation and an atomic proxy switch. Classic apps stop, restore, and start with brief downtime. Every attempt — success or failure — is written to rollback.log.

Inspecting versions

phelix rollback myapp --list

Retention

Old versions are pruned automatically after each successful build, keeping the last 5 by default (configurable per plan). The currently active version is never pruned, even outside the window.