Overview

Datadog Feature Flags for server-side applications allow you to remotely control feature availability, run experiments, and roll out new functionality with confidence. Server-side SDKs receive flag configuration and evaluate flags locally. Some SDKs use a Datadog tracer for configuration delivery or telemetry.

Datadog Feature Flags is built on the OpenFeature standard, an open source, vendor-neutral specification for feature flag APIs. If you’re new to OpenFeature concepts like providers, evaluation context, and hooks, see the OpenFeature concepts documentation.

Configuration delivery

Agentless configuration delivery is the default in server SDK versions that support it. The SDK fetches flag configuration directly from the Datadog-managed CDN over HTTPS, then evaluates flags locally. A Datadog Agent is not required for flag configuration.

The default source does not activate Feature Flags traffic for every tracer installation. Agentless polling begins only when application code initializes or accesses the Datadog OpenFeature provider. Explicitly selecting remote_config activates the Feature Flags Remote Configuration subscription. Requests through either source contribute to server Feature Flags billing.

Java CDN delivery requires dd-openfeature and dd-java-agent. It does not require a Datadog Agent for flag configuration.

Agentless delivery is available for the SDKs and versions listed. Other server SDKs use Agent Remote Configuration.

Choose a language

Select your language or framework to view SDK-specific setup instructions:

For serverless runtimes, see Serverless Environments for no-Agent setup, version requirements, and initial telemetry limitations.

Prerequisites

Requirements depend on the selected SDK and configuration source. Standard requirements include:

• The language-specific tracer or OpenFeature provider versions listed on the SDK page
• A Datadog API key

Java CDN delivery requires the Java agent in the application process. It does not require APM tracing or a separate Datadog Agent service.

Source-specific requirements are:

Agentless configuration

On a supported SDK version, configure the application process:

# Required for direct configuration delivery
DD_API_KEY=<DATADOG_API_KEY>
DD_SITE=<code class="js-region-param region-param" data-region-param="dd_site"></code>
DD_ENV=<YOUR_ENVIRONMENT>

No Feature Flags enablement or source setting is required. See Java Feature Flags or Node.js Feature Flags for dependency versions and language-specific initialization. Initializing or accessing the provider starts CDN polling; tracer installation and initialization alone do not.

Agent Remote Configuration

For Java and Node.js, set the source explicitly to retain Agent-managed delivery:

DD_FEATURE_FLAGS_CONFIGURATION_SOURCE=remote_config

Remote Configuration is enabled by default in Agent 7.47.0 and later. If your Agent has Remote Configuration disabled, re-enable it by setting DD_REMOTE_CONFIGURATION_ENABLED=true or adding remote_configuration.enabled: true to your datadog.yaml.

See the Remote Configuration documentation for detailed setup instructions across deployment environments.

Existing Java and Node.js implementations with DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true remain on Remote Configuration during a migration window. The setting is deprecated. See Migrate from the legacy provider setting to remain on Remote Configuration explicitly or move to agentless delivery.

Remote Configuration polling interval

The Agent polls Datadog for configuration updates at a configurable interval:

# Optional: Configure the Agent polling interval (default: 60s)
DD_REMOTE_CONFIGURATION_REFRESH_INTERVAL=10s

Advanced application configuration

Configure your application with the standard Datadog environment variables. These are common across all server-side SDKs:

# Required: Service identification
DD_SERVICE=<YOUR_SERVICE_NAME>
DD_ENV=<YOUR_ENVIRONMENT>
DD_VERSION=<YOUR_APP_VERSION>

# Optional: Disable Feature Flags and both delivery paths
# DD_FEATURE_FLAGS_ENABLED=false

# Optional: Enable flag evaluation metrics
# See "Set Up Server-Side Flag Evaluation Metrics" documentation

For SDKs and delivery modes that support it, see Set Up Server-Side Flag Evaluation Metrics to enable the feature_flag.evaluations metric. The initial Node.js agentless releases do not export evaluation metrics or exposure events. Java requires a supported Datadog Agent or serverless telemetry path to export these signals. See Feature Flag Graphs for more information on available graphing.

Testing with in-memory providers

Datadog supports these testing approaches:

• Integration tests: Point DatadogProvider at a dedicated test environment and control flag values from the Datadog UI. This exercises the real provider and selected configuration source end-to-end.
• Unit tests: Swap DatadogProvider for OpenFeature’s standard InMemoryProvider (or an equivalent test stub, where no in-memory provider is available in the language) and set flag values directly in test code. This keeps tests hermetic and offline.

This section covers the in-memory approach. Because the OpenFeature API is designed to make providers swappable at runtime, your application code does not change — only the provider registered during test setup.

A typical test follows this pattern:

1. Build a map of flag keys to variants in your test setup.
2. Register an InMemoryProvider with that map through the OpenFeature API.
3. Call the OpenFeature client in the units being tested. The InMemoryProvider returns the flag assignments configured at test setup.
4. Reset the provider in test teardown to avoid cross-test state leakage.

See your language’s SDK page (select from the top of this page) for a concrete test example.

Context attribute requirements

Use flat attributes in your evaluation context:

const evaluationContext = {
  targetingKey: req.session?.userID,
  companyId: req.session?.companyID,
  tier: 'enterprise'
};

const value = client.getBooleanValue('my-flag', false, evaluationContext);

Avoid nested objects and arrays:

// These attributes will cause exposure events to be dropped
const evaluationContext = {
  targetingKey: req.session?.userID,
  company: { id: req.session?.companyID },  // nested object - NOT SUPPORTED
  roles: ['admin', 'user']                   // array - NOT SUPPORTED
};

Further reading

For percentage-based rollouts and deterministic bucketing, see Traffic Splitting and Randomization.

Additional helpful documentation, links, and articles:

Client-Side Feature FlagsDOCUMENTATION Remote ConfigurationDOCUMENTATION Set Up Server-Side Flag Evaluation MetricsGUIDE Feature Flag GraphsCONCEPT Serverless environments and Feature FlagsDOCUMENTATION Server SDK Configuration SourcesCONCEPT