We're sorry to see you go. To cancel your subscription, you can contact your Account Executive or email support@launchdarkly.com. 

If you are looking to delete a trial account that has no subscription, you may wish to reference the following knowledgebase article here.

You can configure your identity provider to send `role` and `customRole` attributes when the team member is signing into LaunchDarkly.

`role` is an optional attribute, which represents a built-in LaunchDarkly role. It must be one of reader, writer, admin. If unspecified, the default role is reader.

`customRole` is another optional attribute. It must be a list of keys for custom roles to give to the team member. These will replace the member’s existing custom roles. If a member has any custom roles, they will supersede the built-in role.

https://docs.launchdarkly.com/docs/single-sign-on#section-user-provisioning-via-sso

When a team member tries to log in to a LaunchDarkly account which has SSO enabled, they should be redirected to login via your Identity Provider. If a team member is prompted for a password, this indicates that an account has not yet been provisioned for that team member.

LaunchDarkly does not support automatic provisioning of new team member accounts. To add new team members, the initial login must be done via a LaunchDarkly application set up in your Identity Provider. Once that step has been taken, the account will be created. On subsequent logins, the team member will be redirected to your IdP when attempting to log in via the LaunchDarkly website.

If you get an error saying that you can't join because the email is part of an existing account, then you should follow the steps in this knowledge base article and then try logging in through your IDP again: https://support.launchdarkly.com/hc/en-us/articles/115002410848

Read more about user provisioning in our documentation here.

If a team member has multiple custom roles, we iterate through each role and see if it will approve the action. If so, the action is approved immediately. If the role denies a certain action, we continue to iterate through the remaining roles to see if any of those roles approve that action. 

In short, if a user has a custom role that allows an action that another custom role denies, the action will ultimately be allowed.

If MFA is enabled and you are locked out of your LaunchDarkly account, you can contact the LaunchDarkly owner or one of the admins at your company to get a reset code. Once you receive this reset code, you will need to head to your profile settings page and re-enable MFA using an authenticator app on your phone.

Are you the account owner? Unfortunately, no one at your organization has sufficient permissions to reset your MFA. Reach out to support@launchdarkly.com and we'd be happy to assist you in regaining access to your account. 

Read more about LaunchDarkly Multi-factor Authentication in our documentation here 

Check out our Getting Started Checklist to get the most out of LaunchDarkly and check out our getting started docs.

After you create a LaunchDarkly account, you will have access to our Quickstart tutorial.  The Quickstart will walk you through the creation of your first feature flag using any of our SDKs.  

We also have sample applications for all supported SDKs. These are simple applications designed to show how the SDK works. You can find them on Github here. 

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.

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.

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 multiple zones of AWS and our globally distributed CDN provider. With the architecture, a feature flag will always be available.

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.

Simply click Start free trial to create an account. All plans come with a free 30 day trial with the core Pro plan features. Contact us using the demo form if you would like a demo or have any questions.

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.

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

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.

LaunchDarkly supports single-sign on with SAML 2.0. All identity providers that support SAML 2.0 should work with our platform. We've tested support for the following SAML 2.0 identity providers:

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

We have official apps already built for Okta, OneLogin, and Azure. See our documentation for complete setup instructions as well as configuration tips for some specific providers.

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.

In addition to targeting individual users, LaunchDarkly allows you to set up targeting rules that target users by attribute. 

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

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

LaunchDarkly does not have a built in way to schedule a flag for a particular date, however this can be achieved with targeting rules. For example, you may want to serve true to show your feature, but only after November 19th, 2018.

You can use the before/after operator to compare dates in your targeting rules. You'll simply need to include the current date as a custom attribute in your user object and then set up a targeting rule that evaluates to true if the date value in your user object is after the date specified in your targeting rule. Note that dates must be formatted in unix milliseconds for date comparisons. You can reference this in our documentation here. 

Here's an example in JavaScript showing how to include the current date in unix milliseconds in your user object:

var user = {
 "key": "67yx27g7fxl004483",
 "custom": {
 "current_date": new Date().getTime()
  }
};

And here's a screenshot showing how the targeting rule would look in the UI:

This example user will evaluate to `true` because their current date attribute is after the date specified in the flag's targeting rules.

Anonymous users work just like regular users, except these users are not stored in your dashboard. One of the primary reasons that users are sent anonymously is to avoid having a lot of unauthenticated users polluting the user dashboard. Another reason is to avoid sending PII, but we recommend the use of private user attributes if that is the case. 

There are some cases where you do need to generate a unique key for anonymous users. If you are targeting users individually by key, using LaunchDarkly's A/B testing feature, or the Analytics Data Stream you would want unique keys. You also want unique keys when conducting percentage rollouts. For that reason, the general documented advice is to treat the anonymous users like regular users and assign unique IDs. 

