Environment variables and feature flags often look similar because both can turn behavior on or off. The difference is when and how that decision changes.
An environment variable is usually read at process start. A feature flag is evaluated at runtime, with context about the user, environment, segment, or rollout percentage.
Use environment variables for static configuration
Database URLs, API base URLs, logging modes, and service credentials belong in environment variables. They describe how the service connects to its dependencies.
Changing them usually means a deploy, a restart, or an infrastructure change. That is fine for configuration, but too slow for release control.
Use feature flags for runtime decisions
A feature flag answers a product or operational question while the application is running. Should this user see the new checkout? Should this customer use the new billing path? Should this risky job pause immediately?
- Feature flags support gradual exposure.
- Feature flags can target users or segments.
- Feature flags can be killed without redeploying.
- Feature flags create an audit trail for release decisions.
The common failure mode
Teams often start with `ENABLE_NEW_CHECKOUT=true` because it is quick. A few weeks later, they need 5% rollout, internal-only access, emergency disable, and history. The environment variable has become a release system without release-system behavior.
A simple rule
If the value changes rarely and only during deployment, use an environment variable. If the value controls user exposure, operational risk, or production rollout, use a feature flag.
Related docs
Try ReleaseAnchor
Create a flag, connect an SDK, and ship your next rollout with a safe default.