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
    • SDK features
    • Client-side SDKs
    • Server-side SDKs
      • .NET SDK reference
      • Apex SDK reference
      • C++ SDK reference
      • Erlang SDK reference
      • Go SDK reference
      • Haskell SDK reference
      • Java SDK reference
      • Lua SDK reference
      • Node.js SDK reference
        • Node.js (server-side) SDK 8.x to 9.0 migration guide
        • Node.js (server-side) SDK 7.x to 8.0 migration guide
        • Node.js (server-side) SDK 6.x to 7.0 migration guide
        • Node.js (server-side) SDK 5.x to 6.0 migration guide
      • PHP SDK reference
      • Python SDK reference
      • Ruby SDK reference
      • Rust SDK reference
    • AI SDKs
    • Edge SDKs
    • OpenFeature providers
    • Observability SDKs
    • Relay Proxy
Sign inTry it free
LogoLogo
On this page
  • Overview
  • Get started
  • Install the SDK
  • Initialize the client
  • Evaluate a context
  • Promises and async
  • Shut down the client
  • Supported features
SDKsServer-side SDKs

Node.js SDK reference (server-side)

Was this page helpful?
Previous

Node.js (server-side) SDK 8.x to 9.0 migration guide

Next
Built with

Overview

This topic documents how to get started with the server-side Node.js SDK. It also links to reference information for all of the features the server-side Node.js SDK supports.

SDK quick links

LaunchDarkly’s SDKs are open source. In addition to this reference guide, we provide source, API reference documentation, and sample applications:

ResourceLocation
SDK API documentationSDK API docs
Supported SDK VersionsNode.js server SDK
GitHub repositorynode-server-sdk
Sample applicationsNode.js (server-side)
Node.js (server-side), TypeScript
Node.js (server-side) with bootstrapping
OpenFeature Node.js (server-side)
Published modulenpm
For use in server-side applications only

This SDK is intended for use in multi-user Node.js server applications. If you want to set up LaunchDarkly in JavaScript in a browser environment, read the JavaScript SDK reference. If you’re creating a client-side Node application, read the Node.js SDK reference (client-side). If you’re creating a desktop application in Electron, read the Electron SDK reference.

To learn more about LaunchDarkly’s different SDK types, read Choosing an SDK type.

The sample code snippets for this SDK are available in both JavaScript and TypeScript, where the sample code differs. To learn more, read Using LaunchDarkly with TypeScript.

Get started

After you complete the Getting Started process, follow these instructions to start using the LaunchDarkly SDK in your Node.js application.

Install the SDK

First, install the LaunchDarkly SDK as a dependency in your application using your application’s dependency manager.

We recommend making the LaunchDarkly observability plugin available as well. This plugin collects and sends observability data to LaunchDarkly, including metrics autogenerated from OpenTelemetry data. This means you can review error monitoring, logs, and traces from within the LaunchDarkly UI. They require the Node.js (server-side) SDK version 9.10 or later.

Here’s how:

shell
$npm install @launchdarkly/node-server-sdk
$
$# optional observability plugin, requires Node.js (server-side) SDK v9.10+
$npm install @launchdarkly/observability-node
$
$# In earlier versions, the package name was launchdarkly-node-server-sdk or ldclient-node

Next, import the LaunchDarkly client in your application code:

1import { init, LDContext, LDOptions } from '@launchdarkly/node-server-sdk';
2
3// optional observability plugin, requires Node.js (server-side) SDK v9.10+
4import { Observability } from "@launchdarkly/observability-node";
The Node.js (server-side) SDK uses an SDK key

The Node.js (server-side) SDK uses an SDK key. Keys are specific to each project and environment. They are available on the SDK keys page under Settings. To learn more about key types, read Keys.

Initialize the client

After you install and import the SDK, create a single, shared instance of LDClient. Specify your SDK key here to authorize your application to connect to a particular environment within LaunchDarkly.

Here’s how:

Node.js SDK
1const client = init(
2 'YOUR_SDK_KEY',
3 {
4 // optional observability plugin, requires Node.js (server-side) SDK v9.10+
5 plugins: [ new Observability(), ],
6 // other options
7 },
8);

To learn more about the specific configuration options available in this SDK, read LDOptions.

LDClient must be a singleton

It’s important to make LDClient a singleton for each LaunchDarkly project. The client instance maintains internal state that allows us to serve feature flags without making any remote requests. Do not instantiate a new client with every request.

If you have multiple LaunchDarkly projects, you can create one LDClient for each. In this situation, the clients operate independently. For example, they do not share a single connection to LaunchDarkly.

The client emits a ready event when you initialize it and it can serve feature flags.

Evaluate a context

Using client, you can check which variation a particular context will receive for a given feature flag. The ready event is only emitted once, when you first initialize the client. In a production application, place your client.variation code so that it is invoked as needed.

Here is an example:

1const context = {
2 "kind": 'user',
3 "key": 'example-user-key',
4 "name": 'Sandy'
5};
6
7client.on('ready', () => {
8 client.variation('example-flag-key', context, false,
9 (err, showFeature) => {
10 if (showFeature) {
11 // application code to show the feature
12 } else {
13 // the code to run if the feature is off
14 }
15 });
16});

Promises and async

All asynchronous SDK methods which accept a callback also return a Promise. This means that if your application uses promises to manage asynchronous operations, interacting with the SDK should be convenient. Because the async/await syntax is based on Promises, these methods also work with await.

Here is an example:

1// Using the .then() method to add a continuation handler for a Promise
2client.variation('example-flag-key', context, false).then((value) => {
3 // application code
4});
5
6// Using "await" instead, within an async function
7const value = await client.variation('example-flag-key', context, false);

There is also an alternative to the ready event:

JavaScript
1// Using .then() and .catch() to add success and error handlers to a Promise
2client.waitForInitialization({timeout: 10}).then((client) => {
3 // initialization complete
4}).catch((err) => {
5 // timeout or initialization failed
6});
7
8// Using "await" instead, within an async function
9try {
10 await client.waitForInitialization({timeout: 10});
11 // initialization complete
12} catch (err) {
13 // timeout or initialization failed
14}

allFlagsState and flush also return a Promise.

Do not wait for a Promise indefinitely

There is no built-in timeout for this method. Instead, we recommend using Promise.race() for your code to stop waiting on the Promise after a set amount of time. Regardless of whether you continue to wait, the SDK will still retry all connection failures indefinitely unless it gets an unrecoverable error.

Shut down the client

Shut down the client when your application terminates. To learn more, read Shutting down.

Unlike other LaunchDarkly SDKs, the Node.js (server-side) SDK does not automatically send pending analytics events to LaunchDarkly when it shuts down. To send analytics events, you first need to call flush.

Supported features

This SDK supports the following features:

  • Anonymous contexts and users
  • Big segments
  • Bootstrapping
  • Configuration, including
    • Application metadata configuration
    • Migration configuration
    • Service endpoint configuration
  • Context configuration
  • Data saving mode
  • Evaluating flags
  • Flag evaluation reasons
  • Flushing events
  • Getting all flags
  • Hooks
  • Identifying and changing contexts
  • Logging configuration
  • Migrations
  • Observability
  • Offline mode
  • OpenTelemetry
  • Private attributes
  • Reading flags from a file
  • Relay Proxy configuration
    • Using proxy mode
    • Using daemon mode
  • Secure mode
  • Sending custom events
  • Service endpoint configuration
  • Shutting down
  • Storing data
  • Subscribing to flag changes
  • Test data sources
  • Web proxy configuration