Environments
Key principle: Less is more. Most organizations need only 2-3 LaunchDarkly environments regardless of how many deployment environments they have.
Default recommendation
Start with these environments:
- Development: No approvals, rapid iteration
- Staging: Optional approvals, testing before production
- Production: Required approvals, critical environment
Use targeting rules with custom attributes to handle multiple deployment environments within each LaunchDarkly environment.
Why consolidate environments?
Each LaunchDarkly environment adds operational overhead:
- Maintain targeting rules across multiple environments
- Synchronize flag states manually
- Manage separate SDK credentials
- Review and approve changes in each environment
Consolidate deployment environments using targeting rules instead.
When to create separate environments
| Scenario | Create separate environment? | Solution |
|---|---|---|
| Per developer | No | Use individual user targeting or custom attributes |
| Per PR or branch | No | Pass PR number or branch name as custom attributes |
| Per tenant or customer | No | Use targeting rules with tenant context attributes |
| Per geographic region | No | Pass region as a custom attribute |
| Federal vs public cloud with compliance requirements | Yes | Compliance mandates complete isolation |
| Production vs development with different approval workflows | Yes | Different stakeholders and approval requirements |
| Different data residency requirements | Yes | Legal or regulatory requirements mandate separation |
Solutions for common scenarios
Per-developer testing
Instead of creating developer environments, use:
Individual user targeting: Create rules like If user equals "alice@example.com" then serve Available
Custom attributes: Pass developer, workstation, or branch_name as context attributes
Local overrides: Use SDK wrappers or test frameworks to mock flag values
Per-PR or ephemeral environments
Pass deployment metadata as custom attributes:
Context:
- pr_number: "1234"
- hostname: "pr-1234.staging.example.com"
- git_sha: "abc123"
Rule: If pr_number equals "1234" then serve Available
Multi-tenant deployments
Pass tenant information as context attributes:
Context:
- tenant_id: "acme"
- subscription_tier: "enterprise"
Rule: If tenant_id is one of ["acme", "initech"] then serve Available
Mapping process
Follow these steps:
- List deployment environments: Document where your application runs
- Group by compliance and approval requirements: Separate only when compliance mandates it or approval workflows differ significantly
- Define custom attributes: Document attributes needed to distinguish consolidated environments
- Mark production as critical: Enable required approvals and UI warnings
Mark production environments as critical to require approvals and prevent accidental changes. To learn more, read Critical environments.
Real-world examples
Multiple regions → Single production environment
You have: US-East, US-West, EU, APAC production deployments
Create: 1 Production environment
Pass context attribute: region: "eu"
Create rules when needed: If region equals "eu" then serve Available
Federal compliance → Separate environments
You have: Federal and Public clouds with different compliance requirements
Create: 2 environments (Federal, Public)
Why separate: Compliance mandates complete isolation
Within each: Use environment: "dev" attribute to distinguish dev/staging/prod deployments
Team-specific staging → Single staging environment
You have: Staging-TeamA, Staging-TeamB, Staging-TeamC
Create: 1 Staging environment
Pass context attribute: team: "team-a"
Create rules when needed: If team equals "team-a" then serve Available