--- title: Server-Side Feature Flags description: Set up Datadog Feature Flags for server-side applications. breadcrumbs: Docs > Feature Flags > Server-Side Feature Flags --- > For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt). # Server-Side Feature Flags {% callout %} # Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com {% alert level="danger" %} This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}). {% /alert %} {% /callout %} ## Overview{% #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](https://openfeature.dev/docs/reference/intro/), 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](https://openfeature.dev/docs/category/concepts). ## Configuration delivery{% #configuration-delivery %} Agentless [configuration delivery](https://docs.datadoghq.com/feature_flags/concepts/configuration_sources.md) 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. | SDK | Minimum agentless version | | ----------------------------------------- | ------------------------- | | Java `dd-openfeature` and `dd-java-agent` | 1.65.0 | | Node.js `dd-trace` v5 | 5.116.0 | | Node.js `dd-trace` v6 | 6.5.0 | Java CDN delivery requires `dd-openfeature` and `dd-java-agent`. It does not require a Datadog Agent for flag configuration. {% alert level="warning" %} The initial Node.js agentless releases support configuration delivery and local flag evaluation only. They do not export evaluation metrics or exposure events. Java agentless delivery changes only the configuration source. Without a supported Datadog Agent or serverless telemetry path, Java also does not export these signals. {% /alert %} Agentless delivery is available for the SDKs and versions listed. Other server SDKs use Agent Remote Configuration. ## Choose a language{% #choose-a-language %} Select your language or framework to view SDK-specific setup instructions: - [dotnet](https://docs.datadoghq.com/feature_flags/server/dotnet.md) - [go](https://docs.datadoghq.com/feature_flags/server/go.md) - [java](https://docs.datadoghq.com/feature_flags/server/java.md) - [nodejs](https://docs.datadoghq.com/feature_flags/server/nodejs.md) - [php](https://docs.datadoghq.com/feature_flags/server/php.md) - [python](https://docs.datadoghq.com/feature_flags/server/python.md) - [ruby](https://docs.datadoghq.com/feature_flags/server/ruby.md) For serverless runtimes, see [Serverless Environments](https://docs.datadoghq.com/feature_flags/implementation_patterns/serverless.md) for no-Agent setup, version requirements, and initial telemetry limitations. ## Prerequisites{% #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](https://docs.datadoghq.com/account_management/api-app-keys.md#api-keys) 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: | Source | Requirements | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `agentless` (default where supported) | Configure `DD_API_KEY`, `DD_SITE`, and `DD_ENV` in the application process. No Agent is required for flag configuration. | | `remote_config` | Datadog Agent 7.55 or later with Remote Configuration enabled, the API key configured on the Agent, and Remote Configuration enabled for your organization in [Organization Settings](https://app.datadoghq.com/organization-settings/remote-config). Java also requires compatible `dd-openfeature` and `dd-java-agent` versions. | ## Agentless configuration{% #agentless-configuration %} On a supported SDK version, configure the application process: ```bash # Required for direct configuration delivery DD_API_KEY= DD_SITE= DD_ENV= ``` No Feature Flags enablement or source setting is required. See [Java Feature Flags](https://docs.datadoghq.com/feature_flags/server/java.md) or [Node.js Feature Flags](https://docs.datadoghq.com/feature_flags/server/nodejs.md) 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{% #agent-remote-configuration %} For Java and Node.js, set the source explicitly to retain Agent-managed delivery: ```bash 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](https://docs.datadoghq.com/remote_configuration.md) 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](https://docs.datadoghq.com/feature_flags/concepts/configuration_sources.md#migrate-an-existing-remote-configuration-setup) to remain on Remote Configuration explicitly or move to agentless delivery. ### Remote Configuration polling interval{% #remote-configuration-polling-interval %} The Agent polls Datadog for configuration updates at a configurable interval: ```bash # Optional: Configure the Agent polling interval (default: 60s) DD_REMOTE_CONFIGURATION_REFRESH_INTERVAL=10s ``` ## Advanced application configuration{% #advanced-application-configuration %} Configure your application with the standard Datadog environment variables. These are common across all server-side SDKs: ```bash # Required: Service identification DD_SERVICE= DD_ENV= DD_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 ``` {% alert level="info" %} In the Java and Node.js versions listed above, `DD_FEATURE_FLAGS_ENABLED` defaults to `true`, so you do not need to set it. Setting it to `false` disables the provider, CDN polling, and the Feature Flags Remote Configuration subscription. Other server SDKs continue to use the activation settings documented on their language pages. {% /alert %} For SDKs and delivery modes that support it, see [Set Up Server-Side Flag Evaluation Metrics](https://docs.datadoghq.com/feature_flags/guide/server_flag_evaluation_metrics.md) 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](https://docs.datadoghq.com/feature_flags/concepts/flag_graphs.md) for more information on available graphing. ## Testing with in-memory providers{% #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. 1. Register an `InMemoryProvider` with that map through the OpenFeature API. 1. Call the OpenFeature client in the units being tested. The `InMemoryProvider` returns the flag assignments configured at test setup. 1. 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{% #context-attribute-requirements %} {% alert level="warning" %} 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. {% /alert %} Use flat attributes in your evaluation context: ```javascript 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: ```javascript // 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{% #further-reading %} For percentage-based rollouts and deterministic bucketing, see [Traffic Splitting and Randomization](https://docs.datadoghq.com/feature_flags/concepts/traffic_splitting.md). Additional helpful documentation, links, and articles: - [Client-Side Feature Flags](https://docs.datadoghq.com/feature_flags/client.md) - [Remote Configuration](https://docs.datadoghq.com/remote_configuration.md) - [Set Up Server-Side Flag Evaluation Metrics](https://docs.datadoghq.com/feature_flags/guide/server_flag_evaluation_metrics.md) - [Feature Flag Graphs](https://docs.datadoghq.com/feature_flags/concepts/flag_graphs.md) - [Serverless environments and Feature Flags](https://docs.datadoghq.com/feature_flags/implementation_patterns/serverless.md) - [Server SDK Configuration Sources](https://docs.datadoghq.com/feature_flags/concepts/configuration_sources.md)