General

Account

See all 7 articles

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

  • 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.

  • How do you calculate monthly active users?

    We calculate the number of unique users across all environments over your billing cycle. Anonymous users are tracked by session, so a single user who visits multiple times will only be counted once.

See all 7 articles

Feature Flags

  • Which order are flag targeting rules evaluated?

    Our targeting rules evaluate from top to bottom and take the first match. The first matching rule will take precedence over any of the rules that follow.

    Learn more about this in our documentation here.

  • What can I do with feature flags?

    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.

    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. Non-technical users can observe feature performance and analytics, perform A/B testing, set and manage goals, and have full visibility into feature performance.

     
  • 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

  • Setting up SSO via SAML 2.0

    LaunchDarkly supports the following SAML 2.0 identity providers:

    • Okta
    • OneLogin
    • Azure Active Directory
    • Google Apps
    • Active Directory Federation Services (ADFS)
    • PingIdentity
    • Centrify

    See our documentation for complete setup instructions as well as configuration tips for specific providers.

  • 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.

    Learn more about targeting users in our documentation here.

  • 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 about the dev console in our documentation.

See all 11 articles

Use Cases

  • How are A/B Test Results Calculated?


    When a conversion event comes in, we try to find the 'closest' feature event. To do this, we look for the latest feature event for this user in the 24 hours preceding the conversion event. (Failing that, we will look for the earliest feature event for that user in the 5 minutes following the conversion event, to allow for clock skew). Once we find a feature event, we look at which variation that user saw, and we add the user to the set of users who saw that variation and converted.

    So, suppose the following timeline:

    t0: user X sees variation A
    t1: user X sees variation B
    t2: user X triggers a conversion event

    As long as there is less than 24 hours between t2 and t1, user X will be added to the variation B conversion set (and *not* the variation A conversion set).

    In this same timeline, but when there is more than 24 hours between t2 and t1, we will not find a feature event, so the conversion will not count at all.

    Suppose an alternate timeline:

    t0: user Y sees variation A
    t1: user Y triggers a conversion event
    t2: user Y sees variation B
    t3: user Y triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Y will be counted in both the variation A conversion set *and* the variation B conversion set. 

    Now, suppose a third timeline:

    t0: user Z sees variation A
    t1: user Z triggers a conversion event
    t2: user Z sees variation A
    t3: user Z triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Z will be counted *once* in the variation A conversion set.

    Keep in mind that the important time limit here is 24 hours. If someone converts 5 days (or 2 days) after (or 2 days) getting a variation, they will not be counted.

    Contact us at support@launchdarkly.com if you have any additional questions.

  • Targeting user by semantic app version

    Targeting your users based in their application's semantic version is a great way to make sure you're getting the right features out to the right users. With LaunchDarkly, custom attributes may be leveraged to specify a ruleset expressive enough to define SemVer logic.

    Example

    Suppose we have a feature we want to release only to users that are on app version >= 2.1.0, and we come across a user running the latest version of our app, 2.2.3, in this case:

    user = {
    "key": "a00bea",
    "custom": {"majorVersion": 2, "minorVersion": 2, "patchVersion": 3}
    }

    By splitting our user's app version into three separate attributes, we can create a feature flag targeting rule targeting, which targets each version attribute separately:

    Screen_Shot_2017-12-04_at_3.58.41_PM.png

  • 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

     
  • 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.
     
    See the use case page
  • 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
  • A/B Testing with feature flags

    LaunchDarkly lets you create goals to measure the effectiveness of a feature. You can track click goals, page view goals, or create custom goals. We also provide an Optimizely integration so you can import your existing goals. We track all user events and let you see exactly how a feature is performing. Our analytics dashboard will help you see which feature variations are performing the best.

    Read more

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 nearly instantaneously, 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.

    Redis caching is currently supported by the following SDKs:

    You may 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

  • What is the targeting logic for percentage rollouts?

    The variation a user receives is determined based on the users key. When a percentage rollout is evaluated it generates a hash from the user's key, the user's secondary attribute if available, and a hidden salt attribute stored in the flag. The SDK then uses this hash to generate a percentage which is used in conjunction with the percentage rollout configuration to determine the variation a user receives.

  • Are anonymous users tracked when A/B testing?

    Yes, anonymous users are included in A/B testing. You will need to set an appropriate user key for anonymous users so that we can track each anonymous user separately; a session key might be appropriate. We don't display anonymous users on the Users screen because anonymous users couldn't be managed from LaunchDarkly, so they would only add clutter to the screen.

  • What happens when the MAU limit is reached?

    We do not impose a hard cap on MAUs. We'll never halt access or send you a weird bill based on overages. We allow for variance as we know a company's user base can grow unexpectedly over time. That said, we do limit the amount of users that will be saved in your dashboard. 

    Up to 150% of your monthly active users will be shown in your LaunchDarkly dashboard across all environments. Once you exceed this 150% your new users and changes to existing users will no longer appear in the dashboard. It's important to note that your users will continue to evaluate their flags correctly. This only impacts your ability to view user updates in the dashboard.

  • Do you have a REST API?

    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 or export your data 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%.

     
