Should Engineering keep them because they built the feature? Should Product take over because they’re responsible for launches and customers? Or should both teams share ownership, set some clear rules, and avoid turning every rollout into a small internal debate?

The honest answer is: both Product and Engineering should own feature flags, but not in the same way.

Engineering should own the technical side: implementation, safe defaults, stability, and rollback. Product should own the rollout side: launch timing, user targeting, customer exposure, and experiments.

That sounds simple enough. But in real life, this is where things often get messy. So let’s break it down.

Why Feature Flag Ownership Matters​

At first glance, feature flags look simple. Just a switch, right? Not quite.

A feature flag can control much more than the visibility of a button. It may control:

• access to a new feature
• which accounts can join a beta program
• plan-based or account-based access
• A/B tests and product experiments
• percentage rollouts
• operational kill switches
• risky backend behavior
• customer-facing changes in production

In one case, changing a flag may reveal a small user interface element. In another, it may affect authentication, payments, permissions, backend processing, or a critical customer workflow.

That is a lot of responsibility for something that looks like a toggle.

When ownership is unclear, familiar problems start appearing:

• A feature is enabled before Support or documentation is ready.
• Targeting rules are changed without the rest of the team knowing.
• Product has to ask Engineering to make every small rollout adjustment.
• A temporary release flag quietly becomes permanent technical debt.
• Nobody knows who can make an emergency change in production.
• A customer receives access to something they were not supposed to see yet.

None of this is usually dramatic at first. It is more of a slow, annoying kind of confusion. The kind where people start checking old tickets, scrolling through Slack threads, and asking around until someone finally says, “Oh, I think that was created for the beta last quarter.”

Clear ownership prevents that. It tells everyone:

• what the flag is for
• who owns its implementation
• who controls its rollout
• who can change it in production
• what the safe fallback is
• when the flag should be removed

Good feature flag ownership makes releases calmer. It gives Product more flexibility without making Engineering nervous. It gives Engineering technical control without turning every rollout into a bottleneck. And that is the balance we are looking for.

Why Engineering Should Own the Technical Side​

From an engineering perspective, handing over control of feature flags can feel risky, and for good reason.

1. Feature flags live in the code​

Engineers write the condition logic, define the defaults, and build the safeguards. They are the ones who understand what happens behind the scenes when a flag is turned on or off.

A flag might change a small UI element, but it might also affect backend behavior, permissions, payment flows, or integrations. That difference is not always obvious from the dashboard.

This is why Engineering should decide how a flag is implemented and what the safe default should be.

2. They’re responsible for stability​

If a feature flag misbehaves in production, it is usually Engineering that has to investigate. They are the ones checking the logs, looking at errors, rolling back behavior, and trying to understand what changed. So when engineers care about who can change flags, they are not being difficult. They are thinking about risk.

This is especially true for flags that touch sensitive parts of the system, like authentication, billing, permissions, infrastructure, or critical customer workflows.

3. Environment drift drives them crazy​

There’s also the issue of consistency. Engineers care deeply about environments behaving the same way. If a flag behaves one way in development, another way in staging, and something completely different in production, debugging turns into detective work very quickly. And not the fun kind.

Clear rules around environments, defaults, and rollout paths help avoid that confusion. This is also where good feature toggle management becomes important. It is not enough to create flags. Teams also need to manage them clearly across environments and over time.

4. They handle emergency rollbacks​

When things go wrong, Engineering is usually the team handling it.

Kill switches, emergency rollbacks, incident response, quick fixes — this is all part of their world. If a flag creates production risk, Engineering needs the authority to turn it off quickly.

This does not mean Engineering should control every rollout decision. But it does mean they should define the technical boundaries.

From this viewpoint, keeping feature flags under Engineering control feels less like preference and more like a responsibility.

Why Product Should Own the Rollout Side​

Now switch perspectives. For Product teams, feature flags are not just technical tools. They are how releases actually happen.

1. Launch timing belongs to Product​

Features are tied to customer rollouts, campaigns, betas, demos, documentation, support readiness, and sometimes very specific deadlines.

If Product has to ask Engineering every time a feature needs to be enabled, delayed, or adjusted, the process becomes slow very quickly. And that defeats one of the biggest reasons teams use feature flags in the first place.

Feature flags separate deployment from release. Engineering can deploy code when it is ready. Product can release the feature when the business is ready.

This is especially useful in teams that practice progressive delivery, where a release is not treated as one giant moment. Instead, teams roll features out gradually, observe what happens, and expand with more confidence.

2. They understand user segmentation​

Product teams often know who should see a feature first. Maybe it should go to internal users before customers. Maybe it should be enabled for a few design partners. Maybe it should only be available in one region, for one plan, or for a specific customer segment. That kind of targeting is not just configuration. It is a strategy.

In B2B SaaS, this matters even more. A rollout can affect customer conversations, onboarding, pricing, demos, support tickets, and renewal discussions.

Product has the context to make those decisions.

This is also why feature flags are useful beyond simple on/off releases. They can support beta programs, account-based rollouts, plan-based access, and even fake door testing when teams want to validate demand before fully building a feature.

3. Experiments live in Product’s world​

A/B tests, gradual rollouts, feature exposure, and product experiments are all part of how Product teams learn. They may want to start an experiment, pause it, expand it, or stop a losing variant. If every change needs an engineering ticket, experimentation slows down.

Feature flags give Product teams the flexibility to learn from real users without turning every change into a deployment. From their point of view, not having control over feature flags slows everything down. And they are right, too.

The Best Model: Shared Feature Flag Ownership​

Feature flag ownership should not be treated as a Product versus Engineering problem. It is a workflow problem. Feature flag ownership has several layers. Someone needs to implement the flag. Someone needs to define the default state. Someone needs to decide who sees the feature. Someone needs to monitor the rollout. Someone needs to turn it off if something goes wrong. And someone needs to remove it when it is no longer needed.

Trying to put all of that on one team usually creates problems.

If Engineering owns everything, Product becomes dependent on Engineering for every rollout change. This slows down launches and makes feature flags feel less useful for non-technical teams.

If Product owns everything, Engineering may lose control over technical risk. This can create production issues, especially when flags affect critical flows or complex backend behavior.

The better model is shared ownership with clear boundaries.

1. Engineering owns safety​

Engineering should be responsible for the technical foundation of each feature flag. That includes implementation, safe defaults, fallback behavior, environment consistency, and rollback options. Engineering should also decide whether a flag is safe for Product to control.

For example, a simple UI visibility flag may be fine for Product to manage directly. A flag that changes authentication, permissions, payments, infrastructure behavior, or backend processing should probably have stricter rules.

Engineering should also own the cleanup of temporary flags. This part is easy to forget, but it matters a lot. A release flag that stays in the codebase long after the feature has launched becomes technical debt. Over time, these old flags make the code harder to read and the system harder to understand.

At some point, nobody remembers whether a flag is still needed. Then everyone becomes afraid to delete it. And that is how a small toggle turns into permanent clutter.

2. Product owns rollout​

Product should own the rollout decisions. Once Engineering has implemented the flag safely, Product should be able to decide when and how the feature reaches users. That might mean enabling it for internal users first, then beta customers, then a small percentage of users, and finally everyone.

Product also owns the customer and business context. They know which customers should get early access, which plans should include the feature, and when a rollout should wait because documentation or support material is not ready yet.

A feature flag can be the difference between “we are launching this to everyone today” and “we are giving this to three design partners first, learning from them and expanding next week.”

The second version is usually much safer. And much less stressful.

3. Everyone shares visibility​

Shared ownership only works if everyone can see what is happening. Feature flags should not become mysterious switches that only one person understands. Both Product and Engineering should know what a flag does, who owns it, whether it is temporary or permanent, who can change it, and what happens if it is turned off.

This visibility is also useful for Customer Success, Support, Sales, and Marketing.

They may not need permission to change flags, but they often need to understand which customers have access to which features. If a customer asks why they can see a new feature but another team member cannot, Customer Success should not have to start a full investigation.

The information should be easy to find. Good visibility prevents confusion. It also makes feature flags more useful across the whole company, not just inside Product and Engineering.

This is one reason why choosing the right feature flagging tool matters. The tool should not only help developers evaluate flags in code. It should also give the wider team a clear place to understand rollouts, targeting, permissions, and environments.

Different Flags Need Different Owners​

One reason feature flag ownership can feel complicated is that not all flags are the same.

A temporary release flag is different from a long-term access-control flag. An experiment flag is different from an operational kill switch. Treating all of them the same way usually leads to confusion.

A release flag is usually temporary. It hides a feature until the team is ready to launch it. Engineering typically owns the implementation, while Product owns the rollout. Once the feature is fully released and stable, Engineering should remove the flag from the codebase.

An access-control flag is usually longer-term. It controls who can use a feature, often based on plan, customer, region, or account. Product may own the business rules, Customer Success may care about specific accounts, and Engineering owns the technical setup. These flags can stay around longer, but they need clear documentation.

An experiment flag is used for A/B testing or product experiments. Product or Growth usually owns the experiment, while Engineering owns the implementation. Once the experiment ends, the old variant should be removed. Otherwise, the codebase slowly fills up with past experiments nobody wants to touch.

An operational flag is usually owned by Engineering. These flags protect the system. They might disable an external integration, reduce load, or turn off risky behavior during an incident. Product should know they exist, but Engineering should usually control them.

This distinction makes ownership much clearer. Instead of asking who owns all feature flags, teams can ask what type of flag they are dealing with and assign ownership from there.

Common Mistakes Teams Make​

1. Giving everyone access to everything​

It may feel flexible at first, but not every flag is safe to change without context. A flag may look harmless in the dashboard, but it could affect a sensitive backend process or customer-facing flow. The fix is not to lock everyone out, but to give people the right level of access.

Product should be able to manage rollout flags. Engineering should control high-risk technical flags. Customer-facing teams may only need visibility. Everyone gets what they need, without creating unnecessary risk.

2. Making Engineering the bottleneck for every flag change​

If Product has to create a ticket or send a Slack message every time they want to adjust a safe rollout, feature flags lose a lot of their value. They should give teams more flexibility, not create a new dependency.

3. Forgetting to clean up old flags​

A flag is created for a release, the feature goes live, and then everyone moves on. A few months later, nobody remembers if the flag is still needed. A year later, everyone is afraid to delete it. This is how feature flag debt builds up.

A Simple Ownership Checklist​

Before creating a new flag, it helps to answer a few basic questions:

• What is this flag for?
• Is it temporary or permanent?
• Who owns the technical implementation?
• Who owns the rollout?
• Who can change it in production?
• What is the safe default value?
• What happens if the flag is turned off?
• When should it be removed?

This does not need to turn into a heavy approval process. The goal is simply to avoid guessing later. If your team can answer these questions, you are already in a much better place.

So, Who Should Own Feature Flags?​

The cleanest answer is this: Engineering owns implementation and safety. Product owns rollout and exposure. Both teams share visibility and responsibility.

This model avoids the two extremes. Engineering does not become a bottleneck for every safe rollout change. Product does not get unrestricted control over risky technical behavior. Everyone has more clarity about what is live, what is hidden, what is being tested, and what needs to be cleaned up.

Feature flags work best when they are treated as a shared release tool, not as a territory one team needs to defend.

Final Thoughts​

Feature flag ownership is not really about who gets the power. It is about who has the right context for each decision.

Engineering has the context to make flags safe. Product has the context to decide how and when features should reach users. Customer-facing teams often have the context to understand how those changes affect real customers.

When that context is shared, feature flags become much more than toggles. They become a better way to release software. And that is the whole point. Not more switches. Better releases.

Want To Make Feature Flag Ownership Easier?​

If your team wants Product and Engineering to work together on releases without stepping on each other’s toes, ConfigCat can help.

ConfigCat gives teams one shared place to manage feature flags, rollouts, targeting, permissions, and environments. Engineering can keep risky flags protected, Product can manage safe rollout changes, and everyone can see what is happening before, during, and after a release.

You can also connect ConfigCat with the tools your team already uses through integrations, join the ConfigCat Slack Community if you want to talk to others, or reach out to support when you need help.

And because ConfigCat has transparent pricing and a Forever Free plan with all features included, your whole team can try feature flagging without seat limits.

You can find more information about ConfigCat on X, Facebook, LinkedIn and GitHub.

But once feature flags become part of your release workflow, another question comes up: should your application code depend directly on one feature flag vendor's SDK?

That is where OpenFeature can help.

In this guide, we'll look at what OpenFeature is, how it works with ConfigCat, and how to use the ConfigCat OpenFeature Provider for Node.js in a simple Express API.

What Is OpenFeature?​

OpenFeature is an open specification that provides a unified API for evaluating feature flags, regardless of the feature flag vendor you choose.

Instead of calling a vendor SDK directly throughout your codebase, your application calls the OpenFeature SDK. Then, an OpenFeature provider connects those calls to your chosen feature flag management system.

For example, when you use OpenFeature with ConfigCat:

OpenFeature does not replace ConfigCat. It standardizes how your application evaluates flags in code, while ConfigCat remains the place where you create, manage, target, and update those flags.

What OpenFeature Does and Does Not Do​

This distinction is important. OpenFeature is not a feature flag dashboard. It is not where product managers create flags, update targeting rules, or review audit logs. It is a standard API layer for evaluating feature flags inside your application.

In short: OpenFeature standardizes the code interface. ConfigCat manages the feature flags.

How Does OpenFeature Work with ConfigCat?​

OpenFeature adds a vendor abstraction layer on top of your existing feature flagging setup. This is done through SDKs for evaluating feature flags. Feature flag vendors (or open source contributors) are then encouraged to develop OpenFeature providers to connect their SDKs to OpenFeature SDKs. In short, an OpenFeature provider is like a bridge between an app and a feature flag vendor.

ConfigCat offers OpenFeature providers for multiple platforms, including Node.js, JavaScript, React, Angular, Go, Java, Python, PHP, Ruby, Swift, .NET, and others. These providers let applications evaluate feature flags through the OpenFeature API while keeping feature management in ConfigCat.

The flow looks like this:

1. You create and manage your feature flag in ConfigCat.
2. Your application uses the OpenFeature SDK.
3. The ConfigCat OpenFeature Provider connects OpenFeature to ConfigCat.
4. Your application evaluates the flag through the OpenFeature API.
5. ConfigCat returns the right value based on your targeting rules.

This gives you a standardized feature flag API in your code, while still using ConfigCat's dashboard, targeting rules, environments, permissions, and release controls.

Why Use OpenFeature?​

OpenFeature is useful when you want a more standardized approach to feature flag evaluation.

Here are the main benefits.

Less code-level vendor lock-in​

Different feature flag tools usually have different SDK methods, data structures, and implementation patterns. If you use those SDKs directly everywhere, switching providers later can require a lot of code changes.

OpenFeature reduces that coupling by giving your application a consistent feature flag API. This does not mean migrations become completely automatic. You may still need to recreate flags, targeting rules, environments, permissions, and workflows in the new platform. But at the code level, OpenFeature can make the transition easier.

A consistent API across teams and services​

If your organization has multiple services, languages, or teams, OpenFeature can help standardize how everyone evaluates feature flags.

Instead of each team learning a different SDK style, they can work with the same OpenFeature concepts:

• providers
• clients
• evaluation context
• flag evaluation methods
• hooks
• events

This is especially useful in larger engineering teams or companies with polyglot architectures.

Access to the OpenFeature ecosystem​

OpenFeature is part of the Cloud Native Computing Foundation (CNCF) ecosystem. The project was accepted into CNCF on June 17, 2022, and moved to the Incubating maturity level on November 21, 2023.

Because it is open and community-driven, teams can build shared tooling around feature flagging. For example, OpenFeature can work with observability-related concepts such as hooks, including OpenTelemetry-related use cases.

Easier experimentation with providers​

OpenFeature can also be useful when evaluating feature flag platforms. Since your application talks to the OpenFeature API, you can test different providers with fewer changes to your business logic.

This can be useful if you are comparing vendors, migrating away from an in-house solution, or moving from another feature flag platform to ConfigCat.

When Should You Use OpenFeature?​

OpenFeature is a good fit if:

• You want a vendor-agnostic feature flag API.
• You are migrating between feature flag providers.
• You want to standardize feature flag evaluation across multiple services.
• You work with several languages or frameworks.
• You want to reduce code-level coupling to one provider.
• You want to use tools from the OpenFeature ecosystem.
• You are building or replacing an in-house feature flag system.

It can also help if your team wants to keep the application code clean and consistent while still using a managed feature flag platform.

When Might You Not Need OpenFeature?​

OpenFeature is helpful, but it is not always necessary. You may prefer using the ConfigCat SDK directly if:

• You are happy with one feature flag provider.
• You want the simplest possible setup.
• You do not need a vendor abstraction layer.
• Your team wants direct access to ConfigCat-specific SDK features.
• You are building a small project where portability is not a concern.

