Environment-Based Feature Flags

Environment-Based Feature Flags

Environment-based flags let you enable features in development or staging without affecting production. This is essential for testing new features safely before they reach real users.

Configuration Example

{
  "new-search-algorithm": {
    "name": "New Search Algorithm",
    "description": "Elasticsearch-based search replacing SQL LIKE queries",
    "type": "boolean",
    "enabled": true,
    "defaultValue": false,
    "targeting": [
      {
        "type": "environment",
        "environment": "development"
      },
      {
        "type": "environment",
        "environment": "staging"
      }
    ]
  }
}

Multi-Environment Strategy

A typical environment promotion flow:

Development (always on)
    ↓
Staging (on for QA testing)
    ↓
Production (off, then gradual rollout)

LaunchDarkly Environments

LaunchDarkly natively supports per-environment flag states. Each environment has its own targeting rules:

{
  "environments": {
    "development": { "on": true, "fallthrough": { "variation": 0 } },
    "staging": { "on": true, "fallthrough": { "variation": 0 } },
    "production": { "on": false, "offVariation": 1 }
  }
}

Common Patterns

Pattern	Description
Dev-first	Enable in dev, promote to staging, then production
Production-only	Flag exists only to control production behavior
Environment-specific config	Different values per environment (e.g., API URLs)
Testing override	QA can enable any flag in staging for testing

Best Practices

• Never hardcode environment names; use your SDK's context/attribute system
• Consider having a "pre-production" environment for final validation
• Document which flags are expected to differ across environments
• Use flag dependencies to ensure prerequisite flags are also enabled