Beyond Environment Variables: When to Use Feature Flags (and Why)
When talking to devs in the software development community about feature flags, a question that often comes up is, “Can’t I just use environment variables for that?” It's a fair question; both can influence how an app behaves. But under the hood, they serve very different purposes. Let's break it down.
What's an Environment Variable?
Environment variables are key-value pairs used to supply configuration values to your application. They typically live in your app’s runtime environment. You can set environment variables through the command line, CI/CD pipelines, or hosting platform settings using a config file.
Environment variables are commonly used in the following scenarios:
- Applying environment-specific data such as port numbers and database URLs.
- Keeping sensitive data such as API keys and credentials out of your source code.
- Changing software behavior based on environment (e.g., setting API rate limits in a production environment).
Simple, dependable, and great for bootstrapping config. But they have limits.
What's a Feature Flag?
A feature flag or feature toggle represents a boolean-type setting value that allows development teams and product managers to toggle features on or off. Feature flags allow you to separate deployments from feature releases. They are typically used in if-else statements to make features visible to an entire user base or, with precise targeting, to specific audiences and individual users.
Common feature flags use cases include:
- Progressive delivery (e.g., canary releases and staged rollouts)
- Trunk-based development
- Experimentation and marketing campaigns (e.g., A/B testing)
- Kill switches for cases where features are not working correctly
They are typically managed using a feature management platform like ConfigCat or LaunchDarkly, or via a homegrown solution if you have the time and resources.
Understanding the Differences
While feature flags and environment variables can both affect how applications behave, their similarities end there. Here are the factors that set them apart:
-
Redeployment: This is probably the biggest difference. Changing the value of an environment variable requires you to redeploy the application code or rebuild your app to reflect the changes. In contrast, when you toggle a feature flag, your app reflects the changes almost immediately without redeployment.
-
Targeting: Feature flags enable you to roll out features to specific subsets of users or user segments based on contextual data, such as country, email address, or device type. Environment variables, on the other hand, do not support user targeting and segmentation.
-
Values: Environment variable values can only be strings. While you can pass numbers and booleans as strings, you need to parse them in your app before use. Complex values, such as objects, must be stringified first. Feature flags, on the other hand, are traditionally boolean values, but modern systems also support strings, numbers, and even JSON objects.
Now that we’ve covered the differences, let’s look at the pros and cons of using feature flags and environment variables to modify application behavior.
Feature Flags vs. Environment Variables: Quick Comparison
| Feature | Environment Variables | Feature Flags |
|---|---|---|
| Does change require code deployment? | ✅ Yes | ❌ No |
| Supports targeting? | ❌ No | ✅ Yes |
| Value types | Strings only (must parse others) | Booleans, strings, numbers, JSON |
| Per-user control | ❌ Not possible | ✅ Easy to segment users |
| Frontend-safe? | ❌ Risky (can expose secrets) | ✅ With proper flag setup |
| Best for | Static config, secrets, bootstrapping | Dynamic features, rollouts, A/B tests |
Pros and Cons
In short, there are numerous benefits and drawbacks to using each, and it is crucial to make an informed decision about when to utilize each to align with best practices.
The pros of using environment variables are that they require no external tools and are language-agnostic. But the downsides are:
- Require redeployments
- No user segmentation
- Harder to manage at scale
- Only handle strings
On the other hand, feature flags have some downsides, such as making testing more complex and adding technical debt to your codebase if stale flags are not removed. However, they offer more benefits, such as:
- No redeployments needed
- Fine-grained control over rollouts
- Safer feature experimentation
What to Use When?
Use environment variables when:
- You need config only at startup
- You don't need to target users
- You're storing secrets or low-level infrastructure config
Use feature flags when:
- You want to enable/disable features instantly
- You are rolling out features to a subset of users
- You need flexibility and safety during releases
Bonus Tips
If you choose to use environment variables, check out OpenFeature's environment variable providers. They support booleans, numbers, strings, and objects, and provide a nice API for evaluating these values. If you opt to use OpenFeature to manage your ConfigCat feature flags, take a look at our OpenFeature guide.
And if you choose feature flags, you should:
- Have the culture and tooling in place to remove stale (zombie) flags.
- Give your feature flags descriptive names.
- Make your feature flags observable.
ConfigCat can help you with all of the above (except the team culture part 😅). ConfigCat provides zombie flag management, integrations for monitoring and analytics platforms, and many other features that allow you to use feature flags and remote configuration with ease. Get started with the generous forever free plan, or contact the team for a demo.
You can also check out ConfigCat on Facebook, X, LinkedIn, and GitHub.