OpenFeature is most useful when portability and standardization matter. If your team wants the simplest possible setup or needs direct access to vendor-specific SDK features, using the native feature flag platform SDK may be the better fit.

OpenFeature Provider vs. Native ConfigCat SDK: What Is the Difference?​

OpenFeature providers and native ConfigCat SDKs are not exactly the same, because they serve different purposes.

OpenFeature provides a standardized abstraction layer. It covers the common functionality shared across feature flag providers, which makes your application code more portable.

The native ConfigCat SDKs give you direct access to the full ConfigCat-specific feature set.

For basic use cases, such as evaluating on/off feature flags, OpenFeature works well. You can evaluate boolean flags, pass an evaluation context, and use ConfigCat targeting rules behind the scenes.

However, some advanced or ConfigCat-specific capabilities are not exposed directly through the OpenFeature API. Examples include:

• getAllKeys
• ConfigCat-specific hooks
• snapshots
• online/offline mode

The ConfigCat OpenFeature provider also exposes the underlying ConfigCat client through a configCatClient property. This means you can still access ConfigCat-specific functionality when needed.

The trade-off is portability. The more your application relies on ConfigCat-specific methods through the underlying client, the less vendor-agnostic your OpenFeature integration becomes.

A good rule of thumb: use OpenFeature when standardization and portability matter. Use the native ConfigCat SDK when you want the full ConfigCat SDK feature set with fewer abstraction limits.

Demo: Use OpenFeature with ConfigCat in Node.js​

Let's build a simple Node.js API using Express that returns a filtered list of AI models based on the user sent in the request.

cURL http://localhost:3000/models -H "x-user-email: tom@whisker.co" | jq

[
  {
    "name": "GPT 3.5 Turbo",
    "type": "standard"
  },
  {
    "name": "Claude Haiku",
    "type": "standard"
  },
  {
    "name": "Llama 2 7B",
    "type": "standard"
  },
  {
    "name": "GPT-4o",
    "type": "pro"
  },
  {
    "name": "Claude Sonnet 3.5",
    "type": "pro"
  },
  {
    "name": "Llama 3.1 405B",
    "type": "pro"
  }
]

I'll show you how to use OpenFeature's standardized evaluation context when evaluating a feature flag. This is useful for targeting users based on attributes such as name, email, and country. For example, showing users with an @whisker.co email address a list of pro-AI models, while others see standard AI models.

Step 1: Create a Feature Flag in ConfigCat​

1. Sign in to ConfigCat, or sign up if you don't have an account.

2. Create a feature flag with the following details.

   • Name: Enable Pro Models
   • Key: enableProModels
   • Hint: Enable pro AI models for users with an @whisker.co email address

3. Click + IF, then click Target users.

   You'll see two sections: an IF section for configuring the condition and a THEN section for setting the feature flag's value based on the condition.

4. In the IF section, select Email as the comparison attribute, then select ENDS WITH ANY OF (hashed) as the comparator.

5. Enter @whisker.co in the field next to the comparator, then turn on the feature flag in the THEN section below. Click SAVE & PUBLISH CHANGES.

Now that we've configured the feature flag, let's move on to the code.

Step 2: Install ConfigCat and OpenFeature​

Prerequisites​

• Node.js v18+
• Basic understanding of Node.js and Express

To use ConfigCat and OpenFeature together, we'll need to install ConfigCat's OpenFeature Provider for Node.js. ConfigCat's Node SDK and OpenFeature's Server SDK will be automatically downloaded alongside the provider.

1. Open your terminal, create a new directory, and install the provider.

mkdir configcat-openfeature-nodejs
npm init -y
npm install express
touch index.js
npm i @openfeature/config-cat-provider

2. Import the provider and OpenFeature server SDK in index.js.

import { ConfigCatProvider } from '@openfeature/config-cat-provider';
import { OpenFeature } from '@openfeature/server-sdk';

3. Create the ConfigCat provider with your ConfigCat SDK key. Then, set the provider and create an OpenFeature client.

// Create a provider with your SDK key
const provider = ConfigCatProvider.create('YOUR-CONFIGCAT-SDK-KEY');

// Initialize the provider
OpenFeature.setProviderAndWait(provider);

// Create a client.
const client = OpenFeature.getClient();

Step 3: Create the API Endpoint​

I'll create a /models endpoint that returns a list of AI models. Depending on the email address supplied in the request header, we'll return a list of pro-AI models if the flag evaluates to true and the standard list otherwise.

app.get('/models', async (req, res) => {
 const email = req.headers['x-user-email'];

 if (!email) {
  return res.status(400).json({ message: 'Email required' });
 }

 const context = {
  targetingKey: 1, // required
  email: email,
 };
 let modelsListEnabled = await client.getBooleanValue(
  'enableProModels',
  false,
  context,
 );

 if (modelsListEnabled) {
  const proModels = db.getModels('pro');
  console.log('Returning pro models...');
  res.json(proModels);
 } else {
  const standardModels = db.getModels('standard');
  console.log('Returning standard models...');
  res.json(standardModels);
 }
});

Finally, I added a condition to return the appropriate list of models based on the feature flag's value. Let's see if it works.

When a user is supplied with an email address like: tom@whisker.co the response would be:

cURL http://localhost:3000/models -H "x-user-email: tom@whisker.co" | jq

[
  {
    "name": "GPT-4o",
    "type": "pro"
  },
  {
    "name": "Claude Sonnet 3.5",
    "type": "pro"
  },
  {
    "name": "Llama 3.1 405B",
    "type": "pro"
  }
]

Why Use ConfigCat with OpenFeature?​

OpenFeature gives you a standardized evaluation API. ConfigCat gives you the feature flag management layer behind it.

Together, they give you vendor-agnostic feature flag evaluation in code without giving up a managed dashboard, targeting rules, environments, permissions, and release controls.

Recap​

OpenFeature is useful when you want a standardized, vendor-agnostic way to evaluate feature flags in your application code. ConfigCat provides the feature flag management layer behind it, including targeting rules, environments, values, and release controls.

In this guide, we covered:

• what OpenFeature is
• what OpenFeature does and does not do
• how OpenFeature works with ConfigCat
• when OpenFeature is useful
• how OpenFeature providers differ from native ConfigCat SDKs
• how to use the ConfigCat OpenFeature Provider for Node.js

OpenFeature is a good fit when portability and standardization matter. If you want the simplest direct integration or need ConfigCat-specific SDK features, the native ConfigCat SDK may be the better choice.

Next Steps​

To explore the broader OpenFeature ecosystem, visit OpenFeature.dev or join the OpenFeature Slack channel to get the latest updates.

If you want to try feature flags with ConfigCat, you can start with the Forever Free plan and connect your first flag through OpenFeature or a native ConfigCat SDK.

For more on feature flags, check out ConfigCat on Facebook, X, GitHub, and LinkedIn.

This guide explains what feature flags actually are, how they work under the hood, when to use them, when not to use them, how to test them properly, how to manage them across teams, and how to avoid the organizational problems that turn a helpful tool into a maintenance burden.

What Are Feature Flags?​

Feature flags (also called feature toggles) are a way to control application behavior without changing code.

A feature flag is simply a conditional in your code whose value is controlled externally (usually from a dashboard or configuration service) and can be changed at runtime.

Here’s the simplest possible version in Python:

import configcatclient

client = configcatclient.get("#YOUR-SDK-KEY#")

if client.get_value("new_checkout_flow", False):
    render_new_checkout()
else:
    render_legacy_checkout()

The important part isn't the if statement. It's where the value comes from. The "new_checkout_flow" flag isn't hardcoded. It's controlled externally, often from a dashboard. That means someone can change it instantly, without touching the code or triggering a deployment.

That separation is what makes feature flags so powerful. The code is deployed, but the behavior is still flexible.

See Feature Flags in Action​

Sometimes it's easier to understand feature flags by seeing them work. In this example, the code reads multiple feature flags (like dark mode or sales banner). Toggling them instantly changes the UI without any redeployment.

Try toggling the flags to see how the application updates in real time.

All Feature Flags

Dark mode

Sales mode

Holiday mode

ConfigCat.js

  const client = configcat.getClient("#SDK-KEY#");
  const darkMode = await client.getValueAsync("darkMode", false);
  const salesMode = await client.getValueAsync("salesMode", false);
  const snowEnabled = await client.getValueAsync("snowEnabled", false);

  if (darkMode) {
      enableDarkTheme();
  }
  if (salesMode) {
      showSalesBanner();
  }
  if (snowEnabled) {
      startSnowAnimation();
  }

This is the core idea of feature flags: the code stays the same, but behavior changes instantly.

Why Feature Flags Matter: Deployment vs. Release​

Before feature flags, deploying code and releasing a feature were the same event. You merge, you deploy, the feature is live. If something breaks, you roll back the entire deployment, not just the broken feature but everything that shipped with it.

Feature flags change that. Deployment is the act of getting code into production. Release is the act of making a feature visible to users. With feature flags, these happen independently:

• You deploy on Tuesday with the flag OFF, the code is live but nothing has changed for users.
• You release on Friday by flipping the flag. No deployment, no risk window.
• If something breaks, you flip the flag back. Users return to the previous behavior in seconds, no rollback required, even on a Saturday, without needing to call in a developer or DevOps.

This is called separating deployment from release and it's a core principle of continuous delivery. Research from the DORA State of DevOps report consistently shows that high-performing engineering teams deploy more frequently and have lower change failure rates. Feature flags are one of the key practices that make this possible.

How Feature Flag Evaluation Works Under the Hood​

Understanding how feature flags are evaluated isn't just an implementation detail, it directly affects performance, consistency, and how you design your system.

From the outside, a flag check looks simple. Under the hood, a few important things happen to make it fast and reliable.

1. The SDK fetches and caches configuration​

When your app starts, the SDK downloads the current configuration from the flag management service and stores it locally.

// Go example — SDK initialization

client := configcat.NewCustomClient(configcat.Config{
    SDKKey: "#YOUR-SDK-KEY#",
    PollingMode: configcat.AutoPoll,
    PollInterval: time.Second * 60,
})
defer client.Close()

The important thing: flag evaluation does not make a network call on every check. The SDK reads from a local in-memory cache. Flag evaluation typically takes microseconds and adds no noticeable latency to your application.

2. The cache is updated in the background​

The SDK periodically polls the configuration service for updates. The interval is configurable, commonly 30 to 60 seconds. Some SDKs also support webhook-based invalidation for near-instant propagation. In serverless environments like AWS Lambda, where in-memory state doesn’t persist between invocations, a shared external cache (such as Redis) is the better pattern.

3. Targeting rules are evaluated locally​

When your code checks a flag, the SDK evaluates it against the user context you provide.

// Java example — passing user context for targeting

User user = User.newBuilder()
    .email("alice@company.com")
    .custom(Map.of(
        "country", "US",
        "subscriptionPlan", "pro"
    ))
    .build("user_123");

boolean isEnabled = client.getValue(Boolean.class, "new_dashboard_layout", user, false);

The SDK evaluates the flag against the targeting rules you've defined, such as:

• user-specific targeting
• segment rules based on attributes like plan or region
• percentage rollout rules

If none of those rules match, it falls back to the default value you provide.

The percentage rollout is worth understanding specifically, The SDK doesn’t use random chance. Instead, it uses a deterministic hashing algorithm based on the user's identifier and the flag key to assign each user to a stable bucket.

This means the result is always the same for the same user, no matter when or where the evaluation happens.

• hash(userId + flagKey) % 100 → consistent bucket between 0–99
• if bucket < rolloutPercentage → flag is ON for this user

Because of this, feature flag evaluation is both stateless and predictable:

• no user data needs to be stored server-side
• no session tracking is required
• and no user will randomly switch between experiences

A user who is part of the 20% rollout today will still be part of that same 20% tomorrow, across sessions, devices, and even platforms.

This is what makes canary releases reliable. When you gradually roll out a feature, you're not exposing it to a different group of users each time. You're expanding a stable group which makes it much easier to monitor behavior, detect issues, and build confidence before going to 100%

4. Your code executes the correct path​

The SDK returns the value, your code branches, done. The entire process from calling getValue to executing the right code path takes under a millisecond in any long-running application.

The Four Types of Feature Flags​

Not all flags serve the same purpose. Understanding the types helps you manage their lifecycle correctly because each type has a different expected lifespan and a different risk profile. The four main types of feature flags you'll encounter in production are release flags, experiment flags, operational flags (kill switches), and permission flags.

1. Release flags​

Purpose: Gradual rollout of a new feature
Lifespan: Short (days or weeks)

Release flags are the most common type. They exist to separate deployment from release and enable gradual rollouts. Once a feature is at 100% and stable, the flag should be removed, leaving it in the codebase creates flag debt.

2. Experiment flags​

Purpose: A/B testing and production experimentation
Lifespan: Duration of the experiment

Experiment flags return multiple variants rather than a simple boolean. Each variant maps to a different experience, and the distribution across your user base lets you measure which performs better.

// JavaScript — experiment flag with multiple variants

async function renderCheckout(user) {
  const checkoutVariant = await client.getValueAsync(
    "checkout_redesign_experiment",
    "control",
    user
  );

  // Returns: "control" | "single_page" | "progressive"

  switch (checkoutVariant) {
    case "single_page":
      renderSinglePageCheckout();
      break;
    case "progressive":
      renderProgressiveCheckout();
      break;
    default:
      renderLegacyCheckout();
  }
}

In practice, this means you can test completely different user experiences without separate deployments or feature branches.

This is also the mechanism behind fake door testing, where you expose a feature concept to users before building it and measure real demand.

3. Operational flags (Kill switches)​

Purpose: Disable unstable or expensive functionality instantly during incidents
Lifespan: Permanent or long-term

Operational flags, often called kill switches, are designed to be flipped under pressure. When something goes wrong in production, you don't want to deploy a fix, you want to turn the problem off.

The default value is critical here. If the flag service is unreachable, the system should fail safe by disabling the risky functionality.

// Go — kill switch for an external recommendation service

useRecommendations := client.GetBoolValue(
    "recommendations_engine_enabled",
    false, // safe default: disable if flag service is unreachable
    user,
)

if useRecommendations {
    products, err = getPersonalizedRecommendations(userID) // External API call
    if err != nil {
        products = getDefaultProductList() // fallback on error
    }
} else {
    products = getDefaultProductList() // fast, local path
}

This pattern is particularly valuable for site reliability engineers. A well-placed kill switch means the response to a production incident is a dashboard toggle, not an emergency deployment at 2 am.

4. Permission flags​

Purpose: Control access to features based on user plan, role, or group
Lifespan: Long-term or permanent

Unlike release flags, permission flags aren’t removed after a rollout. They become part of how your product works, controlling who gets access to what.

This is where feature flags start to overlap with product logic, not just release strategy. They're often used for things like premium features, roll-based access, or region-specific functionality.

// Java — permission flag gating a premium feature

User user = User.newBuilder()
    .custom(Map.of("plan", currentUser.getSubscriptionPlan()))
    .build(currentUser.getId());

boolean canExportData = client.getValue(Boolean.class, "csv_export_enabled", user, false);

if (!canExportData) {
    return ResponseEntity.status(403).body("Upgrade to Pro to export data");
}

// proceed with export

Because these flags tend to live longer, they require clear ownership, proper documentation, and regular review.

The Feature Flag Lifecycle​

Every flag passes through stages. Understanding the lifecycle helps you avoid the two most common failure modes: flags that never get removed, and flags removed before it’s safe to do so.

Done right, feature flags don't just help you release safely. They help you operate cleanly over time.

1. Create​

Before writing a line of code, define the flag in your management tool and document:

• What does this flag control?
• Who owns it?
• What is the safe default if evaluation fails?
• When should it be deleted?

That last question is the one most teams skip. Answering it at creation time makes cleanup decisions obvious later instead of ambiguous forever.

2. Deploy​

The feature ships to production with the flag set to False. From the user’s perspective, nothing has changed. From an engineering perspective, the code is already live and running in your production environment.

This is a meaningful safety step that’s easy to undervalue. Bugs that only appear under real production conditions (memory leaks, race conditions, performance issues under real load) can surface before any user is affected.

3. Roll out​

Once you're confident the system is stable, you start exposing the feature to real users gradually.

A typical rollout might look like this:

Define what “healthy” looks like before you start. Rollback decisions made against pre-defined criteria are fast and confident. Rollback decisions made by gut feel in the middle of an incident are slow and stressful.

You can also combine rollout with soak testing, letting the feature run at a fixed percentage for an extended period to catch issues that only emerge over time.

4. Monitor​

A flag change you can’t measure is a flag change you can’t safely make. Before enabling a flag for real users, make sure you can answer:

• Which users are receiving which variant?
• How do error rates differ between flag states?
• What's happening to key business metrics?