See all 19 articles

Troubleshooting

Application

  • Why should I avoid individually targeting too many users?

    Individually targeting users increases the size of the payload fetched by the SDK when initializing, and the memory footprint of the SDK.

    A better strategy would be to assign a custom attribute to the users who should receive the feature flag and then set up the targeting rules to serve the flag to users who have that attribute. This allows you to target groups of users without increasing the size of the payload.

    You can read more about our targeting rules here. 

  • How long does it take for users to appear in the dashboard?

    It generally takes just a couple of minutes for a user to appear in the dashboard. 

    You can check the dev console to verify that the users data is being sent to LaunchDarkly. If you open the dev console in an active tab and call variations on your users, you will see them appear in the console almost immediately. This is a great option to make sure that LaunchDarkly is receiving your user data without waiting for users to appear in the dashboard.

  • How can I be notified of interruptions to the LaunchDarkly service?

    The best way to get updates from us regarding service status is by subscribing to this RSS feed: http://status.launchdarkly.com/

  • I am unable to connect because of a mismatched origin header
    We take the security of your data at LaunchDarkly seriously. One of the protections we've implemented is validation that the Origin header for any API request authenticated by session cookie matches the expected Origin header (namely https://app.launchdarkly.com). This is just one way that we help to prevent CSRF attacks. (Note that we do not require origin matching when authenticating via Access Token, so this does not affect normal API usage.)
     
    If the Origin header does not match what's expected, we return an error. And since our application relies heavily on interaction with the API, the application will not function properly.
     
    Known causes
    Any browser extension that intentionally changes the Origin header will cause this problem. For example, the Allow-Control-Allow-Origin: * Chrome extension is known to change the Origin header to http://evil.com and will result in the problems described above.
  • What does "Your configuration is incomplete" mean?

    If you're seeing the "Your configuration is incomplete" message, it will usually indicate that there is an incomplete or invalid rule configured for your flag. For example, this could mean that an attribute was not selected, or a negative number was selected for a percentage rollout.

  • 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’
See all 8 articles

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:

    <dependency>
     <groupId>com.google.code.gson</groupId>
     <artifactId>gson</artifactId>
     <version>2.2.4</version>
    </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 in iOS SDK flag evaluation

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

    • The iOS SDK utilizes a streaming architecture to keep itself in sync with your configurations on the dashboard. If any change is made, these changes will be picked up by your iOS users the next time they get online.
    • When the SDK receives any updates from LaunchDarkly they are cached to Core Data, so that the SDK can still evaluate flags even when offline.
    • When a user first installs your app, until the first stream is established with 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.
    • When a current user uses the app while offline, or if variation calls are made before the SDK has has finished initializing, then the SDK will continue to serve variations using the old state, and you may see these events show up occasionally in your dev console after making changes.
    • If your SDK If you need to change your user, or you want to wait until the SDK has finished synchronizing with LaunchDarkly, you should use the userDidUpdate delegate to wait until the feature flags for the new user have been received.
  • 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.

Can't find what you're looking for?

Let us help you!

Submit a request