From a working flag to a safe rollout

You can now flip a schema change on per request. The last piece is doing that gradually in production.

As noted previously, the router does not split traffic. It only reads the header or cookie and serves the matching schema. Deciding which requests get the X-Feature-Flag header—1%, then 10%, then 100%—is the job of your load balancer, proxy, or gateway (by IP rules, cohort, percentage, JWT claim, and so on).

A typical rollout looks like:

  1. Shadow first (optional). Run the new subgraph so its result is computed and compared, but not returned to clients. Confirm correctness and performance.
  2. 0% → 1%. Configure your load balancer to add X-Feature-Flag: my-flag to a tiny slice of traffic. Watch error rates and latency.
  3. Ramp up. 1% → 10% → 50% → 100%, pausing at each step to monitor.
  4. Full rollout. Once 100% is healthy, fold the change into the base subgraph permanently.

Retiring the flag

In most cases, a feature flag is meant to be temporary. After the change is fully rolled out and merged into the base subgraph, clean up: remove the header rule at the load balancer, disable and delete the flag (wgc ff disable / wgc ff delete), and retire the old code path. Leaving stale flags around is a maintenance cost.

Clean up

When you are done with this course, remove the exercise resources (warning, this cannot be undone):

1
2
3

Or delete the whole exercise namespace in one step:

1

These commands only remove this course’s Cosmo config. It does not affect other namespaces.

What you learned

You built a feature flag end to end with the Cosmo demo graph:

  • a base products subgraph
  • a products-fs feature subgraph that added Employee.productCount
  • a feature flag composing them
  • per-request serving via X-Feature-Flag or the feature_flag cookie

You saw the same query return different results depending only on the flag, with no redeploy of the base graph necessary.

Beyond the basics

A few things this course did not cover but are worth exploring:

  • Multiple feature subgraphs per flag — bundle changes across several services into one flag.
  • Managing flags in Cosmo Studio — enable, disable, and inspect flags from the UI.
  • The full CLI surfacewgc feature-flag list / update / enable / disable / delete and wgc feature-subgraph update.
  • Labels — only the feature flag defines labels, and those labels decide which supergraph(s) the flag applies to (they must match the graph's label matchers). When a supergraph uses label matchers, put matching --label values on the flag so it targets the right graphs.

Continue in the Cosmo docs and the CLI reference for feature flags and feature subgraphs .

End of the course 🏁

Congratulations on making it to the end! Please finish the final task and click "Course Complete" when you're ready.


Task

Knowledge check (last one!)

After a feature is fully rolled out to 100%, what is the recommended final step?