Feature flags don't replace observability, they depend on it. Without monitoring, feature flags increase risk instead of reducing it. Most teams integrate with tools like Datadog, New Relic, or Sentry to track the impact of each rollout step in real time.

5. Clean up​

Once a feature is at 100% and stable, the flag has served its purpose. Remove it from the flag management tool and from the codebase. Leaving old flags behind increases complexity, makes code harder to read, and creates long-term maintenance risk.

Feature Flag Use Cases​

Feature flags are one of those tools that seem simple at first, but once you start using them, they quietly spread across everything. What begins as a safe rollout mechanism turns into a way to experiment, control risk, and even reshape how teams collaborate.

Here are the most common (and most valuable) ways teams actually use them in practice.

Gradual rollouts​

Instead of releasing a feature to everyone at once, you start small.

Release to 1% of users, watch your error dashboards, then expand to 10%, 50%, 100%. A bug that would have hit your entire user base now affects a fraction of them, and you catch it while you can still react calmly.

This is closely related to ring deployment, a pattern where you define explicit rings of users and move through them with explicit validation gates.

Canary release​

A canary release is a gradual rollout specifically designed to catch regressions before they affect your full user base. You deploy to a “canary” cohort (typically 1-5% of users), monitor key metrics and only proceed if the canary is healthy.

The important part isn't the percentage. It's the discipline of validating before expanding.

A/B testing and experimentation​

Feature flags don't just control exposure, they also enable learning. Different users can see different versions of a feature, and you can measure which one performs better. That could be a checkout flow, a pricing page, or even a button label.

The key advantage of server-side experimentation is that it happens before the response reaches the user:

• No flicker
• No layout shifts
• No dependency on JavaScript loading

You're measuring real behavior from the moment the request hits your system.

Kill switches for production incidents​

When something breaks in production, the fastest resolution is disabling the feature, not redeploying, not rolling back, not waiting for a hotfix to pass CI. A kill switch turns a potential 30-minute incident into a 30-second one. This is testing in production with a safety net.

Infrastructure migrations​

This is one of the most underused applications of feature flags, and one of the highest-value. When migrating from one database, API, or third-party service to another, you can use a flag to route traffic gradually from the old system to the new one:

# Python — infrastructure migration flag

use_new_payments_api = client.get_value("payments_stripe_v2", False, user_object)

if use_new_payments_api:
    result = stripe_v2_client.charge(amount, currency, token)
else:
    result = stripe_v1_client.charge(amount, currency, token)

Environment-based releases​

Different behavior across environments without code changes:

This means the same codebase runs everywhere, with environment-specific behavior controlled externally.

User targeting and dogfooding​

Enable a feature for internal employees before any external users. Let them find the bugs, give feedback, and validate workflows before customers see anything. This dogfooding or champagne brunch approach is one of the highest-quality pre-release testing methods available because it runs in your actual production environment with real data.

Feature Flags vs. Configuration Files​

At first glance, feature flags can look like just another form of configuration. After all, both control how your application behaves without changing the core logic. But the difference shows up the moment you need to move fast.

Traditional configuration files require modifying a file, often redeploying or restarting the service, and they apply the same value to every user. They weren't designed for frequent change, and they weren't designed for experimentation.

Feature flags were. They let you change behavior at runtime, target specific users, and roll things out gradually, all without touching your codebase or triggering a deployment.

Here's how they compare in practice:

The key distinction isn’t just runtime vs. deployment-time. It’s that feature flags are designed to be changed frequently, often by non-engineers, with built-in targeting logic and a full history of who changed what and when.

Configuration files are static by nature. Feature flags are dynamic by design.

If you're just setting a value once and rarely touching it again, a config file is perfectly fine. But the moment you need control, experimentation, or safe releases, you're no longer dealing with configuration. You're dealing with progressive delivery.

When NOT to Use Feature Flags​

Feature flags are powerful, but they're not a universal solution. Used in the wrong places, they add complexity without adding value.

Knowing when not to use them is just as important as knowing when to reach for them.

Long-term configuration management​

If a value changes rarely, doesn’t need user targeting, and doesn’t need an audit trail, an environment variable or config file is simpler and more appropriate.

Not everything needs to be dynamic. In fact, forcing rarely changing values into feature flags often makes things harder to reason about, not easier. Feature flags are designed for change. If there's no change, there's no benefit.

Secrets and credentials​

API keys, database password, OAuth secrets - these belong in dedicated secrets managers, not feature flags.

Feature flags are evaluated in ways that may expose their values to clients (especially in frontend or mobile environments). That makes them the wrong place for anything sensitive. If leaking it would be a security incident, it shouldn't be a flag.

Core business logic that should never be disabled​

A feature flag implies optionality. If turning something off would fundamentally break your application, it shouldn't be behind a flag in the first place.

Authentication, core data persistence and payment processing are foundational parts of your system. Treating them as optional introduces risk, not flexibility.

Replacing proper access control​

Feature flags are often used to gate features, but they are not a replacement for authorization.

A flag can decide who sees a feature. It should not decide who is allowed to perform an action. If you rely solely on flags to enforce security boundaries without proper server-side checks, you don't have feature control. You have a security gap.

Hiding permanently broken features​

This one happens more often than teams admit. A feature is buggy, so it gets turned off. Weeks pass. Then months. The flag stays false and the code stays in the system.

At that point, the flag isn't helping anymore. It's hiding unfinished work and adding noise to your codebase.

Feature flags are meant for controlled release, not permanent deferral. If a feature isn't coming back, remove it.

Who Uses Feature Flags Across the Organization​

Feature flags often start with developers and expand from there. Once the infrastructure is in place, the control over releases starts to move beyond engineering. What used to require a deployment becomes a decision. And decisions don't always belong to developers.

Product managers​

For product managers, feature flags turn release timing into a controllable variable. They can decide who sees a feature, when it goes live, and how it's introduced. That means launches can align with campaigns, experiments can run without engineering bottlenecks, and features can be enabled exactly when they create the most impact.

A product manager flipping a flag during a live demo isn't a workaround. It's the system doing what it was designed to do.

QA engineers​

For QA, feature flags remove one of the biggest constraints in testing: environment limitations.

Features can be enabled in staging or even production for internal users, without affecting real customers. Specific scenarios, edge cases, or user segments can be tested on demand, without waiting for a new deployment.

Testing becomes more flexible, and closer to real-world conditions.

Marketing and growth teams​

For marketing and growth teams, feature flags unlock experimentation without dependency. Campaigns don't have to wait for releases. Landing page variations can be tested in real time. Features can be enabled for specific regions, audiences, or cohorts as part of a broader strategy.

This is where feature flags start to overlap with growth tooling, not replacing it, but enabling faster iteration.

Site reliability engineers​

For SREs, feature flags are a control mechanism under pressure. Operational flags, often called kill switches, allow teams to degrade non-critical functionality gracefully when systems are under stress. Instead of firefighting with emergency deployments, they can stabilize the system with a single toggle.

Disabling a recommendation engine or a heavy background process during peak load isn't just a technical decision. It's a reliability strategy.

What ties all of this together is not just the technology, but the shift in ownership.

Feature flags allow engineering to build the system, while giving other teams controlled ways to operate within it. That's what a feature flagging tool makes possible: centralized control with distributed decision-making.

When to Bring in a Feature Flag Management Tool​

You can implement basic feature flags yourself, a value in a database, a simple API, a cache layer. This works until it doesn’t.

The challenges that appear at scale are organizational, not technical. A homegrown system gives you toggles. A management platform gives you control.

The right time to bring in a tool is before the organizational problems appear. If more than one team is creating flags, or you have more than 20-30 active flags, manual management is already a liability.

Final Thoughts​

Feature flags might start as a small technical decision, but they quickly become part of how you build, release, and operate software.

They give you control over what users see and when they see it. They let you test ideas safely, roll things out gradually, and react quickly when something doesn't go as planned. Over time, they shift releases from risky events to controlled decisions.

Of course, like any powerful tool, they come with responsibility. Used well, they make your system more flexible and your team more confident. Used poorly, they create noise and complexity. The goal isn't to flag everything, it's to use flags where they actually give you an advantage.

If you're ready to see how feature flags work in practice, you can get started with ConfigCat's Forever Free plan in minutes and make your next release a little less stressful.

For more information, check out ConfigCat's website. You can also stay up to date with the newest developments by following ConfigCat on GitHub, LinkedIn, X, or Facebook.

Microservices reduce that blast radius by breaking systems into smaller, independently deployable services. When you combine microservices with feature flags, you gain something even more powerful: the ability to change production behavior without redeploying code. If one service misbehaves, you don't redeploy. You disable the feature. You stabilize and fix forward. That level of runtime control is what makes feature flags essential in distributed systems.

In this guide, we'll explore how feature flags work in microservices and serverless architectures, and walk through a practical example using AWS Lambda, .NET, Redis, and ConfigCat.

What Are Feature Flags in Microservices?​

Feature flags (also called feature toggles) are configuration switches that allow developers to turn application features on or off without redeploying code. In a microservices architecture, this becomes extremely powerful.

Instead of coordinating releases across multiple services, teams can:

• Deploy code with features disabled
• Gradually enable functionality when ready
• Disable problematic features instantly

Feature flags are commonly used for:

• Progressive rollouts
• Canary releases
• A/B testing
• Kill switches for production incidents
• User segmentation

This decouples deployment from release, which is one of the key principles of modern DevOps practices.

How Feature Flags Work in Microservices Architecture​

A microservices architecture is a design approach in which a single application is composed of many loosely coupled, independently deployable services. Each service typically focuses on a single business capability, such as:

• Product catalog
• Authentication
• Payments
• Checkout
• Order processing

These services communicate through APIs.

While this architecture improves scalability and team autonomy, it also introduces release coordination challenges.

For example:

• Team A (Payments) is ready to release a new feature.
• Team B (Invoicing) isn't ready yet.

Without feature flags, Team A waits. Deployment timing becomes coupled across teams.

With feature flags, Team A can deploy the new code with the feature disabled. When the dependency is ready, the flag is enabled remotely. No coordinated deployment window, no cross-team blocking

Example: Safe Feature Rollout​

Imagine you introduce a "Buy Now with One Click" button to your Checkout Service, but this feature depends on data from another microservice, the Shipping Service. If the Shipping Service starts lagging or crashes, you can quickly revert to the standard multi-step checkout without rolling back any code—simply by toggling the flag OFF.

Beyond simple ON/OFF control, they enable:

• Targeting specific users, regions, or environments.
• A/B testing new behavior.
• Progressive Rollouts (canary releases).

In a microservices architecture, this provides a safety net for features that depend on each other. You can release incrementally, validate safely, and limit exposure when things go wrong.

Microservices vs Serverless Architecture​

Although the terms are sometimes used together, microservices and serverless refer to different things.

Serverless platforms like AWS Lambda are often used to run microservices because they provide:

• Automatic scaling
• No server management
• Pay-per-execution pricing
• Fast deployment cycles

Each microservice can run as its own set of Lambda functions.

When combined with feature flags, this architecture allows teams to control behavior remotely across distributed services without redeploying functions.

Challenges of Using Feature Flags in Serverless (AWS Lambda)​

Lambda functions are short-lived by design. They boot up, handle a request, and return.

AWS may reuse execution environments between invocations (warm starts), but you cannot rely on in-memory state being preserved. Cold starts create a fresh execution environment with no cached data. This matters for feature flag evaluation.

If your Lambda function fetches feature flag configuration from an external API on every invocation:

1. Latency: Network calls before each execution slow everything down.
2. Cost & Limits: You'll burn through API quotas and rack up data transfer fees.

With feature flags in serverless architectures, you need to play by different rules. Depending on how quickly your Lambdas need to react to feature flag changes, you can cache your feature flag data and refresh it periodically to avoid serving stale flags.

How to Implement Feature Flags in AWS Lambda with .NET​

Let's walk through a practical example of integrating feature flags in a .NET AWS Lambda function using ConfigCat.

Here's how to set it up.

Prerequisites​

To follow this tutorial, you will need a few tools installed and accounts set up. Don't worry, free tiers work perfectly for everything here.

• A ConfigCat Account: You can sign up for a forever free account here.
• An AWS Account: You will need access to the AWS Console and a user with permissions to create Lambda functions.
• A Redis Instance: For this tutorial, you can use a free Redis Cloud database to quickly obtain a connection string. Amazon ElastiCache is typically used in production AWS environments.
• The .NET SDK: We are using .NET 10.0, which you can download here.
• Command Line Tools:
  • AWS CLI: configured with your credentials (aws configure).
  • AWS Lambda Tools for .NET:.

Step 1: Create a Feature Flag in ConfigCat​

Before writing code, we need a flag to control.

1. Log in to the ConfigCat Dashboard.
2. Create a new Feature Flag with the name My Feature Flag and key name isMyFeatureEnabled.
3. Turn the feature ON (so we can verify it works later).

Step 2: Setting Up the .NET Project​

We will use the .NET CLI to create a lightweight Lambda function. Open your terminal or PowerShell and run the following commands:

# Create a new empty Lambda function
dotnet new lambda.EmptyFunction -n ConfigCatLambdaDemo

# Navigate into the project directory
cd ConfigCatLambdaDemo

# Install the ConfigCat Client SDK and Redis Client
dotnet add package ConfigCat.Client
dotnet add package StackExchange.Redis

This installs the necessary NuGet packages to handle .NET feature flags and the Redis cache integration.

Step 3: Implementing the Shared Cache (Redis)​

This is the most critical part of this tutorial. In standard apps, internal caching works fine. But in AWS Lambda, in-memory state is not guaranteed to persist between invocations. To prevent your Lambdas from spamming the ConfigCat API on every "Cold Start," we will use Redis as a persistent, shared cache.

Open your Function.cs file and replace the content with the following code. This includes a custom RedisCache class that implements ConfigCat's caching interface:

using Amazon.Lambda.Core;
using ConfigCat.Client;
using ConfigCat.Client.Configuration;
using ConfigCat.Client.Cache;
using StackExchange.Redis;

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace ConfigCatLambdaDemo;

public class Function
{
    private static IConfigCatClient _configCatClient;

    static Function()
    {
        // Add your real ConfigCat SDK key here or add it as an Environment Variable
        var sdkKey = "your-configcat-sdk-key";

        // Add your real Redis Connection String here or add it as an Environment Variable
        var redisConnectionString = "your-redis-connection-string";

        _configCatClient = ConfigCatClient.Get(sdkKey, options =>
        {
            options.ConfigCache = new RedisCache(redisConnectionString);

            options.PollingMode = PollingModes.AutoPoll(pollInterval: TimeSpan.FromSeconds(60));
        });
    }

    public async Task<string> FunctionHandler(string input, ILambdaContext context)
    {
        // Ensure the flag name here matches your Dashboard exactly
        var isFeatureEnabled = await _configCatClient.GetValueAsync("isMyFeatureEnabled", false);

        context.Logger.LogInformation($"ConfigCat Flag value: {isFeatureEnabled}");

        if (isFeatureEnabled)
        {
            return "New Feature Logic Enabled";
        }

        return "Old Feature Active";
    }
}
public class RedisCache : IConfigCatCache
{
    private readonly IDatabase _database;

    public RedisCache(string connectionString)
    {
        var connection = ConnectionMultiplexer.Connect(connectionString);
        _database = connection.GetDatabase();
    }

    public string? Get(string key)
    {
        return _database.StringGet(key);
    }

    public void Set(string key, string value)
    {
        _database.StringSet(key, value);
    }

    public async Task<string?> GetAsync(string key, CancellationToken cancellationToken = default)
    {
        return await _database.StringGetAsync(key);
    }

    public async Task SetAsync(string key, string value, CancellationToken cancellationToken = default)
    {
        await _database.StringSetAsync(key, value);
    }
}

Step 4: Deploying to AWS​

Now that our code is ready, we need to push it to our AWS cloud. The .NET CLI makes this straightforward with the Amazon Lambda Tools.

