General

Getting Started

  • How do I get started with LaunchDarkly?

    Check out our Getting Started Checklist to get the most out of LaunchDarkly.

    After you create a LaunchDarkly account, you will have access to our Quickstart.  The Quickstart will walk you through the creation of your first feature flag using any of our SDKs.  You can use our Hello World sample app or create a sample feature flag in your own test environment.

About LaunchDarkly

  • Can non-developers on my team use LaunchDarkly?

    Yes! While you will need a developer to integrate LaunchDarkly into your application, our dashboard allows non-technical team members to see how features are performing and toggle features without the need to rely on engineering. We strongly recommend you work closely with your developers to make sure that everything works appropriately.

  • What is LaunchDarkly?

    LaunchDarkly is a continuous delivery and feature flag management platform built for teams. The platform allows companies to continuously deliver and deploy software to their users in a faster, more reliable way. You wrap your features in LaunchDarkly flags, which allows you to have full control over who sees the feature (users or user groups). It helps companies perform gradual feature rollouts, disable buggy features without redeploying, and reduce development costs with a more streamlined development cycle.

    Feature flags are a software development best practice of gating functionality. Functionality can be deployed “off”, then turned on via the feature flag, separate from deployment. With feature flags, you can manage the entire lifecycle of a feature.

  • Why should I use LaunchDarkly?

    LaunchDarkly revolutionizes software development by allowing you to iterate quickly and safely. We allow you to easily flag your features, which enables you to manage them from the LaunchDarkly dashboard.

    • Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
    • Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
    • Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
    • Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.
  • Is it easy to set up and integrate?

    Yes! We’ve made LaunchDarkly extremely developer-friendly and easy to integrate. You and your team can start controlling your first feature in minutes. We also provide excellent customer support to help you get started.

    See our getting started guide.

  • Is it fast and reliable?

    Our unique streaming architecture ensures that feature flags are updated instantly, without introducing any latency to your site. LaunchDarkly’s performance is even faster than storing feature flags in your own database. We also have multiple layers of redundancy. All flags are served locally and are backed up by two layers of globally distributed CDNs. With the architecture, a feature flag will always be available.

  • How do I schedule a demo or get more info?

    Complete this form to schedule a free demo and we will be happy to demonstrate the platform and answer all your questions. Our feature flag platform is built to support both small and large development teams with enterprise-grade speed and reliability.

See all 8 articles

Feature Flags

  • What can I do with feature flags?

    LaunchDarkly provides an intuitive dashboard that lets developers wrap features or application behavior in our feature flags. You can then manage your features on the LaunchDarkly dashboard, roll out to users, and see how well things are performing.

    Feature flags are a software development best practice of gating functionality. Functionality can be deployed “off”, then turned on via the feature flag, separate from deployment. With feature flags, you can manage the entire lifecycle of a feature.

    Feature flags (or feature toggles) are meant to complement features branching and distributed version control systems. One of the primary benefits of features flags is the ability to separate feature lifecycle management from code deployment. Using a robust / access-controlled user interface, non-technical users can observe feature performance and analytics, perform A/B testing, set and manage goals, and have full visibility into feature performance.

     
  • Do you support both web and mobile feature flags?

    Yes!  We provide well-documented web and mobile SDKs for Java, JavaScript, PHP, Python, Go, Node.JS, .NET, Ruby, Python Twisted, iOS, and Android.  You can easily sync features across multiple platforms by using our SDKs throughout your stack.

    Here is an article detailing the use case of syncing web and mobile user experiences.

    View our SDKs

  • How does it work?

    LaunchDarkly lets developers wrap features or application behavior in our feature flags. You can then manage your features on the LaunchDarkly dashboard, roll out to users, and see how well things are performing. LaunchDarkly gives you total control of your application.

    • Turn features on and off for your users without waiting for engineering.
    • Roll out to percentages of your population, segments, or whatever rules you define.
    • Get faster feedback from the people you want. Measure the impact of your features with our NewRelic and Optimizely integrations.
    • Create custom rules for granular targeting
    • Manage configurations using our multivariate feature flags
  • What are boolean and multivariate feature flags?

    LaunchDarkly supports both boolean and multivariate feature flags. A boolean flag has two variations true and false, which works best for feature flags that will simply turn things on and off. A multivariate flag allows you to define two or more custom variations. These variations can be strings, numbers, JSON objects, or JSON arrays. Check out the docs.

Features

