Syncing flag settings across environments

Organizations often ask how to sync flag settings across environments. Before implementing a sync process, examine why you need to sync and whether alternative approaches better serve your use case.

Quick answers

Can I bulk sync flag settings between environments? No native bulk sync exists in the LaunchDarkly dashboard. You can compare and copy settings one flag at a time, or use the API for bulk operations.

Should I sync flag settings between environments? Rarely. Flag targeting rules typically serve different purposes in each environment. Syncing often indicates architecture decisions that create unnecessary overhead.

The reframe

Transform the question from “How do I sync environments?” to “Why am I syncing environments?”

Common reasons and better alternatives:

Why environments rarely need syncing

Progressive releases use different targeting strategies in each environment:

Preproduction environment:

• Target yourself: If user key equals "alice@example.com" then serve Available
• Target your team: If team equals "platform" then serve Available
• Enable for testing: If qa_tester is true then serve Available

Production environment:

• Target internal users: If email ends with "@example.com" then serve Available
• Target beta program: If beta_participant is true then serve Available
• Progressive rollout: Serve Available for 10% of users
• Full release: Serve Available for all users

These targeting rules serve different purposes. Syncing them defeats the purpose of progressive delivery.

When to use compare and copy

Compare and copy works well for specific scenarios:

Auditing operational flags

Verify operational flags have consistent configuration across environments:

• Feature flag kill switches
• Rate limiting thresholds
• Configuration values that should be uniform

To learn more, read Comparing and copying flag settings.

Verifying completed releases

After completing a release in production, verify the flag is also enabled in preproduction environments to maintain consistency for operational flags.

Copying base configuration

When creating a new flag, copy the initial structure from another environment, then customize targeting rules for the specific environment.

API-based sync workflows

For bulk operations, use the LaunchDarkly API or Terraform provider:

REST API

Use the REST API to copy flag configurations:

# Get flag configuration from source environment
curl -X GET https://app.launchdarkly.com/api/v2/flags/{projectKey}/{flagKey} \
  -H "Authorization: YOUR_API_KEY"

# Update target environment
curl -X PATCH https://app.launchdarkly.com/api/v2/flags/{projectKey}/{flagKey} \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"environments": {...}}'

Terraform provider

Manage flag configurations as code:

resource "launchdarkly_feature_flag_environment" "staging" {
  flag_id = launchdarkly_feature_flag.example.id
  env_key = "staging"
  
  targeting_enabled = true
  
  rules {
    clauses {
      attribute = "team"
      op        = "in"
      values    = ["platform"]
    }
  }
}

resource "launchdarkly_feature_flag_environment" "production" {
  flag_id = launchdarkly_feature_flag.example.id
  env_key = "production"
  
  targeting_enabled = true
  
  rules {
    clauses {
      attribute = "email"
      op        = "endsWith"
      values    = ["@example.com"]
    }
  }
}

To learn more, read LaunchDarkly Terraform provider.

Consolidating environments

If you frequently need to sync flag settings, consider consolidating environments:

Signs you should consolidate

You maintain identical targeting rules across multiple environments:

Example: qa1, qa2, and qa3 all have the same targeting rules with no meaningful differences.

Solution: Create one QA environment, pass qa_instance: "1" as a context attribute, create targeting rules when instances need different behavior.

You replicate flag states across ephemeral environments:

Example: Per-PR environments where each PR needs the same flag configuration.

Solution: Create one staging environment, pass pr_number: "1234" as a context attribute, target specific PRs when needed.

You sync production-released flags to all environments:

Example: After releasing a flag in production, you copy settings to all preproduction environments.

Solution: Use compare and copy for operational flags that need consistency. For release flags, accept that preproduction environments serve different purposes and don’t need production targeting rules.

To learn more about consolidating environments, read Environments.

Best practices

Follow these practices when managing flag settings across environments:

Design environment-specific targeting rules: Create targeting rules appropriate for each environment’s purpose rather than copying production rules to preproduction.

Use compare and copy sparingly: Reserve compare and copy for operational flags and completed releases, not for active progressive rollouts.

Consolidate environments when possible: Reduce the number of environments to minimize management overhead.

Use the API for legitimate bulk operations: When you need to sync operational flags or configuration values, automate with the API rather than manual dashboard operations.

Question the need to sync: Each time you reach for sync functionality, ask whether the targeting rules should actually differ between environments.

Related topics

• Environments: Guidance on how many environments to create
• Coordinating releases: Strategies for coordinating releases across applications
• Comparing and copying flag settings: LaunchDarkly documentation on native compare and copy functionality