For AI agents: A markdown version of this page is available at https://docs.datadoghq.com/feature_flags/server.md. A documentation index is available at /llms.txt.

Server-Side Feature Flags

This product is not supported for your selected Datadog site. ().

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 integrate with the Datadog tracer for your language and use Remote Configuration to receive flag updates in real time.

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.

This guide covers the common setup required for all server-side SDKs, including Agent configuration and application environment variables. Select your language or framework to view SDK-specific setup instructions:

.NET
Go
Java
Node.js
PHP
Python
Ruby

For serverless runtimes, see Serverless Environments for the Agent-based architecture and limitations.

Prerequisites

Before setting up server-side feature flags, ensure you have:

Agent configuration

Server-side feature flags use Remote Configuration to deliver flag configurations to your application. 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 different deployment environments.

Polling interval

The Agent polls Datadog for configuration updates at a configurable interval. This interval determines the average time between making a flag change in the UI and the change becoming available to your application.

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

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>

# Agent connection (if not using default localhost:8126)
DD_AGENT_HOST=localhost
DD_TRACE_AGENT_PORT=8126

# Required: Enable the feature flagging provider
DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true

# Optional: Enable flag evaluation metrics
DD_METRICS_OTEL_ENABLED=true
The DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true environment variable is required to enable the feature flagging provider. Java also supports the system property -Ddd.experimental.flagging.provider.enabled=true, and Ruby and Node.js support code-based configuration as an alternative. See the SDK-specific documentation for details.
Remote Configuration must be available for server-side Feature Flags. It is enabled by default on Agent 7.47.0 and later. Only set SDK-level Remote Configuration variables (such as DD_REMOTE_CONFIG_ENABLED=true) if your tracer has Remote Configuration disabled and you need to override that setting.
Set DD_METRICS_OTEL_ENABLED=true to enable flag evaluation metrics. Without this, the SDK does not emit metrics for flag evaluations. When enabled, each evaluation records a feature_flag.evaluations counter metric tagged with the flag key, result variant, and evaluation reason.

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 end-to-end, including Remote Configuration delivery.
  • 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

Evaluation context attributes must be flat primitive values (strings, numbers, booleans). Nested objects and arrays are not supported and will cause exposure events to be silently dropped.

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 more more Remote ConfigurationDOCUMENTATION more more Serverless environments and Feature FlagsDOCUMENTATION more more