progressive-delivery
Canary releases with automatic promotion and rollback using Flagger on Flux. Shifts traffic through Gateway API HTTPRoute weights (Envoy Gateway for north-south, Linkerd for east-west), gates each step on success-rate and latency metrics for the canary pods, runs smoke tests before traffic moves, and rolls back on its own when checks fail. Covers install with signed OCI charts, Canary and MetricTemplate design, GitOps ownership, and emergency rollback. Use when asked to "add canary deployments", "roll out gradually", "automatic rollback on errors", "set up Flagger", or "why did my canary roll back". Gateway and routes themselves → /platform-skills:gateway-api. Linkerd mesh issues → /platform-skills:linkerd.
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
The canonical home for this skill is progressive-delivery in nitinjain999/platform-skills
Ship a new version to a slice of real traffic first, promote it only on evidence, and roll it back without a human when the evidence says no.
Read references/progressive-delivery.md before responding. It holds how a Flagger analysis runs, the provider settings for Envoy Gateway and Linkerd, metric rules, GitOps ownership, rollback by situation, and troubleshooting. The working manifests are in examples/progressive-delivery.
This skill is interactive by default. With no arguments, ask how traffic reaches the app (shared Envoy Gateway, Linkerd east-west, both), where metrics come from (Linkerd viz, gateway Prometheus, other), and whether the app has an HPA, then run canary. Never apply resources or change a live Canary yourself.
Mode dispatch
| Mode | What it does |
|---|---|
install | Flagger via Flux from the signed OCI chart, with meshProvider and metricsServer for the user's traffic and metrics |
canary | Canary and MetricTemplates for one app, from examples/progressive-delivery, adapted to its ports, hostname, listener and HPA |
metrics | Design or fix the MetricTemplate queries so they measure the canary pods only, and prove they return data |
debug | Why a canary is stuck, never starts, or always rolls back, from Flagger events and route status |
rollback | The right rollback for the situation: automatic, revert in Git, skipAnalysis, or suspend |
Mode: canary
- Start from
examples/progressive-delivery/app/canary.yaml. SettargetRef,service.portandtargetPort,hosts, andgatewayRefs(the Gateway andsectionNamefor north-south; the Service for Linkerd east-west). - Add
autoscalerRefwhen the app has an HPA. - Pick
interval,stepWeight,maxWeightandthresholdfrom the app's traffic: a check needs enough requests perintervalto be meaningful; a low-traffic app needs a load-test webhook or a longer interval. - If the Canary has webhooks, include
examples/progressive-delivery/app/loadtester.yamlin the app namespace; the webhook URL must name that Service. - Remove the app's hand-written
HTTPRoutein the same change; say so explicitly. - Validate with
kubeconform -strictagainst the CRD catalog, as the example README shows.
Mode: rollback
Use the reference's rollback table. State which objects Flagger owns (primary, generated Services and HTTPRoute) and that the fix for a failed release is always a change in Git, because Flux will keep applying whatever Git says.
Output format
Every mode ends with:
- Changes, as exact files and fields
- Blast radius, in one line (which traffic and for how long)
- Validation, as commands (
kubectl describe canary, the metric query, route status) - Rollback, for the situation in question
- Repository
nitinjain999/platform-skills
- Revision
c2e75b7
- Last updated
- First committed
Canonical home
since Oct 12, 2026
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.