Product Features

  • User Targeting

    LaunchDarkly targeting lets you turn features on or off for individual users or groups of users. You can use the Targeting tab to roll features out for internal testing, private betas, or usability tests before performing a broader rollout. You can create your own rules to target who you want, when you want!

  • Controlled and percentage rollouts

    The Targeting tab allows you to roll a feature out to a percentage of your user base. For example, you can roll a feature out to 1% of users, then gradually scale up to 100% as confidence in the feature increases. LaunchDarkly’s rollouts ensure that a user will always see the same version of a feature until the rollout changes. Top tech companies have termed this a canary release – exposing features to some subset of users (whether it be opt-in, random rollout, or specific segments) is now used to describe what was once a beta.

    • Microsoft: In development of Windows 10, Microsoft used “canary” releases to test with internal users within Microsoft. Gabe Aul, who leads the Data & Fundamentals Team in the Operating Systems Group (OSG), said “our Canary ring probably sees 2X-3X as many builds as OSG because we catch problems in Canary and don’t push to OSG.”
    • Instagram: “Using ‘canary’ releases, updates go out to a subset of users at first, limiting the ability of buggy software to do damage.” Mike Krieger, Instagram co-founder and CTO, said he uses canary releases because “If stuff blows up it affects a very small percentage of people”.
    • Google: For Chrome, Google offers Chrome Canary, which it labels with “Get on the bleeding edge of the web, Google Chrome Canary has the newest of the new Chrome features. Be forewarned: it’s designed for developers and early adopters, and can sometimes break down completely.”

    Percentage and Controlled Rollouts – Consistent Hashing

    To decide which variation to show to a user, you pass us a unique identifier for that user (like a primary key or UUID) that would be consistent throughout your system. Now, when you request a flag that has a percentage rollout, say 20%, we take that key and hash it to a number between 0 and 100. This is a deterministic, consistent hash, so that user will always be bucketed that way across all your nodes.

  • Custom targeting rules

    In addition to targeting individual users, LaunchDarkly allows you to target segments of users by constructing custom rules.In other words, you can create custom rules to target users based on any attributes you send us.

    Each rule has three parts: an attribute, an operator, and a user value.   You can create as many custom targeting rules as you want for each feature flag and even perform percentage rollouts for each rule.

    All users that have not been individually targeted or who are not targeted by a custom rule will be evaluated by the default rule.

    Learn more

  • Flag management dashboard

    LaunchDarkly provides you with a centralized dashboard to manage the lifecycle of your features from local development, to QA, to production. Manage multiple different software projects with their own development environments.

  • Projects and environments to manage your development process

    Projects allow you to manage multiple different software projects under one LaunchDarkly account. For example, you can create one project called Mobile App and another project called Web App. Each project will have its own unique set of environments and feature flags. By default, all team members in your LaunchDarkly account will have access to every project within that account.

    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 SDK key, which is used to connect a LaunchDarkly SDK to a specific environment.

    Each feature flag that you create has its own unique set of targeting rules for 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.

  • Dev console to see real-time feature flag events

    The dev console helps you test whether you've set up LaunchDarkly correctly. From the console, you can see your users' feature flag requests and events in real-time.

    You can access the dev console from the sidebar. The filter buttons allow you to isolate specific events (like clicks or pageviews) or pinpoint errors and warnings, which represent problems with the data being sent to LaunchDarkly.

    The dev console must be the active tab in its browser window. You can have a second window open with your application, if you need to click around in your app in order to generate events.

    Please note that in high-volume environments, the events sent to the dev console may be sampled. When this happens, you will see a subset of events on the dev console, instead of every event.

    Read more

See all 12 articles

