Flags as code

Two things stay out of the files deliberately. The first is evaluation: reading a flag's value for a given user happens in your application through an SDK, in memory, on the request path, and no configuration file is involved. The second is fast toggling. Turning a flag off during an incident has to be immediate, and routing it through a pipeline adds minutes to recovery for no gain, so the kill switch stays on the dashboard or the API. What is left is the long-lived structure, which is exactly the part that accumulates and benefits from review. A walkthrough of the workflow covers the review checklist and the CI pipeline, and a worked Terraform setup covers the resources and the import path.

Drift is any difference between what the files declare and what the platform is serving. Infrastructure tooling treats that as a defect and corrects it on a schedule, which is the wrong instinct here: a flag someone turned off at 3am is drift, and reverting it automatically would undo an incident response. Two habits follow. Declare only what you are willing to have reverted, because rules are usually authoritative once managed, and a rule added in the dashboard disappears on the next apply. And reconcile on a decision rather than a timer, folding real drift back in as a pull request afterwards. Most established flag platforms offer a Terraform provider or an equivalent API for this, and they differ mainly on who can reach it, since some reserve it for higher tiers. Featureflip's Terraform provider and management API work on every plan including the free one.