If you do not have a need to uniquely identify your anonymous users, you could use a shared key for these users.

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.

The SDK relies on its stored state to evaluates flags. By default the SDK first initializes with an empty state. When the SDK first initializes, it opens a streaming connection to LaunchDarkly. The initial response from LaunchDarkly contains the SDKs current state. The SDK will then keep this streaming connection open and when any change is made in the LaunchDarkly dashboard or via the Rest API, LaunchDarkly will send these changes to all currently connected SDKs.

If the SDK ever loses connectivity to LaunchDarkly then it will continue attempting to establish a streaming connection until it succeeds. If you try to evaluate a flag before the SDK receives its initial state, or you try to fetch a flag which otherwise doesn't exist, then the SDK will return the fallback value. All SDKs provide synchronous (through blocking and/or polling) and asynchronous ways of waiting for the SDKs state to initialize.

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

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.

Yes. With our streaming architecture, updates will be reflected in all your servers within milliseconds. If you require even stronger consistency guarantees, you can configure our SDKs to read and write from a shared Redis store.

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.

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.

We do not impose a hard cap on MAUs. We'll never halt access or send you a 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. 

When you exceed your MAU, your new users and changes to existing users (such as new attributes) 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.

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.

We use a z-score.

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.

Read more about our targeting rules. 

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

LaunchDarkly supports only IdP-initiated SSO:

Identity Provider Initiated (IdP-initiated) SSO.  With this option, your end users must log into your Identity Provider's SSO page (e.g., Okta, OneLogin, or Microsoft Azure AD) and then click an icon to log into and open LaunchDarkly the web application. 

Service Provider Initiated (SP-initiated) SSO.  LaunchDarkly does not support this option: This option gives your end users the ability to sign into the apps Login page and then sends an authorization request to the Identify Provider (e.g., Okta, OneLogin, or Microsoft Azure AD). Once the IdP authenticates the user's identify, the user is logged into app. 

You may see an error indicating your MFA code is invalid. This error is caused when the 6 digit code generated by your authenticator app has expired or is tied to the wrong QR code. 

If you're trying to set up MFA for the first time, or re-enable MFA after a reset, one possibility is that you're using a 6 digit code from your authenticator app that is tied to a different QR code than the one displayed on the current page. If you're setting up MFA by scanning a new QR code, be sure not to refresh the page before entering your 6 digit code, or a new QR code will be generated, rendering the code on your applicator obsolete. If you're signing up for a new account, or setting up MFA for the first time, we recommend taking the following steps to ensure you're working with the correct QR code:

1. Delete all existing LaunchDarkly QR codes in your authenticator app.
2. Follow the invitation link from your email and scan the QR code displayed.
3. Immediately enter the 6 digit code generated from your application without refreshing.

If you have confirmed that your 6 digit code is being generated for the correct application, or you have already successfully enabled MFA and you are seeing this error, this may be caused by the clock on your authenticator app being out of sync. We recommend the Google Authenticator app, and Google recommends the following steps to verify that you have the correct time on your authenticator app:

1. Go to the main menu on the Google Authenticator app
2. Tap More  Settings.
3. Tap Time correction for codes
4. Tap Sync now

If you're still experiencing any issues, please contact support@launchdarkly.com.

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

You can check the debugger to verify that the users data is being sent to LaunchDarkly. If you open the debugger in an active tab and call variations on your users, you will see them appear in the debugger 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.

You can read more about the debugger in our documentation here.

Everything works as expected when you target users individually, and users appear to be receiving the correct variation based on the default rule. So why aren't your rules targeting users by attribute working as expected?

The SDK will only evaluate flags using the user object you provide it. The SDK does not use the attributes shown on the dashboard, and user attributes are not synchronized across SDK instances. The only information that is synchronized is flag configuration related data. You will need to provide all applicable user attributes for your configured targeting rules to apply.

The following example shows how to configure your SDK to connect to LaunchDarkly through a HTTP/HTTPS proxy.

LDConfig config = new LDConfig.Builder()
    .proxyHost("https://PROXYURL")
    .proxyPort(8080)
    .proxyUsername("USERNAME") // OPTIONAL
    .proxyPassword("PASSWORD") // OPTIONAL
  .build(); LDClient ldClient = new LDClient("YOUR_SDK_KEY", config);

When you evaluate feature flags, the SDK queues up an analytic event to send back to LaunchDarkly. The events endpoint is used to send these events. If you are working with the JavaScript SDK, enabling your browser's Do Not Track setting or using Adblock will block all requests to events.launchdarkly.com. 

Rest assured that this does not impact your user evaluations - your users will continue to receive the correct variation for the requested flags. This only impacts the ability to send information back to LaunchDarkly.

Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres. You can read more about what caches we support here: https://docs.launchdarkly.com/docs/using-a-persistent-feature-store

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>

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:

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.