Use Cases

  • Enterprise Feature Flag Management

    LaunchDarkly provides on-premise and private solutions for our enterprise plans.

    This LaunchDarkly blog article explaining the requirements for managing feature flags at an enterprise scale.

  • Feature Flag Driven Development

    Feature flags/toggles/controls harness the power of test-driven development (TDD).   This is the process of releasing and iterating features quickly, testing those features, and making improvements.  Think of it as Lean UX methodology.  You release light features to receive market feedback.  You iterate on that feedback, make improvements, and redeploy.

    Think of feature flag-driven development as a way to receive iterative market feedback on your product, rather than solely depend on isolated customer feedback.  It’s a way to test how your features perform in the real world and not just in an artificial test environment.

    Read the full article

     
  • Mitigating deployment risk

    Using LaunchDarkly’s feature flags, you can separate feature rollout from code deployment, allowing you to slowly rollout a feature to a small percentage or subset of users in what is often referred to as a “canary release.” Canary launches allow you to quickly identify issues that might impact your entire user base, roll back easily to a known good version, and fix the issues in a controlled environment. The net result is a better product for all.

    Canary releases, also called “soft launches,” give you the confidence to deploy. By giving you the control to roll out a feature and pull it back with minimum public attention, you can release something risky with the least possible fanfare.

    You can also perform these types of releases during regular business hours. Gone is the Saturday 3 am deploy to ensure you disrupt as few users as possible. That is the power of feature flags. With LaunchDarkly, you can deploy a feature to 1% of your users on a Friday afternoon, wrapped in a feature flag. If something bad happens, it’s no problem. You can just flip the switch and the feature would be rolled back with only 1% of your users experiencing a few seconds of inconvenience.

    In summary, with a completely scalable platform like LaunchDarkly, you can easily roll out features, see the reaction on your users, and either continue rollout or completely shut off.

    See the use case page

  • Creating a feedback loop with LaunchDarkly
    Customers use LaunchDarkly to deploy a new feature to a small subset of their users. The platforms lets you easily segment users. For example, you can:

     

    • Rollout to a percentage of total users
    • Create a beta group of hand-picked users
    • Give early access to a single VIP customer
    • Dogfood to internal users only
    • Create an “opt-in” allowing users to self-select to see new features
    Once you’ve rolled out the feature to a group, measure it to see if the feature has impacted behavior as you expected and use that feedback to inform your path. Fix issues and make changes as necessary then continue to rollout incrementally to the entire base.
     
  • Empowering team collaboration and non-technical users
    LaunchDarkly allows teams to develop software in a way that’s fundamentally healthier, removing friction from the Product and Engineering relationship. The results are a dramatic savings in time and focus as well as faster delivery with greater trust.
     
    Empowered product development means that both technical and non-technical team members can collaborate on software releases. Because feature rollout will be decoupled from code deployment, team members outside of Engineering would be able to control the visibility of particular features without compromising the app’s integrity. Product and QA teams are empowered to make changes to feature visibility without consuming engineering resources.
     
    LaunchDarkly offers end to end feature flag management to allow an entire product development organization to control who gets the right feature, when.

     

    • Facilitate coordination between Engineering and Product, allowing you to break up larger features into smaller deployments and release features faster to select customers
    • Give control to the Product team, taking the burden of re-deploying off of engineering
    • Reduce friction between teams, cultivating a healthier and more productive relationship
  • Feature flag management at scale

    LaunchDarkly allows teams to develop software in a way that’s fundamentally healthier, removing friction from the Product and Engineering relationship. The results are a dramatic savings in time and focus as well as faster delivery with greater trust.

    Empowered product development means that both technical and non-technical team members can collaborate on software releases. Because feature rollout will be decoupled from code deployment, team members outside of Engineering would be able to control the visibility of particular features without compromising the app’s integrity. Product and QA teams are empowered to make changes to feature visibility without consuming engineering resources.

    LaunchDarkly offers end to end feature flag management to allow an entire product development organization to control who gets the right feature, when.

    • Facilitate coordination between Engineering and Product, allowing you to break up larger features into smaller deployments and release features faster to select customers
    • Give control to the Product team, taking the burden of re-deploying off of engineering
    • Reduce friction between teams, cultivating a healthier and more productive relationship

    See the use case page

See all 8 articles

Developers

