For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Sign inTry it free
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
  • SDKs
    • SDK concepts
      • Getting started with SDKs
      • Analytics events
      • Apple App Store data collection policy
      • Choosing an SDK type
      • Contributor's guide
      • Domain list
      • Evaluation reasons
      • Flag evaluation rules in server-side SDKs
      • Persistent data stores
      • Sample applications
      • Server-side SDK bandwidth usage
      • Using flag types
      • Version notifications
      • Versioning policy
    • SDK features
    • Client-side SDKs
    • Server-side SDKs
    • AI SDKs
    • Edge SDKs
    • OpenFeature providers
    • Observability SDKs
    • Relay Proxy
Sign inTry it free
LogoLogo
On this page
  • Overview
  • Prerequisites
  • Implementation guidelines for LaunchDarkly SDKs
  • Consider your SDK use case
  • Plan for a large initial payload from the streaming endpoint
  • Ensure you have a reliable network connection for first-time initialization
  • Implement SDKs in a singleton pattern
SDKsSDK concepts

Getting started with SDKs

Was this page helpful?
Previous

Analytics events

Next
Built with

Overview

This topic explains the prerequisites you must consider when you’re setting up a LaunchDarkly SDK for the first time.

Prerequisites

Regardless of which SDK you use, everyone who integrates LaunchDarkly with their code must consider the following prerequisites. Making decisions about the items listed below will help you use feature flags in a way that makes sense for your use case, customers, security considerations, and existing network architecture.

Consider the following factors when you’re starting to integrate LaunchDarkly SDKs with your code:

  1. Determine what kind of SDK you need to use.
    • Depending on your use case, you may need a server-side, client-side, mobile, AI, or edge SDK.
    • Generally, you only need one SDK per application or service. You can use multiple SDKs if your product is comprised of applications or services written in multiple languages. Using an AI SDK requires initializing the associated server-side SDK.
    • You do not need multiple SDKs to support front-end and back-end behavior, but we support this configuration if it works best for you.
    • All of our SDKs are thread-safe, ensuring consistent behavior from an SDK when you use it in multiple threads.
    • To learn more about SDKs, read Choosing an SDK type.
  2. Identify the language you want to use. In some cases, we support multiple SDKs for a language. To learn more, read Available SDKs. We may also provide a sample application in your preferred language or framework, even if we don’t have a dedicated SDK. To learn more, read Sample applications.
  3. Confirm that your tech stack is compatible with the SDK you want to use.
    • More information about each SDK’s dependencies is available in the documentation for the specific SDK, and in the SDK’s README in GitHub.
    • LaunchDarkly uses the SLSA framework to help developers ensure the authenticity and build integrity of published SDK packages. More information is available in the SDK’s README in GitHub.
  4. (Optional) Determine if you need to use the Relay Proxy. To learn more, read The Relay Proxy.
Newer versions of LaunchDarkly SDKs replace users with contexts

A context is a generalized way of referring to the people, services, machines, or other resources that encounter feature flags in your product. Contexts replace another data object in LaunchDarkly: “users.”

Creating contexts and evaluating flags based on them is supported in the latest major versions of most of our SDKs. For these SDKs, the code samples on this page include the two most recent versions.

Implementation guidelines for LaunchDarkly SDKs

Here are some basic guidelines for implementing LaunchDarkly SDKs:

Consider your SDK use case

The SDK types have different security considerations as well as some behavioral and architectural differences. They handle flag evaluations differently, utilize different kinds of SDK keys, and support different languages.

To learn more, read Choosing an SDK type.

Plan for a large initial payload from the streaming endpoint

The initial payload contains all the targeting rules for the environment associated with the provided SDK key. If you target a large number of individual contexts, have a very large number of flags, or have large numbers of extremely complicated rules, then this can increase the initial payload size. Configure any relevant timeout options to anticipate a large initial load. This helps prevent the SDK from timing out.

Ensure you have a reliable network connection for first-time initialization

The SDK will time out if it cannot get a network connection to LaunchDarkly. Failure to connect is a recoverable error, so the SDK will keep trying to reconnect, but a timeout could happen in the middle of an attempt. If the SDK times out during a first-time initialization, it will serve the flag values you defined in your application code until it can connect to LaunchDarkly.

Implement SDKs in a singleton pattern

Your SDK should only initialize once statically, and that instance should be the exclusive instance you use for a given LaunchDarkly project. When you create multiple SDK instances, previous instances may leak into memory and stay active beyond their useful lifespan.

When you have enough of these instances running, they can cause bottlenecks in the connection to the streaming endpoint.