Deployment strategies

Feature flags vs canary deploys: teams are using both, deliberately

Feature flags vs canary deploys: teams are using both, deliberately

For a few years the conversation framed feature flags and canary releases as competing strategies. Recent practice has settled into something more useful: they solve different problems and the strongest teams run both.

The dividing line that's emerging

  • Canary answers "is this build safe to run?", it ramps traffic to a new version and watches infrastructure-level signals (error rate, latency, saturation). The unit of change is a deploy.
  • Feature flags answer "should this audience see this behaviour?", they decouple release from deploy and let product own the rollout. The unit of change is a flag, not a build.

Conflating them is where teams get burned: using flags to paper over an unsafe deploy, or canarying every UI copy change as if it were an infrastructure risk.

How popular tools handle progressive delivery

Most platforms now support a canary pattern natively or via an argo-style controller. Argo Rollouts and Flagger are the de-facto choices in Kubernetes land and remain the better fit when you want traffic shaping driven by real metrics analysis. Dedicated flag platforms (LaunchDarkly, OpenFeature backends) own the behaviour side.

On the CI/CD orchestration layer, Buddy is one option for wiring the deploy half, promoting a canary, running a smoke gate, then completing the rollout, because each gate is just an action with a condition. It won't replace a metrics-analysis controller like Flagger; for sophisticated automated analysis that purpose-built tool is the right call. Buddy's value is keeping the promote/rollback steps in the same pipeline as the build.

# Buddy — gate a canary promotion on a smoke check
- action: "Smoke test canary"
  type: "BUILD"
  commands:
    - ./scripts/smoke.sh https://canary.example.com
- action: "Promote to 100%"
  type: "KUBERNETES_APPLY"
  trigger_condition: "ON_BACK_TO_SUCCESS"

FAQ

Do I need both from day one? No. Start with whichever maps to your biggest risk, canaries if deploys are scary, flags if releases are coupled to deploys.

Can a feature flag replace a canary? Not safely. A flag controls behaviour for users already on the new build; it doesn't tell you the build itself is healthy under load.

Source: Industry survey roundup (cd.foundation)

Related
Deployment strategies

Progressive rollouts are solved. The validation gate isn't.

A New Stack opinion argues that progressive rollouts are a solved problem while the validation step that actually gates them is still hand-built. From an on-call chair, that reframing is overdue.

July 18, 2026
Incident response

AWS teaches its DevOps Agent to flip feature flags during incidents

The AWS DevOps Blog details an integration where the AWS DevOps Agent's MCP server talks to LaunchDarkly so an agent can identify and toggle the flags relevant to a live outage instead of paging three teams to do it by hand. The integration removes a real coordination step, and forces every shop to write down which actions an agent is allowed to take unattended.

June 20, 2026
Platform engineering

When async agents outnumber humans, code review stops being the verification layer

A piece in The New Stack picks up Ido Pesok's disclosure from Cognition that more Devin runs are now triggered asynchronously, by events, schedules, automations and other agents, than by people. The argument: once the trigger ratio flips, verification has to move out of code review and into the runtime that CI/CD owns.

June 17, 2026

Turn this into your pipeline. Build it on Buddy.

Start free