Performance, Speed, and Reliability

  • What happens if LaunchDarkly goes down?

    Outages happen, but LaunchDarkly uses a CDN to continue serving your feature flags uninterrupted in case something goes wrong with our backend servers. Even if the CDN goes down (we use Fastly, a widely-used CDN provider), your servers will continue operating with the last set of feature flag rules, so your customers will continue seeing the right set of features.

     
  • Do you make a remote call every time a feature flag is requested?

    LaunchDarkly uses a novel streaming architecture to serve feature flags without making remote requests. We use server-sent events (SSE), a protocol for one-way real-time messaging, to send messages to your servers whenever you change the feature flag rules on your dashboard. SSE is widely used for server-to-browser messaging, but it works equally well for server-to-server communication. The SSE connection is all handled under the hood by our SDKs.

     
  • How do you ensure no latency?

    Our unique streaming architecture ensures that feature flags are updated instantly, without introducing any latency to your site. LaunchDarkly’s performance is even faster than storing feature flags in your own database. We also have multiple layers of redundancy to ensure your users always receive a flag.

     
  • Do I need to modify my firewall to use LaunchDarkly?

    In most cases no— our streaming connection only requires that your server be able to make an outbound HTTPS connection to *.launchdarkly.com.

  • What’s the overhead of a feature flag request?

    Almost nothing. LaunchDarkly’s SDKs use a streaming connection to asynchronously receive updates to your feature flag rules. Your actual feature flag requests are served from memory (or a Redis store, if you configure one). This adds less than 1 millisecond of latency to your page loads— about as fast as looking up a value in a hash table.

  • Do you support Redis caching?

    Yes, we support Redis caching. Our SDKs can be configured to use Redis as a persistent store, so even if an initial connection to LaunchDarkly fails, the last flag configurations will be used instead of the fallbacks.  For example, in Java, you can configure a Redis store like this: http://launchdarkly.github.io/java-client/com/launchdarkly/client/RedisFeatureStore.html

    You can also use the LaunchDarkly Relay to handle feature updates, offloading that responsibility from the SDKs running in your servers.

See all 9 articles

How It Works

  • Do you have a REST API?

    Yes! All of our SDKs are built on top of the LaunchDarkly REST API. In fact, the entire LaunchDarkly web site is driven via the same API, so it’s heavily tested and complete. If you want to build a custom integration, export your data, or want to use LaunchDarkly on a platform that we don’t currently support, this API reference is the place to start.

  • How do I add, remove, and manage my users in LaunchDarkly?

    You don’t have to send users to LaunchDarkly in advance – just set up your users in variation calls and you’re all set: http://docs.launchdarkly.com/docs/getting-started .

    If we do not receive a request for a user in 30 days, then that user will no longer appear in the dashboard, but will still be stored in the database.   If we detect that the user is active again, then they will reappear in the dashboard with the latest set of attributes.  You cannot remove users manually from the dashboard.

    You may add individual users using the LaunchDarkly dashboard by navigating to a feature flag and adding users manually in the targeting tab.

  • What is the default rule?

    The default rule is a final rollout rule for any users that don’t match any of the previous sections on the Targeting tab, like individual targeting or custom rules.

    As with other rules, you can choose to serve a specific variation, or apply a percentage rollout to any remaining users.

    For simple percentage rollouts, you can just use the default rule for a feature flag.  For example, to roll out the true variation to 50% of your users, set the default rollout rule to true 50% and false 50%.

     
  • How do you calculate confidence interval for A/B tests?

    We use a z-score.

  • What are custom user attributes?

    Custom attributes let you turn features on or off for specific users or groups of users based on any data that you send to us. In JSON, custom attributes are stored in a custom sub-object, like this:

    {
       "user":"foo@example.com",
       "custom":{
          "groups":[
             "google",
             "microsoft"
          ]
       }
    }
    
     
  • Do I need to call identify for every user?

    No– you don’t have to call identify on users in advance. You can pass new users to variation and we’ll automatically handle adding them to LaunchDarkly.

See all 16 articles

Troubleshooting

Application

  • How do I connect to my team’s LaunchDarkly account?

    If your team already has a LaunchDarkly account, the owner of that account must send you an email invitation to join the team. Once you receive the invitation, follow the sign up instructions and you will be automatically added to your team’s account.

    If you have an existing LaunchDarkly account and want to use that email address to join your team, please take the following steps:

    • Log in to your existing LaunchDarkly account
    • Navigate to Account Settings to access your Profile Page
    • Change your email to something different (e.g. if your email is bob@company.com, you may change it to bob+donotuse@company.com)
    • You should now be able to accept the invitation from your team owner using your preferred email
     
  • Why are all my users seeing the same variant of my flag?

    Make sure that you’re sending distinct user keys for each user in your variation calls. A few other possibilities:

    • Your default rollout rule is serving a single variation
    • Your users are receiving the fallback variation because something is not working correctly
    • The kill switch was activated, and the feature is set to ‘Off’
  • How do you sync between environments? Can it be automated?

    We don’t have a “promote from environment A to B” workflow built into the tool yet, though that is coming. In the meantime, we have a script available that you can use to automate the process: https://github.com/launchdarkly/sync-ld-flags

  • The click goal editor cannot load my page

    The editor is failing to load your site through an <iframe> because of security restrictions. To ensure our editor works, add X-Frame-Options: ALLOW-FROM https://app.launchdarkly.com and Content-Security-Policy: frame-ancestors 'self' https://app.launchdarkly.com to the response headers of your site; alternatively remove the headers if you don’t need to restrict embedding of your site using an <iframe>.

    Note that Chrome and Safari do not respect the ALLOW-FROM directive. Also, Internet Explorer does not currently support Content-Security-Policy with frame-ancestors.

     
  • Feature flag updates did not take effect immediately

    If you have streaming disabled (only recommended for our PHP SDK), changes on the dashboard will be seen by clients after a delay dictated by the feature’s TTL. Our recommendation is to use a 5 minute TTL in production. All changes to a feature including rollout, targeting, and the kill switch respect the TTL.

    If you’re using our iOS SDK, we enforce a minimum TTL of 1 minute. Even if your TTL is set to 0, you’ll need to wait 1 minute for changes to be reflected in your mobile clients.

     
  • I am having trouble logging in to my LaunchDarkly account

    Password Help

    • If you have forgotten your password, simply click the “Forgot Your Password?” link on the login page.

    Multi-Factor Authentication (MFA)

    • If you are prompted to enter your MFA verification passcode, use the authenticator app on your mobile device to enter the six-digit code.
    • If you have forgotten your recovery code or you cannot access your phone, ask the administrator of your LaunchDarkly account to send you a recovery email.
    • Documentation
     