1. Install the Lambda Tools (if you haven't installed it):

   dotnet tool install -g Amazon.Lambda.Tools
   

2. Deploy the Function: Run the following command in your project folder. It will compile your code and upload it to AWS.

   dotnet lambda deploy-function ConfigCatDemo
   

3. Test the Function: Once deployed, you can invoke the function directly from the CLI to see the result immediately:

   dotnet lambda invoke-function ConfigCatDemo --payload "test"
   

   If your feature flag is turned ON in ConfigCat, you will see the payload response: New Feature Logic Enabled

Step 5: Verifying Runtime Control​

To see the "under the hood" details and confirm the Singleton pattern is working:

1. Log in to your AWS Console.
2. Navigate to CloudWatch > Logs > Log management.
3. Click on /aws/lambda/ConfigCatDemo.
4. You will see the logs generated by our code confirming the flag value was retrieved successfully.

Once deployed, you can verify that the feature flag works by toggling it in the ConfigCat Dashboard.

To do this, you go to ConfigCat and toggle the flag OFF.

AWS Lambda doesn't listen for ConfigCat updates; it only checks when the function runs. So toggling the flag doesn't instantly change behavior. You need to wait for the cache to expire, then trigger a new execution.

After waiting 60+ seconds, invoke the function again:

dotnet lambda invoke-function ConfigCatDemo --payload "test"

Then, you will see the payload response: "Old Feature Active"

And the CloudWatch logs show the flag evaluated as false:

That's runtime control in action; production behavior changed with zero deployments.

Step 6: Implementing Progressive Delivery​

Say you're launching a redesigned checkout experience for your e-commerce site. Pushing it to 100% of customers immediately is a gamble; a bug could tank your conversion rate.

This is where Progressive Delivery shines. Start by serving the new flow to 10% of users. If checkout completion rates stay stable and error logs look clean, bump it to 30%, then 70%, then everyone. It's a controlled rollout, sometimes called a Canary Release.

Traditional setups require custom load balancer logic or proxy configurations to perform canary releases. But, ConfigCat handles it with percentage-based targeting rules without code or infrastructure changes.

To do this:

1. Go back to your ConfigCat Dashboard.
2. Find your isMyFeatureEnabled flag.
3. Instead of changing the main toggle, click on the +% button.
4. Set the rule to serve ON to 10% of traffic and OFF to 90%.

Why Progressive Delivery Works Well with Serverless​

Since Lambda functions are stateless, each invocation independently evaluates the 10% targeting rule through ConfigCat's SDK.

Here's what that looks like in practice:

• Watch CloudWatch logs as the feature rolls out
• Errors show up? Only 10% of users are impacted
• Everything stable? Bump the percentage (30% → 50% → 100%) from the dashboard

The microservices advantage:

This decouples deployment timing across teams. If your checkout flow needs the new payment processing API, but that API isn't deployed yet. Ship your code with the flag off. When the payments team eventually deploys, you enable the flag remotely. No waiting, no coordinated release windows, no "we can't ship until Team B is ready" conversations.

Feature Flag Best Practices for Microservices and Serverless​

When using feature flags in distributed systems, keep the following practices in mind.

1. Always define fallback values: That fallback value in GetValueAsync determines what happens during ConfigCat outages. Pick the safest option by disabling the new feature. I've seen production incidents from missing defaults.

2. Clean up old flags: Most teams use feature flags to manage and release a new feature. Once you've hit 100% rollout and the feature is stable, remove the flag from your code. The Zombie Flag Report and the Code References tool do a good job of helping you identify stale flags in your code before they become technical debt.

3. Balance cache duration 60 seconds hits a good balance: flag changes propagate reasonably fast without excessive API calls inflating your Lambda execution costs. You can adjust this interval based on how quickly you need updates vs. what you're willing to pay.

Conclusion​

Feature flags are a powerful tool for managing releases in microservices and serverless architectures.

By combining AWS Lambda, Redis caching, and ConfigCat, teams can safely control application behavior without redeploying code.

This approach enables:

• safer deployments
• progressive rollouts
• instant rollback capabilities
• better collaboration across teams

Whether you're running microservices on Kubernetes or serverless workloads on AWS Lambda, feature flags provide a flexible way to release software with confidence.

Beyond .NET, ConfigCat provides a wide range of SDKs that work seamlessly with other AWS Lambda runtimes, including Node.js, Python, Go, and Java. To learn more, check out ConfigCat's official documentation.

To get more posts like this and the latest updates, follow ConfigCat on X, Facebook, LinkedIn, and GitHub.

But as systems grow, feature flags often become a source of hidden complexity. Flags pile up, naming breaks down, and unclear ownership leads to risky changes in production. What starts as a simple toggle system can quickly turn into long-term technical debt.

This guide walks through seven common feature flag mistakes and the best practices to avoid them, so your system stays clean, predictable, and safe to work with.

Why Feature Flag Best Practices Matter​

Feature flags separate deployment from release. This means teams can ship code to production while keeping new functionality hidden until the right moment. Product managers, developers, and operations teams can decide when a feature becomes visible to users.

This approach supports several modern development practices:

• Gradual rollouts: expose a feature to 5% of users, then 25%, then 100%
• Canary releases: test changes on a small cohort before full release
• Kill switches: instantly disable a broken feature without a hotfix
• A/B testing: compare feature variants across user segments
• Trunk-based development: ship incomplete features safely behind a flag

But when feature flags are used without clear rules, problems start to appear:

• unused flags clutter the codebase
• unclear ownership of flags
• confusing naming conventions
• security risks in frontend implementations

A few consistent practices keep feature flag systems clean, predictable, and easy to maintain.

1. Leaving Old or Stale Feature Flags in the Codebase​

A feature is released. Everything works. The flag stays. This is one of the most common patterns teams run into.

Over time, these unused flags pile up and create what many engineers refer to as flag debt or zombie flags. A developer reading the code cannot easily tell whether a flag still has a purpose.

Stale flags cause real problems:

• Code becomes harder to read and reason about
• Conditional branches remain in production for features that are 100% rolled out
• Accidental changes to an old flag value can affect live behavior in unexpected ways
• In mobile apps, a flag may still be evaluated by users on older versions who haven't updated

What works in practice​

Teams that keep feature flags under control usually treat cleanup as a recurring task, not a one-time effort.

One approach that works well is scheduling regular cleanup sessions. For example, some teams run a quarterly "cleanup day", where removing unused flags is a standing agenda item. This aligns well with release cycles, especially in environments where updates take time to reach all users.

Another pattern is to introduce limits. Some teams define a feature flag budget per team. If the number of active flags exceeds that limit, the build or deployment pipeline fails. This forces teams to review and remove unused flags before adding new ones.

There are also teams that categorize flags from the start:

• short-term flags used during rollout
• medium or long-term flags used for gradual control
• permanent flags used as kill switches

In this model, removing short-term flags becomes part of the release process. When a feature is fully rolled out, a cleanup task is created alongside the original implementation work.

A common challenge​

One difficulty that often comes up is knowing when it is safe to remove a flag. Even if a feature has been released, older versions of an application may still be in use. This is especially common in mobile apps, where users do not always update immediately.

In these cases, a flag may still be evaluated by older versions in the wild, even if it appears unused in the current codebase.

Tools like ConfigCat's Zombie Feature Flags Report can highlight flags that haven't changed recently, but teams often need additional signals (such as whether a flag is still being evaluated) before removing with confidence.

2. Reusing Feature Flags Instead of Creating New Ones​

Reusing a feature flag may feel efficient. In reality, it creates hidden complexity. A flag designed for one feature gets repurposed for another. Its name no longer reflects its behavior, and debugging becomes harder.

In extreme cases, this can lead to serious issues. There are well-known incidents where old flag logic was unintentionally reused, causing unexpected system behavior.

What works in practice​

Teams that avoid this follow a strict rule: a flag is tied to one purpose only. If the purpose changes, a new flag is created.

Naming conventions play an important role here. A clear, descriptive name makes it easier to understand what a flag does without digging into the code.

A good feature flag name should reflect:

• a feature area
• the functionality being controlled
• optionally, the team responsible

Pattern: {team}_{area}_{behavior}:

• payments_checkout_newPaymentFlow
• search_results_rankingAlgorithmV2
• onboarding_signup_emailVerificationRequired

Avoid vague names:

• newFeature // What feature?
• betaEnabled // Beta of what?
• enableV2 // V2 of which thing?

Note: Avoid prefixing flags with enable or disable; it's redundant since all flags enable or disable something, and it adds noise without meaning.

Common naming styles include camelCase, PascalCase, lower_case, UPPER_CASE, and kebab-case. The specific format matters less than consistency. A predictable structure makes flags understandable across the entire team.

3. Using Feature Flags Without Backend Protection​

Feature flags are often used to control interface elements such as buttons, menu items, or entire pages. However, relying solely on frontend feature flags can introduce security and reliability risks. Because frontend flags are delivered to the browser when the application loads, their values can be inspected, modified, or bypassed entirely. A user does not need to see a button to call the API endpoint behind it.

Example Scenario​

A new Export Data button is hidden behind a feature flag. The button doesn't render, but the /api/data/export endpoint has no flag check on the server. Anyone who knows the endpoint exists (or who previously had access and bookmarked it) can call it directly.

Best Practice​

Use two layers of protection:

1. Frontend flag: controls whether the UI element appears
2. Backend flag: controls access to the underlying logic

With this approach, even if the interface becomes visible prematurely, the backend still prevents unintended access. Whenever possible, evaluating feature flags on the server side offers stronger protection.

4. Not Planning Feature Rollouts Properly​

Feature flags make gradual rollouts possible, but they do not replace release planning. A feature can still be enabled for all users at once, which removes the main advantage of using feature flags.

Without a staged rollout, you lose the ability to catch issues early. A bug that only appears under real production load hits all your users at once, not 5% of them.

What works in practice​

Define rollout stages before you flip the first switch. A typical staged rollout:

Monitoring without baselines is guesswork. Before enabling a flag for any users, establish what normal looks like: error rates, p95/p99 latency, and key conversion metrics. Then watch for deviations at each stage.

At each stage, observe:

• Error rates: compared to the control groups
• Performance: latency and throughput changes
• User behavior: conversion, engagement, support volume

Define explicit thresholds for rollback before you start. "If error rate increases by more than 0.5% compared to the control group, roll back" is a decision you can make calmly in advance. It's much harder to make a clear decision in the middle of an incident.

5. Storing Sensitive Data in Feature Flags​

Feature flags should not contain sensitive data such as connection strings, API keys, or credentials.

The reason is simple: feature flags are not secrets managers. A frontend flag is delivered to the browser at page load and is readable by anyone with DevTools open. But even backend flag configurations lack the access controls, audit logging, and rotation mechanisms that credentials require.

How to fix it​

Use dedicated secrets management infrastructure for anything sensitive:

6. Overloading Feature Flags with Complex Logic​

Feature flags should control a single, well-defined behavior. When a single flag controls multiple features or contains complex logic, it quickly becomes difficult to understand, test, and maintain.

What works in practice​

Teams that avoid this keep flags focused and predictable. What starts as a simple toggle can easily turn into a mini decision engine embedded in your code.

This often happens when teams try to reduce the number of flags by grouping too much behind one. Instead of simplifying things, it creates hidden complexity.

What this looks like in practice​

You might see flags that:

• control multiple unrelated behaviors
• include nested conditions (user segment + region + plan + environment)
• store structured data like JSON instead of a simple value
• act differently depending on the context that is not immediately obvious

At that point, understanding what the flag actually does requires reading multiple parts of the codebase.

A common side effect​

Overloaded flags often lead to unexpected interactions. A small change in targeting or rollout rules can affect multiple parts of the system at once. This makes debugging harder and increases the risk of unintended behavior in production.

Keeping flags small and focused reduces the risk significantly.

7. Not Having a Flag Ownership Model​

Most articles on feature flags focus on the flags themselves. This one is about the system around them, and it's where many teams quietly fail.

As teams and flag counts grow, questions that were easy to answer in a small codebase become difficult: Who created this flag? Is it still needed? Who can change it? What happens if it's toggled in production right now?

Without explicit ownership, flags become a shared global state that nobody feels fully responsible for.

What this looks like in practice​

• A flag exists, but nobody knows if it's safe to delete
• A flag is changed in production by one team, breaking behavior owned by another
• Flags are created without documentation, and six months later, the original context is gone
• An audit question like "who changed this flag and when?" has no clear answer

What works in practice​

• Assign ownership explicitly: every flag should have a named owner (a team, a squad, or a specific person) and that ownership should be visible in the flag management tool, not just in a document somewhere
• Document at creation time, not after: a flag's description should include: what it does, why it exists, when it can be deleted, and what the safe default value is if the flag evaluation fails. This takes two minutes to write when the context is fresh and hours to reconstruct later
• Require an audit log: for production systems, every flag change should be traceable: who made the change, from what value to what value, and when. This is essential for incident response
• Include flags in incident reviews: when a production incident involves a flag change, review whether the ownership and change process worked as intended. Flags that caused the incidents are often flags that lacked clear ownership

When to Bring in a Feature Flag Management Tool​

As the number of flags grows, managing them manually (in config files, environment variables, or a homegrown database table) becomes a significant operational burden. A dedicated tool provides the infrastructure that makes the practices above sustainable at scale.

What to look for when evaluating a tool:

• Audit log: who changed what flag, when, and to what value
• Targeting and segmentation: roll out to specific users, regions, or cohorts
• SDK support: server-side SDKs are essential for backend enforcement
• Lifecycle management: surfaces stale or unused flags before they become technical debt

Without tooling, most of the practices in this article require manual discipline that doesn't scale. Tooling makes the discipline structural.

ConfigCat is one option worth evaluating, particularly for teams that want straightforward flag management without significant infrastructure overhead. It provides SDK support across major languages, a clean targeting interface, a Zombie Flags Report for stale flag detections, and full audit logging.

To Sum It Up​

Feature flags make it easier to release features gradually, test changes in production, and respond quickly when something goes wrong. At the same time, they introduce a layer that needs to be maintained.

Most issues with feature flags come from how they are used. Flags remain in the system longer than intended, get reused without a clear meaning, or are introduced without a plan for how they will be removed.

With the best practices covered, managing feature flags doesn't have to be a headache. Keep them short-lived, keep them named clearly, keep sensitive data out of them, and clean them up when the job is done.

If you want to learn more about feature flags or stay up to date with all the latest news, follow ConfigCat on X, Facebook, LinkedIn, and GitHub to learn more.

In this guide, you'll learn:

• What a canary release is
• How it works with feature flags
• A step-by-step rollout strategy using ConfigCat
• Best practices and common mistakes to avoid

What Is a Canary Release?​

A canary release (also called a canary deployment) is a strategy where a new feature is introduced to a small subset of users before being rolled out to everyone. Instead of releasing a feature globally, the rollout happens in controlled stages.

Example rollout strategy:

Team members → Beta users → 1% of users → 5% of users → All users

This incremental approach helps teams:

• Limit the impact of potential issues
• Test features with real users
• Gather early feedback
• Roll back quickly if something goes wrong

Feature flags make this strategy even easier because they allow teams to control feature visibility without redeploying code. If you're new to this concept, our guide on feature flags and how they work explains the fundamentals and common use cases.

Why Is It Called a Canary Release?​

The term comes from coal mining, where miners used canaries to detect toxic gases. If the canary was affected, it warned miners of danger.

In software, early users act as the "canary", helping detect issues before a full rollout.

When Should You Use a Canary Release?​

Canary releases are especially useful when:

• You're shipping high-risk or critical features
• You want to test changes in a real production environment
• Performance or scalability is a concern
• You have a large user base and want to reduce rollout risk

For example, in microservices architecture, canary releases help isolate failures without impacting the entire system.

Benefits of Canary Releases​

A well-executed canary rollout helps teams:

• Catch bugs in real-world conditions
• Monitor performance under gradual load
• Ship features with more confidence
• Roll back quickly if issues appear
• Build confidence before a full rollout

Challenges to Be Aware Of​

Canary releases aren't without tradeoffs. Depending on your setup, you may need to handle:

• Multiple versions of your application
• Increased infrastructure complexity
• Database compatibility between versions
• Additional monitoring requirements

This is why many teams rely on feature flag platforms to simplify rollout logic.

Canary Release vs A/B Testing​

These concepts are often confused but serve different purposes:

• Canary releases: detect bugs, regressions, and performance issues
• A/B testing: test product ideas and user behavior

Canary rollouts typically complete in minutes or hours, while A/B tests may run for days to reach statistical significance.

How Feature Flags Simplify Canary Releases​

Feature flags (also called feature toggles) give you direct control over how features are exposed without redeploying your application.

Instead of relying on infrastructure-heavy solutions like traffic routing or load balancers, you can manage rollouts directly in your code and dashboard.

With feature flags, you can:

• Release a feature to a specific group of users
• Roll out changes gradually using percentages
• Turn features off instantly if needed

This approach fits into progressive delivery, where features are released in controlled steps instead of all at once.

Platforms like ConfigCat make this even easier by letting you define targeting rules and rollout percentages without modifying your codebase.

How to Choose Canary Users​

Before starting a rollout, decide who should see the feature first.

Common strategies include:

• Internal team members (developers, QA)
• Beta testers or early adopters
• A random percentage of users
• Specific regions or countries
• Low-risk or non-critical users

Choosing the right users helps reduce risk and gather meaningful feedback early.

A Simple Canary Release with ConfigCat​

Let's look at how a basic rollout might work in practice.

In this example, we assume you've already:

• Logged into the ConfigCat dashboard
• Created a feature flag
• Integrated the ConfigCat SDK into your application

Our feature flag will be called:

facebook_sharing_enabled

Initially, the feature is turned off for everyone.

Step 1: Start with the Feature Disabled (Unreleased State)​

At this point the feature flag already exists, but it isn't serving the feature to everyone.

In the ConfigCat dashboard, the flag is simply set to OFF, which means every user will receive the default value and the feature remains hidden.

This is usually how a rollout begins. The code for the feature can already be deployed in production, while the flag keeps the functionality disabled until you're ready to start exposing it to users.

In other words, the application contains the new functionality, but the feature flag ensures that users won't see it yet.

A simple example might look like this:

if (configCatClient.getValue("facebook_sharing_enabled", false)) {
  showFacebookShareButton();
}

Since the flag is currently OFF for everyone, the Facebook sharing button will not appear for any users.

Step 2: Release to Internal Team Members​

The next step is to enable the feature only for internal users. Before rolling out a new feature to real users, many teams first expose it to developers, testers, or product managers inside the company. This makes it possible to test the feature in a real production environment and quickly gather feedback.

In this example, the feature flag is enabled only for users whose email contains @mycompany.com.

Everyone else will still receive the OFF value, so the feature remains hidden from external users.

Step 3: Expand to Trusted Users (Beta Group)​

Next, you can expand the rollout to a slightly larger group. In addition to internal team members, many teams include a small group of trusted users such as friends, beta testers, or early adopters. These users can provide valuable feedback before the feature becomes available to everyone.

In this example, the feature is enabled for users whose email contains @mycompany.com or @friends.com.

Everyone else will still receive the OFF value, so the feature remains hidden from the wider audience. This step helps gather feedback from real users in a controlled way before moving to a broader rollout.

Step 4: Release to 1% of Users - But No Sensitive Users​

If more feedback is needed, the next step is to expose the feature to a small percentage of users. Instead of enabling the feature for everyone at once, you can gradually roll it out to a small portion of your user base and observe how it behaves in production. This approach is commonly known as canary release.

In this example, the feature is enabled for 1% of users, while the remaining 99% still receive the OFF value.

At the same time, it's often a good idea to exclude certain users from early rollouts. These might include high-value customers, sensitive markets, or users who rely heavily on the stability of your product.

In the screenshot above, users from the United States are treated as sensitive users and are explicitly excluded from the rollout.

This way you can safely collect feedback from a small portion of real users while reducing the risk of impacting your most sensitive user groups.

Step 5: Increase to 5% of Users - But No Sensitive Users​

Once the feature works well for internal users and early testers, the rollout can be expanded further.

In this step, the feature is enabled for 5% of users, while sensitive users are still excluded. This gradually increases exposure while keeping the risk under control.

At this point, the feature is available to team members, friends, and a small portion of the general user base, while the remaining users still receive the OFF value.

Step 6: Release to Everyone Except Sensitive Users​

At this stage, the feature has already been tested with internal users, trusted testers, and a small percentage of the user base. The feedback collected during those steps should give enough confidence to expand the rollout further.

Now the feature can be enabled for all users except the sensitive group.

In this example, users from the United States are still excluded from the rollout, while everyone else receives the ON value.

This step exposes the feature to almost the entire user base while still protecting the most sensitive users until the rollout is fully validated.

Step 7: Release to Everyone​

If everything looks stable - bugs have been fixed, the UI behaves as expected, and feedback from early users is positive - the feature can finally be released to the entire user base, including previously excluded sensitive users.

At this point, the feature flag simply serves the ON value to all users, completing the rollout.

What to Monitor During a Canary Release​

Monitoring is what makes canary releases effective. Without it, you're just rolling out blindly.

Focus on core system metrics first:

• Error rates, to catch failures early
• Latency and performance, to keep the app responsive
• System load, especially if the feature adds overhead

At the same time, watch how users respond:

• User behavior, such as drop-offs or unusual patterns
• Conversion metrics, to measure real impact

If anything looks wrong, feature flags act as a kill switch, letting you disable the feature instantly without redeploying.

Best Practices for Canary Releases​

A safe rollout is gradual and controlled. Start small and expand only when confident.

• Begin with internal users
• Roll out step by step (1% → 5% → 25% → 100%)
• Monitor metrics continuously

To reduce risk:

• Exclude sensitive users early
• Use feature flags for instant rollback

After rollout, remove unused flags. Following feature flag naming conventions can also help keep things organized.

Common Canary Release Mistakes​

Even with a solid strategy, certain mistakes can reduce effectiveness of a canary release.

Common mistakes include:

• Rolling out too quickly
• Not monitoring key metrics
• Including sensitive users too early

Over time, teams may also run into issues like:

• Leaving old feature flags in the codebase
• Using canary releases as A/B tests instead of a risk-reduction strategy

Keeping these mistakes in mind helps you maintain a safer, more controlled release process while getting the full benefits of canary deployments.

Conclusion​

Gradual rollouts help teams release new features with confidence. By starting with internal users, expanding to trusted testers, and slowly increasing the percentage of affected users, teams can monitor performance and catch issues early.

This type of canary release strategy reduces risk compared to releasing a feature to everyone at once.

Feature flag tools like ConfigCat make this process straightforward by providing targeting rules, percentage rollouts, and a simple dashboard to control feature exposure without redeploying code. Because of this, both developers and product teams can safely manage feature releases and experiment directly in production.

If you'd like to try this rollout strategy yourself, you can sign up for ConfigCat and start using feature flags in minutes. ConfigCat offers a generous Forever Free plan, so you can experiment with gradual rollout and feature targeting without any upfront commitment. You can also follow ConfigCat on X, GitHub, LinkedIn, and Facebook to stay up to date with what we're building next.

Coming up, we'll learn what Bun is and how it compares to Node.js, then dive into using ConfigCat feature flags in Bun projects. Finally, we'll discuss how to safely roll out new features, A/B test them, and quickly fix problems in production, all with the help of feature flags.

What is Bun? (Bun vs. Node.js)​

Bun was created as a JavaScript runtime replacement for Node.js. With added features like bundling, testing, and package management, it later became a toolkit for developing both JavaScript and TypeScript applications with better performance.

Here is a comparison between them:

Why Use Feature Flags in Bun Applications?​

Bun's speed and near-instant startup time make it an excellent choice for applications where behavior may need to change frequently. Feature flags complement this perfectly by allowing you to toggle features, run experiments, or adjust application behavior without a redeployment or app restart.

For command-line tools, Bun's fast startup means users get immediate responses. For serverless functions, faster cold starts translate to lower costs and better performance. However, raw speed alone isn't enough; software teams need to roll out changes safely, test new ideas with small user groups, and roll back quickly when something goes wrong.

This is exactly what feature flags provide. When combined with ConfigCat's feature management and remote configuration capabilities, Bun applications gain:

• Real-time control over features and configuration
• Safe, gradual rollouts instead of risky big releases
• Instant kill switches for problematic code
• Dynamic A/B testing without code changes
• Flexible behavior for CLI tools, servers, and serverless environments

In a nutshell, Bun gives you speed. Feature flags give you control. Together, they enable fast, reliable, and modern software delivery.

How to Use Feature Flags in Bun with ConfigCat​

To help you understand how to integrate ConfigCat feature flags in a Bun application or environment, here's a step-by-step guide:

Step 1: Create a Bun Project and Install the Bun SDK​

First, open a terminal and install bun:

npm install -g bun

With Bun installed, create a new directory and initialize a Bun project using the following commands. When prompted, select Blank as the project template to use.

mkdir bun-feature-flags
cd bun-feature-flags
bun init

Then, proceed to install the ConfigCat Bun SDK:

bun add @configcat/sdk

Bun's package manager is really fast. The whole process of installing and setting it up takes a few seconds.

Step 2: Initialize the ConfigCat Client​

Create a reusable ConfigCat service so you can import and use it to evaluate feature flags throughout your application. In your Bun project, create a new file named configcat.service.ts, then paste the code below into the file.

import * as configcat from "@configcat/sdk/bun";
import {
  PollingMode,
  type IConfigCatClient,
  type SettingValue,
  type User,
} from "@configcat/sdk/bun";

export class ConfigCatService {
  private readonly client?: IConfigCatClient;

  private readonly SDK_KEY =
    "YOUR-CONFIGCAT-SDK-KEY"; //Add your ConfigCat SDK key here.
  private defaultUser?: User;
  private readonly POLL_INTERVAL_SECONDS = 30;

  constructor() {
    try {
      this.client = configcat.getClient(this.SDK_KEY, PollingMode.AutoPoll, {
        pollIntervalSeconds: this.POLL_INTERVAL_SECONDS,
      });
    } catch (error) {
      console.error("ConfigCat initialization failed:", error);
    }
  }

  // Get the value of a setting value
  getValue<T extends SettingValue>(key: string, defaultValue: T, user?: User) {
    return this.client?.getValueAsync(
      key,
      defaultValue,
      user ?? this.defaultUser,
    );
  }

  getAllValues(user?: User) {
    return this.client?.getAllValuesAsync(
      user ?? this.defaultUser,
    );
  }

  dispose(): void {
    this.client?.dispose();
  }

  [Symbol.dispose](): void {
    console.log("Disposing ConfigCat Service");
    this.dispose();
  }
}

By using AutoPoll, the SDK periodically fetches your latest feature flag data every 60 seconds, so your flags remain in sync without requiring manual updates.

Step 3: Evaluating Feature Flags​

To evaluate feature flags, import the ConfigCat service into your Bun entry file (index.ts) and use it as shown below.

import { ConfigCatService } from "./configcat.service";

async function createApp() {
    using configCatService = new ConfigCatService();

    const isMyFeatureEnabled = await configCatService.getValue("myFeatureFlag", false);

    console.log("The feature flag value is: ", isMyFeatureEnabled);

    return;
}

createApp();

With this setup, you can evaluate feature flags anywhere in your application.

Real-World Use Cases for Bun Feature Flags​

To build on what we previously learned, let's look at some practical use cases for using feature flags in a Bun environment or codebase.

Progressive Feature Rollout​

Imagine you're building a new API endpoint and want to test it with 10% of users first, then gradually increase to 100%.

Because ConfigCat's percentage targeting evaluates users deterministically, you can pass a User Object containing a unique identifier as the third parameter so users consistently fall into the rollout group.

import { ConfigCatService } from "./configcat.service";

async function handleRequest(userId: string, request: Request) {
    using configCatService = new ConfigCatService();

    const newApiEnabled = await configCatService
    .getValue(
        "new-api-endpoint",
        false,
        { identifier: userId } // User Object
    );

    if (newApiEnabled) {
        return handleWithNewAPI(request);
    } else {
        return handleWithLegacyAPI(request);
    }
}

In ConfigCat's dashboard, you can set the new-api-endpoint flag to target a percentage of users. As you gain confidence, you can increase the percentage without touching the actual code.

A/B Testing in Bun CLI Tools​

Bun also excels at CLI tools. Here's a way to run an A/B test experiment to evaluate two different user experiences:

import { parseArgs } from "util";
import { ConfigCatService } from "./configcat.service";

async function main() {
    using configCatService = new ConfigCatService();

    const { values } = parseArgs({
        options: {
            user: {
                type: "string",
                short: "u",
            },
        },
    });

    const userId = values.user || "anonymous";

    const experimentVariant = await configCatService.getValue(
        "ui-experiment-variant",
        "control",
        { identifier: userId }
    );

    if (experimentVariant === "variant-b") {
        console.log("User sees experience B");
        // Run variant B logic
    } else {
        console.log("User sees control experience");
        // Run control (variant A) logic
    }
}
main().catch(console.error);

Serverless Functions with Kill Switches​

The start-up performance of Bun makes it ideal for serverless environments. Feature flags provide instant kill switches:

import { ConfigCatService } from "./configcat.service";

export async function handler(event: any) {
    using configCatService = new ConfigCatService();

    // Check if the feature is experiencing issues
    const maintenanceMode = await configCatService.getValue(
        "maintenance-mode",
        false
    );

    if (maintenanceMode) {
        return {
            statusCode: 503,
            body: JSON.stringify({
                error: "Service temporarily unavailable",
            }),
        };
    }

    // Proceed with normal logic
    return {
        statusCode: 200,
        body: JSON.stringify({ message: "Success" }),
    };
}

If your service degrades, you can toggle the flag off in ConfigCat without a code redeployment.

Advanced ConfigCat Features in Bun​

There are several advanced ConfigCat features for Bun that we can look into. Some of them are:

Targeting Rules​

ConfigCat allows you to define targeting rules for your feature flags, ensuring features are delivered to the right users based on attributes such as identifier, country, email, and more. Here's a simple example of how to implement it:

// Sample user object
const userObject = {
    identifier: "user@example.com",
    email: "user@example.com",
    country: "US",
    custom: {
        subscription: "premium",
        joinDate: "2023-01-15",
    },
};

const premiumFeature = await configCatService.getValue(
    "premium-analytics",
    false,
    userObject
);

In ConfigCat's dashboard, create a targeting rule: "If subscription equals premium, then Serve value: true". Now the flag will ensure that only users with a premium subscription see the feature.

Getting All Flag Values​

For cases of dashboards or reporting, you can fetch all flags at once using the code below.

const allValues = await configCatService.getAllValues({
    identifier: "user123",
});

allValues.forEach((item) => {
    console.log(`${item.settingKey}: ${item.settingValue}`);
});

Snapshots for Synchronous Evaluation​

Bun supports synchronous operations for flags already cached. The code below shows the implementation for that.

const snapshot = client.snapshot();
const value = snapshot.getValue("my-flag", false, userObject);
console.log(value);

This is perfect for synchronous code paths where async/await isn't practical.

Best Practices for Feature Flags in Bun​

To use feature flags in the best and most effective way, here are some best practices to look into.

Use Semantic Flag Names​

Name flags clearly to indicate their purpose:

• new-checkout-flow (better than words like feature-x, new-feature)
• premium-analytics-dashboard (better than words like flag-123, test-flag)

Implement Proper Logging​

Feature flags can be difficult to debug without visibility into how values are evaluated. ConfigCat includes a built-in logger that helps you inspect flag evaluations and targeting decisions.

You can enable SDK logging when creating the client:

import * as configcat from "@configcat/sdk/bun";

const configCatClient = configcat.getClient(
    process.env.CONFIGCAT_SDK_KEY,
    configcat.PollingMode.AutoPoll,
    {
        logger: configcat.createConsoleLogger(configcat.LogLevel.Info),
    }
);

With LogLevel.Info, the SDK logs:

• Feature flag evaluations
• Targeting rule matches
• Returned values

This visibility makes it much easier to diagnose rollout issues and verify targeting behavior during development and testing.

When to Add Application-Level Logging​

While ConfigCat's logger is useful for diagnostics, you may still want to log business events for analytics, monitoring, or auditing.

const enabled = await configCatClient.getValueAsync("my-flag", false, {
    identifier: userId,
});

if (enabled) {
    auditLogger.info("Feature enabled", {
        feature: "my-flag",
        userId,
    });
}

This type of logging is helpful for:

• Tracking feature adoption
• Auditing behavior
• Product analytics
• Monitoring gradual rollouts

Cache Results When Possible​

For performance-critical code, cache the flag value during the request.

async function handleRequest(userId: string) {
    const flags = {
        newUI: await configCatService.getValue("new-ui", false, { identifier: userId }),
        analytics: await configCatService.getValue("advanced-analytics", false, {
            identifier: userId,
        }),
    };

  // Use flags.newUI and flags.analytics throughout the request
  // No additional flag evaluations needed
}

Clean Up Old Flags​

As features become permanent or experiments conclude, remove the corresponding flags to keep your codebase and dashboard clean.

Unused flags, often called zombie flags, increase technical debt, complicate maintenance, and may trigger legacy logic unexpectedly.

ConfigCat helps you manage stale flags by:

• Identifying inactive flags in the Zombie Flags dashboard
• Sending automated zombie flag email reports
• Providing an API for cleanup automation

If you enable Code References, ConfigCat can show where a flag is used across your repositories, making it safer to remove unused flags.

You can go a step further by scanning your codebase with the ConfigCat CLI:

configcat scan . --print

This detects flag usage, highlights references to deleted flags, and helps prevent breaking changes during cleanup.

Regularly removing stale flags keeps your feature flag system maintainable and prevents long-term technical debt.

Document Flag Purpose​

In ConfigCat, you can add descriptions like:

• When the flag was created
• What feature or experiment does it controls
• The rollout strategy (gradual rollout, A/B test, internal only)
• The expected removal date
• The team or owner responsible

Use tags to organize and filter flags at scale. For example:

• experiment
• release
• ops
• beta
• cleanup-required

Tags make it easier to track flags by purpose, environment, or lifecycle stage.

You can also include descriptive hints in the flag description to guide future developers, such as:

"Temporary rollout flag for the new checkout flow. Remove after full rollout."

Clear documentation reduces onboarding friction, prevents misuse, and makes flag cleanup safer and faster.

Conclusion​

Feature flags are no longer just a nice-to-have; they're essential for modern software delivery. Combined with Bun's performance and simplicity, they create a powerful foundation for building reliable, scalable applications.

Whether you're building CLI tools, serverless functions, or backend services, integrating ConfigCat feature flags in Bun takes minutes and pays dividends immediately.

Start with a simple kill switch. Progress to A/B testing. Eventually, you'll wonder how you ever shipped software without feature flags.

Ready to try it? Grab your Bun SDK key from ConfigCat and deploy your first feature flag today. Your users and your deployment pipeline will thank you.

You can also check out ConfigCat on Facebook, X, LinkedIn, and GitHub.

Rather than rebuilding every flag by hand, you'll export your entire Prefab configuration into a data file and use ConfigCat's AI-powered Model Context Protocol (MCP) server to transfer your configuration with minimal effort.

Prefab was acquired by Reforge and is being rebranded as Reforge Launch. If you're evaluating Prefab alternatives, ConfigCat offers a comparable feature set. With this simple migration process, you can see exactly how your Prefab feature flags behave in ConfigCat.

TL;DR: How to Migrate from Prefab?​

1. Use the @prefab-cloud/prefab CLI tool to download your Prefab feature flags as a .json data file.

2. Set up an AI agent (like Claude Desktop or Cursor) to connect to ConfigCat using the ConfigCat MCP server.

3. Ask the AI agent to interpret the exported file and migrate your feature flags from Prefab to ConfigCat.

Read on for the full step-by-step walkthrough.

Prefab vs. ConfigCat: How the Concepts Map​

Before diving into the migration, it's helpful to understand how the two platforms map to each other conceptually.

• Prefab Feature Flags are equivalent to Boolean Feature Flags in ConfigCat (simple on/off toggles).
• Prefab Config values (int, double, string, string list, JSON) map to Int, Double or String Settings in ConfigCat. JSON configs can be represented as a String Setting that stores the serialized JSON. A string list can also be mapped to a String Setting that stores comma-separated strings.
• Both tools use Segments for reusable user groups, Targeting Rules for feature flag targeting and support multiple Environments like Production, Staging, Dev, etc.

You can learn more about how ConfigCat structures Settings, Products and Environments in the ConfigCat Main Concepts documentation.

Prerequisites​

• Prefab account with existing feature flags
• ConfigCat account - sign up for free, if you don’t have one
• Node.js version 16 or higher installed
• Claude Desktop installed

Step 1: Export Your Prefab Feature Flags​

The @prefab-cloud/prefab CLI can download your entire Prefab configuration into a local config.json file. This file contains all your feature flags, config values, targeting rules, and segment definitions.

For this guide, assume you have these two feature flags in Prefab:

This is the BetaUsers segment used by BetaFeatures feature flag:

Install the Prefab CLI​

npm install -g @prefab-cloud/prefab

Create Prefab API Key​

The Prefab CLI tool needs an API key to access your feature flags.

Log in to your Prefab account and create an API key:

1. Click Environments.
2. Click Add Backend API Key under the environment you want to migrate.
3. Copy the Plain API Key. The Prefab CLI will use this API key.
4. Click OK.

Download the configuration data file​

Let's export the configuration file of the Development environment:

prefab download --api-key <YOUR-PREFAB-BACKEND-API-KEY> --environment Development

This produces a config.json file in your working directory. It contains a complete snapshot of your Prefab flags. Keep this file handy, you'll upload it to the AI agent.

Step 2: Configure ConfigCat MCP Server​

What is an MCP Server?​

Model Context Protocol (MCP) is an open standard that allows AI assistants to connect with external tools and services. Think of it as giving your AI agent hands to actually perform actions, not just talk about them.

An MCP server acts as a bridge between your AI client (like Claude Desktop) and an external service's API. When you ask your AI assistant to "list all feature flags in my project," the MCP server translates that natural language request into the appropriate API calls and lists your flags.

Creating ConfigCat Public API Credentials​

The ConfigCat MCP server needs a ConfigCat Public API credential to access ConfigCat's public management API and perform actions like managing feature flags, targeting rules, or segments, etc.

You can create this credential on the Public API credentials management page.

Installing MCP Server​

1. Install Claude Desktop, if you haven’t already.
2. Open Settings → Developer
3. Click Edit Config
4. In claude_desktop_config.json add:

{
  "mcpServers": {
    "ConfigCat": {
      "command": "npx",
      "args": ["-y", "@configcat/mcp-server"],
      "env": {
        "CONFIGCAT_API_USER": "YOUR_CONFIGCAT_API_USER",
        "CONFIGCAT_API_PASS": "YOUR_CONFIGCAT_API_PASSWORD"
      }
    }
  }
}

5. Save & restart Claude Desktop.

Verify the MCP Server Connection​

Let's try asking the agent to list all ConfigCat feature flags using the following prompt:

"List all feature flags in my ConfigCat account"

You should see a list of your ConfigCat feature flags with their names, IDs, and statuses. If this is a new ConfigCat account, you might see the default myNewAwesomeFeature flag created during registration.

Step 3: Migrate the Feature Flags to ConfigCat​

Upload the exported Prefab configuration data file, and let's ask the agent to migrate the first flag:

"migrate NewCheckoutFlow Prefab feature flag into ConfigCat"

On the ConfigCat dashboard, you can check the migrated NewCheckoutFlow flag:

Let's migrate the other one:

"migrate BetaFeatures Prefab feature flag into ConfigCat"

On the ConfigCat dashboard, you can check the migrated BetaFeatures flag:

This is the migrated BetaUsers segment used by the BetaFeatures feature flag:

The migration is complete. On top of that, you should update all usages of these flags in your codebase to use the appropriate ConfigCat SDK rather than the previous Prefab SDK.

Questions You Might Have During Migration​

Is it possible to remove the migrated from Prefab text from a migrated feature flag's description?​

Yes. Add this requirement to your migration prompt like this:

"Migrate BetaFeatures Prefab feature flag to ConfigCat. Keep the original description, don't append the text: migrated from Prefab."

Is ConfigCat a good Prefab alternative for teams affected by the Reforge acquisition?​

Yes. Prefab was acquired by Reforge and is being rebranded as Reforge Launch. For teams that want to stay on a dedicated, independent feature flag platform rather than follow the rebrand, ConfigCat is a strong alternative. It covers the same core use cases like boolean flags, multi-value settings, segments, targeting rules, and multiple environments, while also offering broader SDK support, global CDN delivery, transparent usage-based pricing with no seat limits, and a zero data collection architecture with strong security by design.

Can I migrate flags from other feature flag tools like LaunchDarkly?​

For LaunchDarkly, ConfigCat has an official migration tool built into the ConfigCat dashboard.

For other tools (such as Statsig or DevCycle) that provide an MCP server, you can run a migration process that uses two MCP servers. The AI agent communicates with both servers and transfers the flags from the source tool via its MCP server to ConfigCat via the ConfigCat MCP server. This method is explained in detail in the following blog post.

Can I use AI to refactor the usage of the migrated feature flags in my codebase?​

Yes. A ConfigCat MCP server can access the ConfigCat SDK documentation and assist with implementing ConfigCat feature flags.

It’s recommended to configure the ConfigCat MCP server in an AI coding tool such as Cursor, Claude Code, or VS Code with Copilot. Just ask the AI tool to update the codebase like this:

"Migrate my codebase from Prefab to ConfigCat for the "BetaFeatures" feature flag."

AI-generated code may contain mistakes; always validate and test it.

Is it possible to use ConfigCat's hashed confidential text comparators instead of cleartext comparators?​

Yes. Add this requirement to your prompt like this:

"Migrate NewCheckoutFlow Prefab feature flag to ConfigCat. Use hashed ConfigCat confidential text comparators wherever possible instead of cleartext comparators."

Conclusion​

Migrating feature flags from Prefab to ConfigCat with the Prefab CLI tool and the ConfigCat MCP server is straightforward:

1. Download the data file with the Prefab CLI tool
2. Set up ConfigCat MCP servers in your IDE
3. Export your complete environment into a data file from Prefab with the CLI tool
4. Load the exported data into the AI agent and ask to migrate the feature flags one by one
5. Verify and run both systems in parallel before cutover

Resources​

• ConfigCat MCP server documentation
• ConfigCat MCP server GitHub repository
• ConfigCat MCP server available tools
• Management API Reference
• Official LaunchDarkly to ConfigCat migration tool
• How to Migrate from Statsig to ConfigCat: Feature Flag Migration Using MCP Servers - Blog post

For more on feature flags, check out ConfigCat on Facebook, X, LinkedIn, and GitHub.

If you're looking for a Prefab alternative, ConfigCat is a great choice. It does everything Prefab Reforge Launch does. Sign up and try it yourself or book a demo to see it in action.

Over the past years, we kept hearing the same request in different forms:

• “Can we have enum-like values for feature flags?”
• “Can we avoid people mistyping values?”
• “Can we define JSON values once and just select it?”
• “Can we separate flag definitions from rollouts?”

This usually came up when teams started using multivariate feature flags or working with more complex JSON feature flags.

Free-form values are flexible. But when feature flags become operational tools, toggled by Customer Success, Sustainment teams, or junior teammates, flexibility without guardrails becomes a risk.

So we built Predefined variations.

What Are Feature Flag Variations?​

Predefined variations let you define your possible feature flag values upfront. Instead of typing the value manually every time you create a targeting rule, you select it from a dropdown.

Each variation includes:

• Served value – the actual value returned to your application (including full JSON)
• Display name – a human-readable label
• Hint (optional) – guidance for when to use it

In other words: define once, reuse safely.

If you’ve been looking for a way to implement a feature flag enum directly in the dashboard, this is it.

Managing JSON Feature Flags Without Copy-Paste Drift​

Predefined variations are particularly useful for JSON feature flags.

Instead of embedding the full JSON object in every targeting rule, you define it once as a variation. That variation can then be reused consistently across environments and segments.

For example:

{
  "display_name": "Red Banner - Planned Outage",
  "hint": "Use during confirmed production incidents",
  "served_value": {
    "background_color": "red",
    "label": "Planned outage"
  }
}

Targeting rules then reference the variation by intent, not by repeating raw configuration.

This approach:

• Reduces duplication
• Improves clarity in overview screens
• Prevents small inconsistencies between environments
• Makes flags safer for operational teams

Definitions remain structured. Rollouts remain clean.

Supporting Multivariate Feature Flags and Enum Workflows​

Many teams use multivariate feature flags where values correspond to specific states in their application code. Often, these are mapped to enums on the backend.

With Predefined variations, the dashboard now mirrors that structure. Instead of typing arbitrary text or number values, you define the allowed options once and reuse them safely.

This reduces the chance of mismatched values and ensures consistency between the control plane and application logic.

Converting Existing Feature Flags​

Predefined Variations can be enabled on existing flags. When converting from free-form values to variations, the system automatically collects currently used values and suggests them as predefined options. You can then refine display names and hints.

You can also convert back to free-form values if needed. These conversions do not affect deployed applications.

When to Use Predefined Variations​

Predefined variations are a good fit when:

• You manage multivariate feature flags
• You reuse complex JSON configurations
• Non-engineers toggle production flags
• You want enum-like control in the ConfigCat Dashboard
• Consistency across environments matters

Free-form values remain available for simple use cases. Variations add structure where structure reduces risk.

Available in All Plans​

Predefined variations are available across all ConfigCat plans. They extend feature flag value management without adding complexity to rollout workflows.

Feature flags are meant to reduce deployment risk and improve operational control. As teams scale their usage, adding structure to feature flag values becomes a natural next step.

If you have feedback, we listen. Many of the improvements in this release came directly from customer conversations.

You can also stay up-to-date with us on X, GitHub, LinkedIn, and Facebook.

Early-stage SaaS teams face a unique challenge: they need to ship new features quickly, experiment often, and release continuously without risking production stability. Speed drives growth, but uncontrolled releases can lead to outages, technical debt, and lost user trust. That's why feature flags have become a core part of modern startup release management.

The ConfigCat Startup Program was created to help startups build with the right foundations from the beginning. It gives early-stage teams access to a production-ready feature flag service with startup-friendly pricing, so they can release safely while everything is still under construction.

Why Do Startups Need Feature Flags Early​

Feature flags (also called feature toggles) allow teams to control when and how new functionality becomes visible to users without redeploying code. For startups practicing CI/CD and rapid iteration, this separation of deploy and release is critical.

Shipping fast is essential for startups - but moving quickly without control can cost momentum, trust, or even a weekend fixing production. That's where feature flags come in.

Feature flags let you:

• Separate deploys from releases
• Test in production safely without exposing features to everyone
• Roll out new functionality gradually
• Instantly disable or adjust features when something goes wrong

The Hidden Cost of Homegrown Feature Flags​

Many early-stage teams start with homegrown toggles: environment variables, config files, or simple flags in code. It works… for a little while.

But as your product grows, these shortcuts create tech debt:

• No rollback or gradual rollout options
• Harder to test safely in multiple environments
• Limited visibility and collaboration for your team
• Complex refactors when scaling

ConfigCat provides a production-ready feature flag management platform, giving you the flexibility of a homegrown system without the hidden maintenance costs, scaling issues, or operational risk.

⚡ Pro tip: Already using another feature flag platform like LaunchDarkly or Statsig? ConfigCat offers migration guides so you can switch smoothly without disrupting production.

Why We Created the ConfigCat Startup Program​

At ConfigCat, we've seen startups struggle with two extremes:

1. Building internal systems that don't scale
2. Avoid professional tooling due to budget limitations common in early-stage startups

The Startup Program was designed to remove that trade-off. It provides early-stage teams with access to the same feature flag platform used in production by growing companies but with pricing and limits aligned to startup realities.

The goal isn't to add complexity. It's to give startups control over releases without complex setup.

What You Get in the Startup Program​

The Startup Program gives early-stage teams the full ConfigCat feature flag platform, plus startup-friendly benefits:

• 50% off Pro or Smart annual plans in Year 1
• 25% off Pro or Smart annual plans in Year 2
• Early access to upcoming new features

This isn't a stripped-down edition. Teams get full feature flag capabilities, including:

• advanced targeting rules,
• percentage-based rollouts,
• multiple environments (development, staging, production),
• remote configuration management,
• generous monthly config.json downloads and network traffic limits.

You can start simple and scale when you're ready without refactoring your release infrastructure later.

How the Startup Program Compares to Our Forever Free Plan​

ConfigCat's Forever Free plan is great for prototypes or early experiments. The Startup Program is for teams building real products with real users. If you're building a hobby project or early prototype, the Forever Free plan may be enough.

For a full breakdown of plan limits and details, see our pricing page.

Who the Startup Program Is Built For​

The program is designed for early-stage startups actively building and shipping software.

Eligibility criteria:

• Company founded less than 5 years ago
• Raised less than $5M USD in total funding
• Live website or product
• No paid ConfigCat subscription in the last 12 months

Not sure if you qualify? Apply anyway. We review applications individually, and the process typically takes up to one week.

A Two-Way Partnership​

The ConfigCat Startup Program is designed as a long-term partnership with early-stage teams.

Startups receive meaningful discounts and early access to new features. In return, participants share feedback and experiences as they grow with us.

Full details about participation and commitments are available on the Startup Program page, where you can review everything before applying.

How to Join ConfigCat's Startup Program​

If your startup qualifies, you can apply directly through the Startup Program page.

Once approved, you can activate your discounted plan and begin using production-ready feature flags from day one.

👉 Visit the Startup Program page to review the full details and submit your application.

Start with the Right Foundations​

Every startup builds while everything is still under construction. Features evolve. Assumptions change. Roadmaps shift. That’s the nature of building a startup.

What shouldn’t shift is your foundation.

The ConfigCat Startup Program helps early-stage teams build safely from day one, without enterprise pricing or unnecessary complexity.

If you are still validating ideas or building a prototype, you can start with our Forever Free plan. Sign up here, no credit card needed. When you are ready to scale, the Startup Program gives you room to grow.

To learn more and apply, visit the Startup Program page. You can also follow ConfigCat on X, GitHub, LinkedIn, and Facebook to stay up to date with what we're building next.

In this article, we'll share real-world feature flag examples from production, explain how we use our own system inside ConfigCat, and confess the biggest feature flag mistake we've ever made (so you don't have to repeat it).

How to Use Feature Flags in Your Application?​

At ConfigCat, we have a whopping number of 70 feature flags that control many different aspects of our applications on the backend and frontend sides as well.

We use feature flags to:

• Show targeted banners
• Hide in-progress features
• Run controlled experiments and A/B tests
• Roll out new features gradually
• Control beta access for selected users
• Separate behavior across environments (dev, staging, production)
• Flip emergency kill switches in production

In practice, this means we can ship code safely, test ideas without risk, and react instantly when production gets... interesting.

Let me show you some real-world examples of how a feature flag tool utilizes feature flags.

The Cute One - the isSantaHatVisible Feature Flag​

During the holidays, we dress up our cute ConfigCat logo with a Santa hat on our login/signup pages.

Yes, there is a feature flag for that. Yes, it's mission-critical.

The code behind it is pretty simple yet so powerful. Instead of hardcoding dates, we check the current month and day and let configuration decide whether the hat appears.

readonly isSantaHatVisible = resource({
  loader: () => {
    const now = new Date();
    return this.configCatService.getValueAsync("isSantaHatVisible", false, { 
      identifier: "n/a", 
      custom: { 
        month: now.getUTCMonth() + 1, 
        day: now.getUTCDate()
      } 
    });
 },
});

The "Learning" One - comparatorSuggestionsForComparisonAttributes​

This feature flag's key is the proof that naming things is still one of the hardest problems in computer science.

We strive to build an intuitive interface that anticipates what customers need, making their workflow seamless and frictionless.

ConfigCat's targeting rules offer powerful comparators to help you build precise rollout strategies. We launched with 15 comparators covering text, semantic versions, and numbers. Fast forward to today: we now have 35 different comparators available.

More choice is great, but it came with a cost. We didn't want our customers spending too much time scrolling through irrelevant options. The solution? Context-aware filtering. Now, when you're building targeting rules around registration dates, we automatically surface datetime comparators. Working with app versions? You'll see semantic version comparators front and center, not text-based ones you'd never use.

Behind the scenes, a feature flag powers this intelligence. It takes the comparison attribute you've selected and returns the most appropriate comparators. We could have hardcoded these mappings, but that would have meant redeploying every time we wanted to tweak the logic.

This is an important point: feature flags are not just for hiding unfinished features. They can power adaptive product behavior in production without increasing deployment risk.

Let us know if your comparison attributes are not showing the right comparators, and we'll try to adjust them.

The Guardian Angels - canUseConfigCat, isEmailSendingEnabled, disabledOrganizationCreation​

Back in 2020, we launched our public Bug Bounty Program without DDoS or firewall protections in front of our infrastructure. Basically, we walked into a gunfight with a butter knife. It didn't take long to realize we needed emergency parachutes inside the codebase.

So we added operational safety switches.

Email spammers trying to bankrupt us via our email provider? We deployed the isEmailSendingEnabled feature flag faster than you can say "captcha". (Of course, we later added proper CAPTCHA and infrastructure-level protections like responsible adults.)

Tired of manually deleting the 26th fake registration of admin@configcat.com? disabledOrganizationCreation became our new best friend.

Spotted someone clearly up to no good? Time for feature flag jail with canUseConfigCat. Sorry, not sorry.

Why does this matter?​

These weren't "product" flags. They were operational kill switches. There's an important difference.

Every production system should have emergency controls that allow teams to:

• Disable high-risk subsystems instantly
• Limit abuse without redeploying
• Isolate suspicious accounts
• Protect infrastructure while investigations are ongoing

A deployment pipeline is not an incident-response mechanism. Feature flags, when designed properly, can act as one.

We've since added proper DDoS protection, firewall layers and abuse prevention mechanisms. But these switches remain as battle scars and as proof that runtime control can literally save your system when things go sideways.

The Biggest Blunder in Feature Flag History - maintenanceModeEnabled - AKA How Not to Use Feature Flags?​

Let me tell you about the time ConfigCat, the feature flag service provider, spectacularly failed at using feature flags.

We had a major database migration scheduled and needed a simple way to lock out customers temporarily. Easy, right? We're the feature flag experts after all!

The plan was foolproof:

1. Create a maintenanceModeEnabled feature flag to be able to show a friendly "we'll be back soon" page. ✓
2. Turn on the feature flag. ✓
3. Execute the database migration. ✓ with flying colors.
4. Turn off the feature flag. ✗ Houston, we have a problem.

Turns out, when you enable a feature flag that blocks everyone from accessing your dashboard, that includes you. Who knew? (Literally everyone but us, apparently.)

Picture us: the feature flag experts locked out of their own feature flag system, SSH-ing into the database server to manually flip a Boolean in production. Peak DevOps energy.

Let's not talk about eating your own dog cat food.

What actually went wrong?​

The problem wasn't feature flags. The problem was architecture. We tied operational control to the same access path it was supposed to regulate. In simpler terms: the switch that locked users out also locked out the people who needed to unlock it.

That's not resilience. That's self-inflicted downtime.

The real lesson​

Maintenance mode (and any critical kill switch) must follow a few rules:

• Always include admin bypass logic
• Separate operational control from user-facing access
• Provide an out-of-band recovery path
• Test lockout scenarios before enabling them in production

A maintenance flag should never depend on the system it might disable. That's not just a funny story. It's a design principle.

Conclusion​

Feature flags are incredibly versatile tools. They can make your life easier, your deployments safer, and your customers happier. But as we've learned the hard way, they're not just convenience switches. But once they control production behavior, they become infrastructure. And infrastructure deserves discipline.

The real power of feature flags isn't just that they let you ship faster, it's that they let you correct course quickly when things don't go as planned.

Used well, they reduce risk. Used carelessly, they create it.

If you're ready to start your own feature flag journey (minus the face-palm moments), ConfigCat offers a forever free plan to help you get started. And don't worry, we've fixed the maintenanceModeEnabled flag since then (Pinky promise!)

You can also follow ConfigCat on X, GitHub, LinkedIn, and Facebook to stay up to date with what we're building next.

TL;DR: How to Migrate from Statsig?​

We are going to set up an AI agent (like Claude Desktop or Cursor) to connect to Statsig through the Statsig MCP server and to ConfigCat through the ConfigCat MCP server. After that, you can simply ask the AI agent to migrate your feature flags from Statsig to ConfigCat. Let’s see how to do this step by step.

Differences between Statsig and ConfigCat​

Before diving into the migration, it's helpful to understand how the two platforms map to each other conceptually. While ConfigCat and Statsig share many similar features and concepts, they use different terminology and have some structural differences.

• Statsig Feature Gates are equivalent to Boolean Feature Flags in ConfigCat (simple on/off toggles).
• Statsig Dynamic Configs store JSON payloads. In ConfigCat, the equivalent is a String Setting that stores the JSON as a string.
• Statsig Rules map to Targeting Rules in ConfigCat.
• Both tools use Segments for reusable user groups for targeting and support multiple Environments like Production, Staging, Dev, etc.

You can learn more about how ConfigCat structures Settings, Products and Environments in the ConfigCat Main Concepts documentation.

Prerequisites​

• Statsig account
• ConfigCat account - If you don’t have one yet, sign up here for free
• Node.js version 16 or higher installed

What are MCP Servers?​

Model Context Protocol (MCP) is an open standard that allows AI assistants to connect with external tools and services. Think of it as giving your AI agent hands to actually perform actions, not just talk about them.

An MCP server acts as a bridge between your AI client (like Claude Desktop) and an external service's API. When you ask your AI assistant to "list all feature flags in my project," the MCP server translates that natural language request into the appropriate API calls and lists your flags.

Creating ConfigCat Public API Credentials​

The ConfigCat MCP server needs a ConfigCat Public API credential to access the ConfigCat's public management API and perform actions like managing feature flags, targeting rules or segments etc.

You can create this credential on the Public API credentials management page.

Creating Statsig Console API Key​

The Statsig MCP server also needs Statsig Console API key to access the Statsig API via the MCP server.

Login to your Statsig account and create a console API key:

1. Settings -> Keys & Environments
2. Click Generate New Key
3. Select Console Key Type
4. Add a description like MCP console key for migration to ConfigCat
5. Enable Any Environment or Select specified one
6. Click Create

Installing MCP Servers​

1. Install Claude Desktop, if you haven’t already.
2. Open Settings → Developer
3. Click Edit Config
4. In claude_desktop_config.json add:

{
  "mcpServers": {
    "ConfigCat": {
      "command": "npx",
      "args": ["-y", "@configcat/mcp-server"],
      "env": {
        "CONFIGCAT_API_USER": "YOUR_CONFIGCAT_API_USER",
        "CONFIGCAT_API_PASS": "YOUR_CONFIGCAT_API_PASSWORD"
      }
    },
    "Statsig": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://api.statsig.com/v1/mcp",
        "--header",
        "statsig-api-key:${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "YOUR_STATSIG_AUTH_TOKEN"
      }
    }
  }
}

