A deployment goes live at 2:00 PM. By 2:05 PM, CPU usage spikes to 95% because of a slow database query in a new beta feature. If you rely on environment variables, resolving this requires changing a configuration file. You must commit the change, push to your repository, and wait for a 10-minute CI/CD pipeline to rebuild and redeploy the container. During those ten minutes, your users experience errors. If you use a feature flag, you toggle a switch in a UI or run a quick CLI command. The feature turns off instantly.
Env vars vs. feature flags: Where to draw the line
Environment variables (env vars) work well for static configuration. They define your application's environment—database connection strings, third-party API keys, and port numbers. These values rarely change. When they do change, a full application restart or redeploy is acceptable.
Feature flags solve a different problem. They manage runtime behavior. You use feature flags when you want to change how your application behaves without rebuilding your code or restarting your servers.
The inflection point where env vars fail is targeting. If you want to show a new payment gateway only to 5% of users in Canada, env vars cannot help you. They apply globally to the entire process. Feature flags evaluate context—such as user IDs, geographic locations, or email domains—at runtime to make dynamic decisions.
Use env vars for build-time configuration—use feature flags when you need to alter runtime behavior dynamically without redeploying code.
The roll-your-own approach: Simple, cheap, but limited
Many engineering teams start by building their own flag system. It is easy to set up a basic key-value store in Redis or add a features table to your PostgreSQL database.
For example, let us look at a basic Node.js implementation using Redis:
// Illustrative example of a homegrown flag check
async function isFeatureEnabled(userId, featureName) {
const flagValue = await redis.get(`flag:${featureName}`);
if (flagValue === 'true') return true;
if (flagValue === 'false') return false;
// Simple percentage rollout logic (e.g., flagValue = "20")
const hash = getSimpleHash(userId); // returns an illustrative number between 0 and 99
const rolloutPercentage = parseInt(flagValue, 10);
return hash < rolloutPercentage;
}
In this illustrative example, if the Redis key flag:new-checkout is set to 20, only 20% of users see the new checkout. This works well initially. It has zero external dependencies and costs almost nothing to run.
However, the maintenance burden grows quickly. What happens when your product managers want to target only users who signed up before last Tuesday and use an enterprise email domain? Writing custom targeting rules in your application code becomes messy. You also have to build an administrative UI so non-technical stakeholders can toggle flags safely. Without audit logs, you will struggle to know who turned off a critical flag at 3:00 AM.
Building your own flag system works well for simple boolean toggles—but it quickly becomes a distraction when you need complex targeting or audit logs.
LaunchDarkly: Robust targeting and enterprise scale
LaunchDarkly is the market incumbent. It uses a real-time streaming architecture built on Server-Sent Events (SSE). When you update a flag in the LaunchDarkly dashboard, the change propagates to your servers and clients in milliseconds.
Its targeting engine is highly sophisticated. You can target users based on any custom attribute you pass to the SDK—such as subscription tier, device type, or historical usage. It also includes built-in experimentation tools for running A/B tests and multivariate rollouts.
The trade-off is cost. LaunchDarkly is a premium product with pricing that scales based on monthly active users (MAUs). For high-traffic consumer applications, this pricing model can become expensive. There is also the risk of vendor lock-in, as your codebase becomes deeply integrated with proprietary LaunchDarkly SDKs.
LaunchDarkly is ideal for large engineering organizations that require complex user targeting, real-time updates, and advanced experimentation.
Flagsmith: Open-source flexibility and self-hosting
Flagsmith offers a different approach. It is an open-source feature flag platform that you can run as a managed cloud service or self-host on your own infrastructure. You can deploy it using Docker, Kubernetes, or run it directly on AWS, GCP, or Azure.
This deployment flexibility is valuable for organizations with strict compliance requirements. If you cannot send user data to third-party servers, you can run Flagsmith entirely within your private network.
Flagsmith uses a straightforward API. Its feature set is slightly more streamlined than LaunchDarkly's—but it handles standard targeting, multivariate flags, and environment management well. Its pricing model is predictable, scaling with API calls or seat counts rather than strictly tracking every monthly active user.
Flagsmith is a strong choice if you require on-premises deployment, open-source transparency, or a more predictable pricing model.
How to choose: A comparison of trade-offs
Choosing between these options requires balancing operational overhead against control.
Consider how each option handles latency. If your application makes a network call to an external database or API every time it checks a flag, your page load times will suffer. To avoid this, both LaunchDarkly and Flagsmith use local evaluation. The SDKs download the flag ruleset when your application starts and cache it in memory. When a user requests a page, the SDK evaluates the flag locally in microseconds.
A custom database-backed system requires you to implement your own caching layer—like Redis—to avoid hammering your primary database with flag queries.
If you only need a few basic toggles for internal testing, building a simple system in-house is reasonable. If you have a growing product team that needs to run complex rollouts without engineering intervention, a dedicated tool is necessary.
Choose roll-your-own for basic internal toggles, Flagsmith for self-hosted control, and LaunchDarkly for managed, high-scale targeting.
Compare feature management tools on StackMatch
Selecting the right feature flag tool depends on your stack, budget, and compliance needs. You can explore more options on StackMatch, where we offer curated tool listings, side-by-side comparison tables, and editorial reviews scoring ease of use, pricing transparency, and integrations.
FAQs
When should I migrate from environment variables to a feature flag service?
You should migrate when you need to change application behavior at runtime without triggering a new CI/CD deployment pipeline—or when you need to target specific subsets of users based on custom attributes rather than applying changes globally.
Does using a third-party feature flag tool introduce latency to my application?
Most modern feature flag SDKs mitigate latency by using local evaluation. Flag rules are cached in memory on your servers and updated asynchronously via streaming connections—resulting in near-zero latency for flag checks.
Is Flagsmith a viable alternative to LaunchDarkly for small teams?
Yes, Flagsmith is a viable alternative—especially for teams that prefer open-source software, require self-hosting for compliance reasons, or want a simpler pricing structure that scales with API calls rather than monthly active users.
What are the hidden costs of building a custom feature flag system?
While the initial build is cheap, the hidden costs of a custom system lie in ongoing maintenance. You must build and secure an administrative UI for non-technical team members, implement audit logs, and ensure high availability for the flag delivery infrastructure.