Quick Summary: Stop letting third-party dashboards add 200ms of latency to your application logic; moving feature flags back into your Git repository ensures type safety, zero latency, and an actual audit trail that DevOps can trust.

Feature Flags Belong in Your Codebase, Not a dashboard

I still wake up in a cold sweat thinking about Black Friday 2019. I was the lead SRE for a mid-sized e-commerce platform, and we were relying heavily on a popular SaaS feature flag provider—I won’t name names, let’s just call them “LaunchDarkish.”

Traffic to prod-web-01 spiked, and the provider’s API latency drifted from 20ms to 500ms. Suddenly, our storefront wasn’t just slow; it was rendering white screens because the frontend was blocked, waiting for permission from a remote server just to decide whether to show the “New Checkout” button. We were paying thousands of dollars a month to introduce a single point of failure that took down our site during peak traffic. That was the moment I realized: Why are we asking a remote server permission to run code that is already on our own infrastructure?

The “Why”: We Optimized for the Wrong Person

The industry sold us a lie. They told us we needed complex, third-party dashboards so that Product Managers could toggle features without “bothering” developers. But look at your actual flag usage. In my experience at TechResolve, 90% of flags are technical:

• Circuit breakers for prod-db-legacy migrations.
• Canary releases for backend API refactors.
• Kill switches for specific regions.

By decoupling these definitions from the codebase, we created a massive disconnect. When the flag lives in a dashboard, it isn’t version controlled with the code it toggles. You merge the PR, but forget to flip the switch in the SaaS UI, and boom—production incident. The root cause isn’t just latency; it’s a lack of Source of Truth.

The Fixes: Taking Back Control

I recently saw a discussion gaining traction about building tools where flags live in the repo. This is the way forward. Here is how we handle this transition, ranging from “quick and dirty” to “architecturally sound.”

Solution 1: The Quick Fix (The “Hot-Swap” JSON)

If you are bleeding money on a SaaS provider or suffering from latency, you can rip it out this afternoon. The simplest solution is a JSON configuration file that your application reads at runtime. You don’t need a database.

I call this the “Poor Man’s Control Plane.” You mount a Kubernetes ConfigMap or just sync a file to the server.

// config/flags.json
{
  "new_payment_flow": {
    "enabled": true,
    "rollout_percentage": 20,
    "allowed_users": ["darian.vance@techresolve.com"]
  },
  "legacy_db_write": false
}

Pro Tip: Don’t bake this into the Docker image if you need instant toggles. Mount it as a volume. If you change the file, your app should detect the file change (using `fs.watch` in Node or `fsnotify` in Go) and update its internal state without a restart.

Solution 2: The Permanent Fix (Git-Native Type Safety)

This is the “Holy Grail” approach discussed in the thread. Instead of treating flags as dynamic data, treat them as code. You define your flags in a strictly typed schema within your repository.

When you define flags in code, you get compile-time safety. No more typos causing crashes because you checked for new_header but the dashboard called it New-Header.

Here is what the implementation looks like in a modern TypeScript environment using a tool closer to the metal:

// features.ts
export const features = {
  checkoutV2: {
    options: [true, false],
    defaultValue: false,
    description: "Enables the React-based checkout flow"
  }
} as const;

// usage.ts
import { features } from './features';

// The compiler knows this is a boolean. 
// If you delete the flag in 'features.ts', this line throws a build error.
if (getFlag(features.checkoutV2)) { 
  renderNewCheckout();
}

This approach requires a CI/CD pipeline step. When you merge a PR changing a flag, your pipeline deploys the new config artifact. Is it slightly slower than a toggle button? Yes. Is it infinitely safer? Absolutely.

Solution 3: The ‘Nuclear’ Option (Environment Injection)

Sometimes, you just need a kill switch that works even if your file system is corrupt or your deployment pipeline is jammed. This is what I use for critical infrastructure protections, like turning off a recommendation engine that is thrashing prod-db-01.

We inject these directly into the container environment. It’s ugly, it requires a redeploy (or a pod restart), but it is the most reliable mechanism in existence.

# kubernetes-deployment.yaml
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: backend-api
          env:
            # THE NUCLEAR SWITCH
            - name: FEATURE_DISABLE_RECOMMENDATIONS
              value: "true"

I admit, this is hacky for daily product work. But for DevOps safety valves? It beats an HTTP request to a dashboard every single time.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions