---
title: Getting Started with Feature Flags
description: >-
  Manage feature delivery with integrated observability, real-time metrics, and
  OpenFeature-compatible gradual rollouts.
breadcrumbs: Docs > Getting Started > Getting Started with Feature Flags
---

# Getting Started with Feature Flags

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site). ().
{% /alert %}

{% /callout %}

## Overview{% #overview %}

Datadog feature flags offer a powerful, integrated way to manage feature delivery, with built-in observability and seamless integration across the platform.

- **Real-time metrics:** Understand who's receiving each variant, as well as how your flag impacts the health & performance of your application—all in real time.

- **Supports any data type:** Use Booleans, strings, numbers or full JSON objects—whatever your use case requires.

- **Built for experimentation:** Target specific audiences for A/B tests, roll out features gradually with canary releases, and automatically roll back when regressions are detected.

- **OpenFeature compatible:** Built on the OpenFeature standard, ensuring compatibility with existing OpenFeature implementations and providing a vendor-neutral approach to feature flag management.

## Feature Flags SDKs{% #feature-flags-sdks %}

This guide uses the JavaScript browser SDK as an example. You can integrate Datadog Feature Flags into any application using one of the following SDKs:

### Client-side SDKs{% #client-side-sdks %}

- [Android](https://docs.datadoghq.com/feature_flags/client/android/)
- [Android TV](https://docs.datadoghq.com/feature_flags/client/android/)
- [Angular](https://docs.datadoghq.com/feature_flags/client/angular/)
- [iOS](https://docs.datadoghq.com/feature_flags/client/ios/)
- [JavaScript](https://docs.datadoghq.com/feature_flags/client/javascript/)
- [React](https://docs.datadoghq.com/feature_flags/client/react/)
- [React Native](https://docs.datadoghq.com/feature_flags/client/reactnative/)
- [tvOS](https://docs.datadoghq.com/feature_flags/client/ios/)

### Server-side SDKs{% #server-side-sdks %}

- [.NET](https://docs.datadoghq.com/feature_flags/server/dotnet/)
- [Go](https://docs.datadoghq.com/feature_flags/server/go/)
- [Java](https://docs.datadoghq.com/feature_flags/server/java/)
- [Node.js](https://docs.datadoghq.com/feature_flags/server/nodejs/)
- [Python](https://docs.datadoghq.com/feature_flags/server/python/)
- [Ruby](https://docs.datadoghq.com/feature_flags/server/ruby/)

## Configure your environments{% #configure-your-environments %}

Your organization likely already has pre-configured environments for Development, Staging, and Production. If you need to configure these or any other environments, navigate to the [**Environments**](https://app.datadoghq.com/feature-flags/settings/environments) page to create tag queries for each environment. You can also identify which environment should be considered a Production environment.

{% image
   source="https://datadog-docs.imgix.net/images/getting_started/feature_flags/environments-list.cd9670523869c056142c94452c411b60.png?auto=format"
   alt="Environments list" /%}

## Create your first feature flag{% #create-your-first-feature-flag %}

### Step 1: Import and initialize the SDK{% #step-1-import-and-initialize-the-sdk %}

First, install `@datadog/openfeature-browser`, `@openfeature/web-sdk`, and `@openfeature/core` as dependencies in your project:

```
yarn add @datadog/openfeature-browser @openfeature/web-sdk @openfeature/core
```

Then, add the following to your project to initialize the SDK:

```js
import { DatadogProvider } from '@datadog/openfeature-browser';
import { OpenFeature } from '@openfeature/web-sdk';

// Initialize the provider
const provider = new DatadogProvider({
    clientToken: '<CLIENT_TOKEN>',
    applicationId: '<APPLICATION_ID>',
    enableExposureLogging: true, // Can impact RUM costs if enabled
    site: 'datadoghq.com',
    env: '<YOUR_ENV>', // Same environment normally passed to the RUM SDK
    service: '<SERVICE_NAME>',
    version: '1.0.0'
});

// Set the provider
await OpenFeature.setProviderAndWait(provider);
```

{% alert level="warning" %}
Setting `enableExposureLogging` to `true` can impact [RUM](https://docs.datadoghq.com/real_user_monitoring/) costs, as it sends exposure events to Datadog through RUM. You can disable it if you don't need to track feature exposure or guardrail metric status.
{% /alert %}

More information about OpenFeature SDK configuration options can be found in its [documentation](https://openfeature.dev/docs/reference/technologies/client/web/). For more information on creating client tokens and application IDs, see [API and Application Keys](https://docs.datadoghq.com/account_management/api-app-keys/#client-tokens).

### Step 2: Create a feature flag{% #step-2-create-a-feature-flag %}

Go to [**Create Feature Flag**](https://app.datadoghq.com/feature-flags/create) in Datadog and configure the following:

- **Name and key**: The flag's display name and the key referenced in code

- **Variant type**: The data type for the flag variants (Boolean, string, integer, number, or JSON)

**Note**: The flag key and variant type cannot be modified after creation.

- **Variant values**: The possible values the flag can return (you can add these later)

- **Distribution channels**: Which types of SDKs receive this flag's configuration (client-side, server-side, or both)

{% alert level="warning" %}
Flag keys, variant keys, and variant values should be considered public when sent to client SDKs.
{% /alert %}

{% image
   source="https://datadog-docs.imgix.net/images/getting_started/feature_flags/create-feature-flags.0de9433490db6b875434b55b554fbc38.png?auto=format"
   alt="Create Feature Flag" /%}

### Step 3: Evaluate the flag and write feature code{% #step-3-evaluate-the-flag-and-write-feature-code %}

In your application code, use the SDK to evaluate the flag and gate the new feature.

```js
import { OpenFeature } from '@openfeature/web-sdk';

const client = OpenFeature.getClient();

// If applicable, set relevant attributes on the client's global context
// (e.g. org id, user email)
await OpenFeature.setContext({
    org_id: 2,
    user_id: 'user-123',
    email: 'user@example.com',
    targetingKey: 'user-123'
});

// This is what the SDK returns if the flag is disabled in
// the current environment
const fallback = false;

const showFeature = await client.getBooleanValue('show-new-feature', fallback);
if (showFeature) {
    // Feature code here
}
```

After you've completed this step, redeploy the application to pick up these changes. Additional usage examples can be found in the SDK's [documentation](https://openfeature.dev/docs/reference/technologies/client/web/).

### Step 4: Define targeting rules and enable the feature flag{% #step-4-define-targeting-rules-and-enable-the-feature-flag %}

Now that the application is ready to check the value of your flag, you can start adding targeting rules. Targeting rules enable you to define where or to whom to serve different variants of your feature.

Go to **Feature Flags**, select your flag, select the environment whose rules you want to modify, and click **Edit Targeting Rules**.

{% image
   source="https://datadog-docs.imgix.net/images/getting_started/feature_flags/ff-targeting-rules-and-rollouts.a989b93512ecb2d8d7799d967f43d100.png?auto=format"
   alt="Targeting Rules & Rollouts" /%}

### Step 5: Publish the rules in your environments{% #step-5-publish-the-rules-in-your-environments %}

After saving changes to the targeting rules, publish those rules by enabling your flag in the environment of your choice.

{% alert level="info" %}
As a general best practice, changes should be rolled out in a Staging environment before rolling out in Production.
{% /alert %}

Toggle your selected environment to **Enabled**.

{% image
   source="https://datadog-docs.imgix.net/images/getting_started/feature_flags/publish-targeting-rules.5138641be3fabf04978d164c21b2bd1b.png?auto=format"
   alt="Publish targeting rules" /%}

The flag serves your targeting rules in this environment. You can continue to edit these targeting rules to control where the variants are served.

### Step 6: Monitor your rollout{% #step-6-monitor-your-rollout %}

Monitor the feature rollout from the feature flag details page, which provides real-time exposure tracking and metrics such as **error rate** and **page load time**. As you incrementally release the feature with the flag, view the **Real-Time Metric Overview** panel in the Datadog UI to see how the feature impacts application performance.

{% image
   source="https://datadog-docs.imgix.net/images/getting_started/feature_flags/real-time-flag-metrics.50ed4bef49eb143a1c21f740368cb39d.png?auto=format"
   alt="Real-time flag metrics panel" /%}

## Further reading{% #further-reading %}

- [Client-Side SDKs](https://docs.datadoghq.com/feature_flags/client/)
- [Server-Side SDKs](https://docs.datadoghq.com/feature_flags/server/)
- [Ship features faster and safer with Datadog Feature Flags](https://www.datadoghq.com/blog/feature-flags/)
- [How to bridge speed and quality in experiments through unified data](https://www.datadoghq.com/blog/experimental-data-datadog/)
- [How Datadog Feature Flags is resilient to cloud provider failures](https://www.datadoghq.com/blog/datadog-feature-flags-cloud-resilience/)