5. Save & restart Claude Desktop.

Verify the MCP Server Connections​

Let's try asking the agent to list all Statsig flags using the following prompt:

"List all feature gates in my Statsig account"

You should see a list of your Statsig feature flags with their names, IDs and statuses.

Let's do the same with the ConfigCat account

"List all feature flags in my ConfigCat account"

You should see a list of your ConfigCat feature flags. If this is a new ConfigCat account, you might see the default myNewAwesomeFeature flag created during registration.

The Migration Process​

The migration follows a simple two-step workflow: first export everything from Statsig, then create each flag in ConfigCat.

Export Your Statsig Feature Gates​

Let's assume in Statsig you have these two feature gates:

Start by getting a complete inventory of your flags. Use this prompt:

"List all feature gates in my Statsig project. For each gate, show me: name, description, status, default value and all targeting rules with their conditions."

Save this output. It becomes your migration checklist and reference for creating flags in ConfigCat.

Migrate the Feature Flags to ConfigCat​

Let's ask the agent to migrate the first flag:

"migrate beta_features Statsig feature gate into ConfigCat"

On the ConfigCat dashboard you can check the migrated beta_features flag:

Let's migrate the other one:

"migrate new_checkout_flow Statsig feature gate into ConfigCat"

On the ConfigCat dashboard you can check the second flag:

