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.
To learn more about syncing flag settings across environments, read Syncing flag settings across environments.
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