SDKs

  • Does the LD SDK support Postgres as a caching backend?

    Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres.

  • I am getting a JSON parsing exception with the Java client

    Exception:

    Json parsing exception: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was….ExceptionType: com.google.gson.JsonSyntaxException

    Make sure your build tool is bringing in the proper version of Gson. The LaunchDarkly SDK may have problems with versions earlier than 2.2.4. To enforce the proper version add this dependency:

    1. <dependency>
    2.  <groupId>com.google.code.gson</groupId>
    3.  <artifactId>gson</artifactId>
    4.  <version>2.2.4</version>
    5. </dependency>

     

  • I am getting SSL exceptions when calling variation() in the Java client

    Make sure your build tool is bringing in the proper version of the Apache http client. The LaunchDarkly SDK may have problems with versions earlier than 3.3.6. To enforce the proper version add this dependency:

    1. <dependency>
    2.  <groupId>org.apache.httpcomponents</groupId>
    3.  <artifactId>httpclient</artifactId>
    4.  <version>4.3.6</version>
    5. </dependency>
  • Every time I call get_flag, a remote call is made.

    One possibility is that you have streaming mode disabled and your feature’s TTL is set to 0. We do not recommend disabling streaming unless you are using PHP. If you do disable streaming mode, we recommend setting the TTL to 5 minutes in production environments.

    If you’re using PHP, you may need to configure a custom HTTP cache provider as described in the PHP SDK Reference. PHP’s shared-nothing architecture means that the in-memory HTTP cache will be reset on every request, which means that almost every flag request will require a remote call. Using a Memcache or Redis-backed cache is the best solution.

     

Mobile

  • How do the mobile SDKs handle airplane/flight mode?

    When a user is in flight or airplane mode on their mobile device, LaunchDarkly will use the latest stored flag settings.  When the user reconnects to a network, LaunchDarkly will reconnect to the stream to see if there are any new flag updates.  This ensures that your users will always receive the most up-to-date flag settings, even if their devices are not currently connected to a network.

     
  • I’m seeing inconsistencies while testing the iOS SDK

    There are a few things to be aware of with the iOS SDK:

    • When an app is first installed, until the first response is received back from LD, the default variation values will be used. There is a delegate pattern (see userDidUpdate) that can be used to block until the first response is received.
    • The iOS SDK polls for changes based on the TTL set in your environment settings (https://app.launchdarkly.com/settings#/projects). Unlike our other SDKs, a minimum TTL of 1 minute is enforced. So if your TTL setting is 0, changes will still take 1 minute to propagate to your mobile client
    • If your app has a login flow, or you need to change to a brand new user context for any reason, you should use the userDidUpdatedelegate to wait until the feature flags for the new user have been received. Once the user context has been seen at least once, it is cached on the device.
    • If you change environments during testing (say by changing your API key from a test key to a production key), you should clear the device cache.
  • Why is there a different mobile environment SDK key?

    The server SDK keys are intended to be embedded in trusted environments. The mobile SDK keys are suitable for use in (untrusted) mobile clients. If a mobile user were to somehow decompile your app, or gain access to your mobile key, there is really no impact, as those keys can only access a restricted subset of our APIs that do not reveal any private data.