The migration is complete. On top of that, you should update all usages of these flags in your codebase to use the appropriate ConfigCat SDK rather than the previous Statsig SDK.

Questions You Might Have During Migration​

Is it possible to remove - migrated from Statsig text from a migrated feature flag's description?​

Yes. Add this requirement to your migration prompt like this:

"Migrate beta_features Statsig feature gate into ConfigCat. Keep the original description don't append the text: - migrated from Statsig"

Can I migrate Dynamic Configs or Parameter Stores?​

A Statsig Dynamic Config will be migrated into ConfigCat as a String Setting storing a JSON string.

Unfortunately, the Statsig MCP server can’t access Parameter Stores, so they can’t be migrated using the method described in this blog post.

Can I migrate flags from other feature flag tools like LaunchDarkly?​

For LaunchDarkly, ConfigCat has an official migration tool built into the ConfigCat dashboard.

For other tools (for example DevCycle) that provide an MCP server, you can run a similar migration process as described above.

Can I use AI to refactor the usage of the migrated feature flags in my codebase?​

Yes. A ConfigCat MCP server can access the ConfigCat SDK documentation and assist with implementing ConfigCat feature flags.

It’s recommended to configure the ConfigCat MCP server in an AI coding tool such as Cursor, Claude Code, or VS Code with Copilot. Just ask the AI tool to update the codebase like this:

