Canary deployments and feature flag rollouts solve the same problem at different layers. Here's how they actually work, when to use each, and how to combine them.

A canary deployment releases a new version of your application to a small slice of users before rolling it out fully. If something breaks, you catch it at 5% of traffic instead of 100%.

Feature flags solve the same problem at a different layer. Understanding the distinction helps you pick the right tool — and combine them when it makes sense.

How traditional canary deployments work

A canary deployment means running two versions of your application simultaneously in production. Version A is your current stable release. Version B is the new version. A routing layer — a load balancer, a service mesh, or your orchestration platform — directs a percentage of traffic to version B while the rest continues to hit version A.

In Kubernetes, the most common implementation uses two Deployments sharing a single Service selector. The Service routes traffic across all matching pods, so the traffic split is determined by the ratio of replicas:

# stable: 9 replicas
# canary: 1 replica
# → roughly 90% / 10% split

More sophisticated setups use an ingress controller (like NGINX or Traefik) or a service mesh (like Istio or Linkerd) to control the split with explicit weights, independent of replica count. This gives you precise percentages without scaling your fleet.

The key point: a canary deployment is an infrastructure strategy. Both versions of your code are running in production. The routing layer decides which users hit which version.

How feature flag rollouts work

A feature flag rollout is an application-layer strategy. You deploy a single version of your application to all servers. Inside that code, a flag evaluation controls which code path executes for a given user.

import { flaggy } from '@flaggy.io/sdk-js';

const client = flaggy({ apiKey: process.env.FLAGGY_API_KEY });
await client.initialize();

const useNewAlgorithm = client.isEnabled('new-recommendation-engine', {
  key: currentUser.id,
});

const results = useNewAlgorithm
  ? newRecommendationEngine(user)
  : legacyRecommendationEngine(user);

The key field ensures the same user always gets a consistent experience — the percentage is applied by hashing the key, not by random chance per request.

The key point: a feature flag rollout is a code strategy. One binary is deployed. The flag determines which behavior that binary exhibits for each user.

The difference in practice

Both approaches answer the same question: is this change safe at scale before committing fully? But they operate at different layers and have different strengths.

Canary deployments are managed by infrastructure or DevOps teams. Rollback means shifting traffic back to the stable version and eventually tearing down the canary — it’s a deployment operation. All changes in the new version are rolled back together; you can’t independently revert one feature if it shares a deployment with others.

Feature flag rollouts are managed by the team shipping the feature. Rollback means flipping a flag — it takes seconds and requires no deployment. Each feature has its own flag, so you can roll back one independently without touching anything else in the same release.

Another difference: canary deployments work at the traffic level, not the user level. You can route based on headers, cookies, or geographic region — but you’re routing requests, not targeting specific users. Feature flags can target individual users, user attributes, cohorts, or segments. You can enable a feature for your beta group specifically, then expand to a percentage of everyone else.

Percentage rollouts with Flaggy

The basic pattern is a flag with a percentage rollout rule. Start at 5%, verify your metrics look clean, expand in stages.

Monitoring during rollout

Before you expand, you need something to watch:

Error rates. Instrument both code paths with error tracking. An increase in exceptions for users in the new path is the clearest signal something is wrong.

try {
  const results = useNewAlgorithm
    ? newRecommendationEngine(user)
    : legacyRecommendationEngine(user);
  return results;
} catch (err) {
  errorTracker.capture(err, {
    tags: { flagVariant: useNewAlgorithm ? 'new' : 'legacy' }
  });
  throw err;
}

Latency. New code paths are often slower. Tag your performance measurements with the flag variant so you can compare p50/p99 between the two groups.

Business metrics. For user-facing features, watch the metrics that matter for the feature itself — conversion rate, click-through rate, session length. These take longer to accumulate signal but catch subtler problems that error rates miss.

Flag evaluation split. Flaggy’s analytics show the true/false breakdown for each flag in real time. If you set a 10% rollout and the split reads 0% or 100%, something is wrong before your error tracker has had time to accumulate signal.

The rollout ladder

A sensible default for most features:

You can compress this for low-risk changes or extend it for changes with high blast radius. The goal is giving each stage enough time to accumulate error budget signal, not following the ladder for its own sake.

Write the ladder down before you start. On-call engineers shouldn’t have to find the person who created the flag to know whether 25% coverage is expected or a bug.

Targeting canaries at specific users first

Percentage rollouts distribute randomly across your user base. For higher-risk changes, you want more control over who gets the new behavior first.

The pattern: define a segment of internal users or beta testers and enable the flag for that segment before any percentage rollout.

In Flaggy:

Create a segment: “users where email ends with @yourcompany.com”
Enable the flag for that segment — your team gets the new behavior
Run it internally for a few days, file bugs, fix them
Then start the percentage rollout for the broader user base
You can stack these rules: the flag is enabled for the internal segment and for 5% of everyone else. The two targeting rules work independently.

The Free plan includes 3 segments — enough for an internal team, a beta group, and one more. If your rollout workflow needs more than that, the Team plan has unlimited segments.

When to use infrastructure canary deployments instead

Feature flag rollouts handle application-level changes well. There are cases where you need infrastructure-level canaries:

Database schema migrations. Running two versions of your app simultaneously lets you verify the new schema is compatible before fully migrating. A flag can’t help if the migration breaks the old code path.

Dependency and runtime upgrades. Upgrading a major version of a core library, or moving to a new runtime version, is safer to test on a slice of real traffic. These changes affect behavior throughout the app in ways that are hard to wrap in a flag.

Infrastructure configuration changes. Changes to server tuning, connection pool sizes, caching behavior — these need to run on real infrastructure to measure their effect. A flag in application code can’t surface OS-level or infrastructure-level impacts.

For everything else — new UI, changed algorithms, new API endpoints, updated business logic — a feature flag rollout is faster to set up, easier to operate, and gives you better targeting control than an infrastructure canary.

Rollback

The practical advantage of a feature flag over a deployment rollback is speed and granularity. Rolling back a deployment takes minutes and reverts everything in that release. Flipping a flag takes seconds and affects only that feature.

When something goes wrong at 10% rollout, you open the dashboard and move the slider to 0%. The broken code path stops executing immediately for all users. Then you fix the bug and run the rollout again — without touching anything else that shipped in the same deployment.

Flaggy’s free plan supports unlimited flags — there’s no cost to adding a rollout flag to every significant feature you ship.