Deployment strategies

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.

Based on reporting from Industry survey roundup. Summary and analysis are independent and vendor-neutral.

Turn this into your pipeline. Build it on Buddy.

Start free