"Migrate my codebase from Statsig to ConfigCat for the "beta_features" feature flag."

AI-generated code may contain mistakes, always validate and test it.

Can I migrate Statsig experiments?​

Statsig experiments can be mapped to ConfigCat’s percentage-based targeting rules.
You can migrate your experiment groups using the following prompt:

“Migrate the my_experiment Statsig experiment into ConfigCat as a feature flag with percentage-based targeting for each variant.”

Because ConfigCat follows a zero data collection strategy, it does not collect user-tracking data. For statistical analysis, you’ll need to integrate an analytics tool such as Google Analytics or Mixpanel.

Conclusion​

Migrating feature flags from Statsig to ConfigCat with MCP servers is straightforward:

1. Set up both MCP servers in your IDE
2. Export your complete flag list from Statsig
3. Ask the AI agent to migrate the feature flags one by one
4. Verify and run both systems in parallel before cutover

What previously took hours of manual work now becomes a series of copy-paste prompts. The AI handles the API complexity while you focus on ensuring your flags are correctly configured.

Resources​

• ConfigCat MCP server documentation
• ConfigCat MCP server GitHub repository
• ConfigCat MCP server available tools
• Management API Reference
• Official LaunchDarkly to ConfigCat migration tool

For more on feature flags, check out ConfigCat on Facebook, X, LinkedIn and GitHub.

If you’re a Statsig user and you’re interested in how migrating to ConfigCat works in practice, sign up and try it yourself or book a demo to see it in action.

Chaos engineering with feature flags offers a more controlled alternative. Instead of waiting for failures to happen, teams can deliberately inject small, realistic faults into production, limit their blast radius, and observe how systems behave under stress without risking a full-scale incident.

In this article, we'll look at how feature flags work, how they fit naturally into chaos engineering practices, and how chaos-enabled feature flags can help test production resilience through controlled failures.

What are feature flags?​

A feature flag is a software technique that functions like a remote switch inside your app. It is typically a boolean value that can be coupled with conditional statements in your code to enable or disable features or functionality without requiring a redeployment.

In the context of chaos engineering, feature flags are especially useful because they let you introduce and remove failure behavior in production without redeploying code.

Modern feature flag management platforms go further. Tools like ConfigCat allow you to configure your features with targeting and percentage rules to target a specific region, device, or user segment.

Here are a few common ways in which feature flags are used:

• Release flags - Gradually expose a new feature to 1%, then 5%, then 25% of users. Roll back to zero with a single click if needed.
• Operational flags - Switch off a heavy job, reduce cache TTLs, or enable a fallback implementation.
• Experiment flags - Direct a user segment to variant A or B for learning or A/B testing.
• Kill switches - Provide an emergency stop for malfunctioning features.

Chaos flags fall into that second group. They give engineers the ability to simulate degraded conditions or trigger controlled failures without deploying new code.

A quick primer on chaos engineering​

Chaos engineering is the practice of forming a hypothesis about a system’s steady state and then running experiments that challenge that assumption. You define what “normal” looks like in metrics and traces, pick a failure mode that could realistically occur, inject that failure in a controlled way, observe what changes, and learn where your controls or fallbacks are weak — then fix them.

Common failure modes include added latency, dropped requests, dependency timeouts, resource exhaustion, network partitions, and bad data. The most valuable experiments run close to production scale — ideally in production — which is where most teams start to get nervous. That’s where feature flags come in.

Chaos engineering with feature flags​

The ideal way to test the resilience and reliability of software is to incorporate chaos engineering practices.

Just relying on traditional chaos engineering tools like fault injection proxies, service mesh experiments, and traffic replays is powerful but often heavy to operate and hard to scope. When combined with feature flags, you get:

• Precision targeting - Scope by environment, service, percentage of traffic, user segment, or geographic region.
• Instant rollback - Toggling a flag is faster and less stressful than reverting a deployment.
• Auditability - Flags live in a control plane with change history, ownership, and approvals.
• Consistency - The same mechanisms used for dark launches, canary rollouts, and kill switches can drive failure simulations.

Chaos engineering provides a way to probe weak spots by introducing deliberate faults. Feature flags allow us to toggle functionality on or off. Combine the two, and you get chaos-enabled feature flags — flags designed not just to enable features, but to enable failure: deliberately, safely, and reversibly.

Think of it as a practical, reversible way to test resilience under real traffic. Flip one toggle, and a small, well-chosen slice of users experience added latency, a dependency failure, or a throttled resource — while everyone else remains unaffected. Measure how the system bends, not just whether it breaks. Learn, adjust, and repeat.

For example, imagine you want to test how your application handles a slow database. With a chaos flag, you can inject artificial latency for a targeted subset of users:

async function App() {
  using configCatService = new ConfigCatService();
  const userObject = getUserObject();
  const canInjectLatency = await configCatService.getValue(
    'chaosDatabaseLatency',
    false,
    userObject,
  );
  if (canInjectLatency) {
    // Simulate a slow database latency: add 500-2000ms of delay
    const delay = Math.random() * 1500 + 500;
    console.log(`Simulating a ${delay}ms database delay...`);
    await new Promise((resolve) => setTimeout(resolve, delay));
  }
  // Normal database call
  const userProfile = getUserProfileFromDatabase(userId);
  console.log('User Profile:', userProfile);
}

This approach makes reliability testing a regular habit, integrating it into delivery rather than treating it as a special event. You don’t need a large platform team or a heavy chaos toolchain to get started — but you do need discipline, observability, and a few sensible guardrails.

Benefits of chaos-enabled feature flags for resilience testing​

Using feature flags for chaos engineering offers several practical advantages.

