LaunchDarkly Developer Documentation

Get started in under 30 minutes.
LaunchDarkly provides feature flags as a service for Java · Python · Ruby · Go · Node.js · PHP · .NET. Control feature launches -- who sees what and when -- without multiple code deploys. Easy dashboard for phased rollouts, targeting and segmenting.
Need more help? write us at support@launchdarkly.com

Get Started    Documentation

Environments

Environments allow you to manage your feature flags throughout your entire development lifecycle — from local development to QA, staging, and production.

When you first sign up, you're provided with two environments within a project. By default, they're named Test and Production. Each environment has its own private API key. Each feature flag that you create can have different rules in each environment. This means that you can change your flag rollout rules in a development or staging environment for QA testing before rolling out to production.

JavaScript snippets and environments

If you're using one of our client-side JavaScript snippets for front-end feature flags or A/B tests, note that the snippets we provide you are environment-specific. A best practice is to put the snippet in a template variable so you can easily change the snippet for each of your environments.

The LaunchDarkly sidebar has a dropdown widget that shows you the current environment and allows you to quickly switch between environments.

You can manage your environments from your Account settings page. You can add new environments here (for example, to give each developer on your team their own environment for local testing).

Each environment also has its own swatch color. The swatch color gives you a quick visual indication of which environment you're working on.

Each environment also has a time-to-live (TTL) setting. This sets the number of minutes that your SDK can cache feature flag rules locally.

TTL settings

We recommend setting your TTL to 2 minutes in production environments. This lets our SDKs cache feature flag rules for 2 minutes, so most calls to variation will not make a remote request. The tradeoff is that changes you make to your feature flag rules on your dashboard will not take effect for 2 minutes.

If your site has relatively low traffic (fewer than one request per minute), you may wish to increase the TTL to 5 minutes or more to take better advantage of the local cache.

If the TTL is set to 0 minutes, the SDK will not use a local cache, and every call to variation will make a remote request to our CDN. You can set your TTL to 0 in testing environments to see changes reflected immediately, but we do not recommend a 0 minute TTL in production.


Environments


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.