Deployment strategies

deploy.strategy controls how a new release takes traffic. It is usually set by environment profiles (e.g. canary in prod, rolling everywhere else), but projects can override it like any other key.

Rolling (default)

The Deployment is updated in place with a zero-downtime rolling update (maxUnavailable: 0 when ha: true). With autoRollback: true, a rollout that stalls past its progress deadline automatically reverts to the previous release.

Canary

deploy:
  strategy: canary
  canary:
    steps: [10, 50]        # traffic percentages
    stepInterval: 5m       # healthy time required per step
    analysis: [error-rate, latency-p95]

The old release keeps serving as the primary while the new release runs on a parallel canary track with its own Deployment and Service. Traffic is weighted at the edge — nginx-ingress canary annotations, or natively weighted HTTPRoute backends in gateway mode.

The controller advances through the steps only when the canary has been fully ready for a whole step interval and every analysis gate passes. Past the last step the new release is promoted: the primary is re-rendered from it, the canary track is deleted, and the old release is superseded.

If the canary stalls (with autoRollback) or the metric gates exhaust their failure budget, the rollout aborts: the canary track is deleted and the application points back at the old release — which never stopped serving. The failing gate and value are recorded on the Release and sent to the deploy-notification webhook.

Canary progress is visible everywhere: kubectl get applications shows a Canary column, the API status endpoint includes the current weight and last analysis result, and the console shows a canary badge.

Blue/green

deploy: blueGreen

Two color tracks exist: <app>-blue and <app>-green. A new release stages on the idle color while the stable Service keeps selecting the active one. The moment the staged Deployment is fully ready, the Service selector flips — instant cutover.

The previous color deliberately keeps running until the next release replaces it, which makes rollback instant too: pointing back at the old release just flips the selector to the still-warm color.

curl -X POST -H "Authorization: Bearer $TOKEN" \
  "$PAGIFIER_URL/v1/applications/my-app/environments/prod/rollback"

Blue/green briefly doubles capacity during a rollout, and the idle color keeps running between releases by design — that standby capacity is the price of instant rollback.

Choosing a strategy

	Rolling	Canary	Blue/green
Extra capacity	none	one traffic slice	2× during rollout
Bad release blast radius	full	one step's traffic %	zero until cutover
Rollback speed	redeploy	primary never stopped	instant selector flip
Requires	—	ingress (edge weighting)	—
Metric gates	—	✅	—