• Safer production learning - Flags carry built-in safety: progressive exposure, instant rollback, approvals, and visibility. This reduces the risk of a chaos test turning into a public incident.
• Realistic conditions - Lab tests miss emergent behavior that only shows up with real caches, real network paths, and messy user patterns. Flags let you get real conditions with low risk.
• No redeploy needed - Feature flags let you run experiments during a code freeze because you can toggle behavior without deploying new code.
• Documentation for free - Flags with metadata, audit logs, and notes give you a history of how the system reacted under stress, helping future on-call engineers to troubleshoot faster.
• Precision and repeatability - Traditional chaos tools often operate at a lower layer, which can be noisy or broad. Feature flags let you aim faults at specific parts of your code, then repeat the same scenario weeks later to validate a fix.

Guardrails for safe chaos engineering in production​

Chaos engineering works best with boundaries. Most production incidents caused by experiments aren't due to bad ideas; they're caused by missing guardrails.

Here are the ones that matter in practice:

• Start small: Start with an internal cohort, then grow carefully. Production experiments can begin with employees, test accounts, or canary tenants.
• Time limits: Define how long the chaos flag should remain active. You can do so by adding a TTL on the flag or an automation that turns it off after a set window.
• SLO-aware automation: Wire the flag to your alert pipeline so that if the experiment degrades user experience, the system kills it automatically, notifies the team, and logs what happened.
• Full observability: Log the evaluated flag values with each request. Add them as attributes on traces and as labels on metrics. That makes before-and-after comparisons straightforward and prevents you from chasing phantom regressions.
• Single ownership: Every flag should have a runbook entry and a named owner or team. Document what it does, how long it should live, rollout plan, rollback plan, and expected signals or metrics.
• Isolation across environments: Keep separate flag keys or namespaces per environment. If one misconfiguration can enable a flag everywhere at once, you're one typo away from an outage.
• Change review: Treat a chaos flag toggle like a production change. Use the same approval workflow you use for risky config edits. The approval process adds enough friction to make you think twice before flipping a toggle.
• Cleanup discipline: Retire the flag as soon as the learning is recorded. Don't let zombie flags pile up, as they create technical debt, add cognitive load, and can cause surprise interactions.

Conclusion​

Chaos-enabled feature flags give you the best parts of two proven ideas. You get real production experiments and the safety of tight controls. You can target, define a time window, and roll back in seconds. You can turn reliability from a big quarterly event into a weekly practice that fits inside normal delivery.

Start with a service and one failure mode. Inject a little delay, then watch what happens. Fix the sharp edges you find. Share the outcome with the team. Then move to a second failure mode. Over time, you’ll accumulate a clear catalog of experiments and the practice to run them well. Your systems won't just pass health checks—they’ll behave reliably even under stress.

The goal is not perfection, but rather steady, deliberate learning with small bumps along the way and an easy path back to calm. If you're looking for a practical way to get started, a feature flag management platform like ConfigCat gives you the controls needed to run controlled failure experiments without disrupting users. The forever free plan is enough to begin experimenting with feature flags and resilience testing today.

You can also stay up-to-date with ConfigCat on X, GitHub, LinkedIn, and Facebook.

LaunchDarkly is the biggest name in the game, but it's not always the best fit. Maybe you need simple pricing, zero data collection, or an open-source option you can self-host. The good news: there are amazing Launchdarkly alternatives out there.

Here are the 8 best feature flag tools in 2025 to help you ship faster, safer, and stress-free.

1. ConfigCat - Simple, Transparent, and Built for Teams of All Shapes and Sizes​

ConfigCat is one of the most popular LaunchDarkly alternatives for teams who want essential feature flagging capabilities (user targeting, percentage rollouts, audit logs, enterprise-grade security, and blazing-fast SDKs) minus the clutter and surprises. Flat usage-based pricing (no per-seat or MAU charges), unlimited team members, zero end-user data collection, and a zero-pressure Forever Free plan make ConfigCat the feature-flagging companion that always lands on its feet.

Why teams choose ConfigCat​

• Unlimited team members on all plans: invite everyone without extra cost
• Flat, transparent, usage-based pricing (no per‑seat/MAU fees)
• Zero data collection architecture: flags are evaluated on client side, user data doesn't go to ConfigCat by default
• Blazing fast, global feature flag delivery
• Data residency control (EU, global CDNs, configurable governance)
• Rich SDK set across backend, frontend, mobile, game engines, and more
• Free LaunchDarkly-to-ConfigCat migration tool for fast onboarding
• OpenFeature support for easier integration and less lock-in
• Hosted, private cloud, and on-prem options
• Adorable cat logo 🐾

Pricing​

• Forever Free plan: 10 flags, 2 environments, 2 products, unlimited team members, 5M config.json downloads/month, unlimited seats
• Pro: Starts at $110/mo (100 flags, 3 envs/products, higher network limits)
• Higher tiers: From $325/mo, unlimited flags & increased usage limits
• All plans include customer support, advanced targeting, and enterprise features like SSO/SAML and SCIM

Best for you if: you want a simple, scalable feature flag solution with unlimited seats, predictable pricing, and no hidden usage traps.

Less ideal if: you need deeply integrated built-in statistics for experimentation (you can still run experiments by combining ConfigCat with your analytics/data warehouse).

2. Flagsmith - Open Source with Self-Hosting Flexibility​

Flagsmith is built for teams that love open source and want to shape their feature flag system to fit their world. If fine-tuning YAML brings you the same quiet joy a cat gets from finding a new sleeping spot, Flagsmith is your tool.

Why teams choose Flagsmith​

• 100% open-source, so you can see (and change) the code
• Flexible deployment: fully on-prem, private cloud, or in their SaaS
• A/B and multivariate testing built into the platform
• OpenFeature support so you can swap vendors without changing app code

Pricing​

• Free plan: Unlimited flags and environments, 1 user/month, up to 50k requests/month
• Start-up plan: $45/mo, 3 members, 1M requests
• Enterprise plans: Custom pricing, 5M+ requests, premium support, private cloud/on-prem

Best for you if: you want open source + SaaS flexibility.

Less ideal if: you want a totally managed experience with no infra involvement (Flagsmith's SaaS is managed, but many teams adopt it precisely to later self-host).

Also, if you plan to self-host the open source version but still need enterprise governance: the OSS self-hosted setup doesn’t include things like role-based access control, audit logs, and guaranteed support/SLAs.

3. Split.io (Harness FME) - Enterprise-Grade Experimentation & Observability​

Split.io gives you feature flags with a scientific twist: built-in experiments, guardrails, and impact metrics that reveal exactly how your features behave. Since joining the Harness family in May 2024, Split has become part of a larger enterprise toolkit designed to keep your releases as controlled as a cat stalking its prey.

Why teams choose Split.io​

• Strong focus on experimentation and feature observability
• Instant Feature Impact Detection (IFID) to spot issues during rollouts
• Advanced user targeting, gradual rollouts, and dynamic configuration
• 40+ integrations across development, monitoring, and infrastructure

Pricing​

• Free trial available
• Team plan: $33/user/month (min. 10 users)
• Business plan: $60/user/month (min. 10 users) with full experimentation features
• Enterprise: Custom quotes for advanced capabilities and premium support

Best for you if: you’re an enterprise already using Harness or planning to consolidate tools.

Less ideal if: you want flat, non-seat-based pricing.

4. Unleash - Open-Source Flags with Enterprise-Ready Governance​

Unleash is a fully open-source platform that lets you deploy feature flags wherever you prefer: on-prem, in your own cloud, or even on that Raspberry Pi you keep meaning to repurpose. It’s ideal for teams who value freedom and control, much like a cat who insists on managing its own schedule.

Why teams choose Unleash​

• Open-source with a large, mature community
• Flexible deployment: self‑host, private cloud, or Unleash‑hosted SaaS
• Detailed audit trails and role-based access for compliance
• Gradual rollout strategies for custom targeting
• Real-time feedback and instant rollbacks
• Huge SDK library (official and community-supported)

Pricing​

• Self-hosted plan: Free forever, includes all core features and unlimited flags
• Managed (SaaS): Paid plans scale by usage, number of environments, and enterprise features (SSO, SLAs, etc.)

Best for you if: you want open‑source control, strong compliance, and flexibility to run Unleash anywhere.

Less ideal if: you need built‑in experimentation & analytics in one product.

In the self-hosted open-source (OSS) version, there’s no SSO, SCIM, or Role-Based Access Control (RBAC) either.

5. PostHog - The All-in-One Analytics and Feature Flag Platform​

PostHog is the Swiss Army knife of product teams: feature flags, product analytics, A/B testing, session replay, and user surveys, all in a single open-source platform. Self-host or go cloud and enjoy unlimited flags in the OSS edition. It’s the perfect mix of hedgehog precision and cat-like curiosity for understanding what your users really do.

Why teams like PostHog​

• Self-hosted OSS or Cloud with generous free tier
• Feature flags tightly integrated with analytics and experiments
• Session replay & surveys beside flags
• Integrates with your data warehouse

Pricing​

• Open‑source (self‑hosted): Free forever, unlimited feature flags, but A/B testing is not available in the OSS edition
• Cloud: starts at $0/mo with 1M events/month, then pay‑as‑you‑go pricing for additional events and features (replay, advance analytics, etc.).

Best for you if: you want an all‑in‑one solution combining feature flags, analytics, and user insights in one place.

Less ideal if: you only need lightweight flagging without the overhead of of a big analytics suite.

Also, the free self-hosted OSS version doesn’t include features like SAML/SSO, RBAC, account management, or audit logs. It's not optimized for scaling to very high event volumes. PostHog recommends paid cloud plans if you need to handle more events.

6. Statsig - Unified Experimentation, Feature Flags, and Analytics​

Statsig (now part of OpenAI) is for the analytics-obsessed: tons of flags, tons of experiments, tons of data. Plus, it offers both hosted and “warehouse-native” deployments, so you can choose where your data lives. In September 2025, OpenAI announced a $1.1B acquisition of Statsig, with Statsig operating under OpenAI’s Applications division, tracking insights with the intensity of a cat watching a laser pointer.

Why teams like Statsig​

• Unlimited free feature flags across tiers
• Built-in A/B and multivariate testing, guardrail metrics, dashboards
• No per-seat pricing – pricing is based on events & session replays, with unlimited seats and flags
• Warehouse Native mode: run experiment analysis directly in your data warehouse (Snowflake, BigQuery, Redshift, Databricks, etc.)

Pricing​

• Free: Unlimited flags, 2M monthly events, 50k session replays, basic analytics
• Paid plans: Usage‑based pricing that scales with events, premium features, and support

Best for you if: you want a deeply integrated experimentation + feature management solution and advanced analytics out of the box.

Less ideal if: you’re wary of long-term dependence on a vendor now embedded within a large AI company.

7. GrowthBook - Open-Source & Warehouse-Native Experiments​

GrowthBook is open-source and “warehouse-native” built for teams that want to keep their experiment data where they already keep everything else. If thinking in SQL comes as naturally to you as napping does to a cat, GrowthBook will feel like a perfect fit.

Why teams like GrowthBook​

• Open-source core with self-hosted and cloud options
• Experimentation suite: A/B, multivariate, and retroactive analysis
• Warehouse-native: plug directly into Snowflake, BigQuery, Redshift, and more
• Visual experiment editor and results dashboard
• OpenFeature providers available for multiple languages

Pricing​

• Open-source: Free forever, unlimited flags and experiments, self‑hosted
• Cloud: Free tier with usage limits, paid plans for higher traffic, SSO, and enterprise features
• Custom enterprise plans available for strict compliance and SLAs

Best for you if: you want to keep all experiment data in your own warehouse, value open‑source control, and need robust statistical analysis.

Less ideal if: you just want a lightweight flagging tool without experimentation, or you prefer a pure plug‑and‑play SaaS solution.

Similar to other open-source feature flag tools, If you self-host the open-source version, you’ll miss features like SSO/SAML, Prerequisite Flags, and Advanced RBAC Permissioning.

8. DevCycle - OpenFeature-Native, Edge-First Feature Management​

DevCycle is built for developers who live and breathe automation, GitHub, and Jira. If your pipeline chain is longer than a cat’s list of hiding spots, DevCycle has a flag for every step.

Why teams like DevCycle​

• OpenFeature-native platform with first-class OpenFeature integrations
• Integrates easily with GitHub, Jira, Datadog, and more
• Edge Flags & EdgeDB for low-latency, globally replicated flag decisions
• Supports automated workflows for CI/CD pipelines

Pricing​

• Free: unlimited seats, up to 1,000 client-side MAUs, ideal for small projects or trials
• Paid plans: usage‑based pricing scales with flag evaluations, includes advanced features like SSO, custom roles, and priority support
• Enterprise options available with SLAs, SOC2 compliance, and dedicated onboarding

Best for you if: your team is heavily invested in modern DevOps tooling and wants feature flags that plug directly into automated pipelines.

Less ideal if: you want open-source server components (DevCycle focuses on OpenFeature + open SDKs rather than fully OSS backend).

Quick Comparison Table (LaunchDarkly Alternatives at a Glance)​

Here’s how the top LaunchDarkly alternatives compare across pricing, experimentation, and ecosystem. This table is the best place to start if you want to compare LaunchDarkly competitors.

Final Thoughts​

Whichever LaunchDarkly alternative you choose, the right feature flag tool will help you ship faster and sleep better. At ConfigCat, we believe in transparent pricing, zero data collection, and making life easier for development teams. Plus, we’ll never charge you extra for inviting more teammates.

If you made it this far, you deserve a break! Go pet a cat, take a walk, or try toggling a feature on (or off) just for fun. If you’re ready to see how simple (and fun) feature flagging can be, give ConfigCat’s Forever Free plan a try and let your next release be purr-fectly smooth.

You can stay up-to-date with ConfigCat on Facebook, X, GitHub, and LinkedIn.

This guide shows you how to use feature flags in Flutter (Dart) with ConfigCat, focusing on best practices, manual polling, offline support, and real-world examples.

Why Use Feature Flags in Flutter Apps?​

Feature flags (also called feature toggles) are a best practice for Flutter app development. They help you:

• Test in production safely by targeting specific users while others see the existing version.
• Turn off features remotely, without resubmitting your app for review.
• Roll out features gradually to monitor performance and stability.
• Decouple release from deployment, giving your team more control over what users see.

These benefits are especially useful in mobile development, where deployment cycles can be slow and risky.

I'm sure you can agree that these benefits are worthwhile, especially when working with an evolving product.

How ConfigCat Fetches Flags: Polling Modes Explained​

In ConfigCat, polling refers to how your app fetches the latest feature flag values from ConfigCat's servers.

There are three main polling modes:

• Auto Polling: Fetches flags periodically in the background.
• Lazy Loading: Fetches only when you ask for a flag, with optional caching.
• Manual Polling: You control exactly when the flags are fetched.

Why Mobile Developers Prefer Manual Polling​

Manual polling gives mobile apps full control over when network calls are made. This is important because:

• Mobile apps have startup performance concerns
• You don't always want to fetch data unless necessary (e.g., poor connectivity)
• You want to minimize battery and network usage

Let's now look at an example of how to implement Manual Polling.

Setting up ConfigCat with Manual Polling in Flutter​

Here's a realistic example: you're building a weather app, and you've developed a new radar map feature that you want to release only to beta testers. Here's how you can do it:

Step 1: Add Dependencies​

The first is the ConfigCat client dependency. I'll use shared_preferences for caching (explained soon).

dependencies:
  configcat_client: ^2.1.0
  shared_preferences: ^2.2.0

Step 2: Initialize ConfigCat with Manual Polling​

import 'package:configcat_client/configcat_client.dart';

final client = ConfigCatClient.get(
 sdkKey: 'YOUR-CONFIGCAT-SDK-KEY', //FOUND IN YOUR CONFIGCAT ACCOUNT
 options: ConfigCatOptions(
 pollMode: PollMode.manualPoll(),
 ),
);

Step 3: Fetch Flags Using forceRefresh() at App Startup​

So far, I've set up manual polling, but I also need to tell ConfigCat to fetch the latest flags when the app launches by calling the forceRefresh() method on the client.

await client.forceRefresh();

Then, use the flag value:

bool isRadarMapEnabled = await client.getValue(
  'radar_map_feature_enabled',
  false,
);

if (isRadarMapEnabled) {
  // Show new feature
} else {
  // Fallback UI
}

Making Feature Flags Persistent in Flutter Using SharedPreferences​

By default, ConfigCat stores flag values in memory. That means values are lost when the app restarts. This isn't ideal for mobile apps, which are frequently closed and reopened.

Let's fix that with SharedPreferences.

Step 1: Create a Simple Cache Helper​

import 'package:shared_preferences/shared_preferences.dart';

class ConfigCatCache {
  static const String _cacheKey = 'configcat_cached_flags';

  static Future<void> save(String data) async {
    final prefs = await SharedPreferences.getInstance();
    await prefs.setString(_cacheKey, data);
 }

  static Future<String?> load() async {
    final prefs = await SharedPreferences.getInstance();
    return prefs.getString(_cacheKey);
 }
}