--- title: Serverless Environments description: >- Use Datadog Feature Flags server SDKs in serverless environments with or without a Datadog Agent. breadcrumbs: Docs > Feature Flags > Implementation Patterns > Serverless Environments --- > For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt). # Serverless Environments {% 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 %} The Datadog Feature Flags Java, Node.js, and Python SDKs can receive flag configuration directly from the Datadog-managed CDN. This *agentless* configuration source simplifies onboarding because it does not require a Datadog Agent for flag configuration. It also supports serverless applications that cannot connect to a Datadog Agent. After configuration is loaded, flag evaluation happens locally in the application. The SDK does not make a network request for each evaluation. The following table shows the Feature Flags functionality available in each SDK version: | SDK | Minimum version | Agentless configuration and local evaluation | Experiment exposure events | Event Platform Proxy (EVP) flag evaluation events | Event delivery | | ----------------------------------------- | --------------- | -------------------------------------------- | -------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------- | | Java `dd-openfeature` and `dd-java-agent` | 1.66.0 | Supported | Supported | Supported | Prefer a compatible local telemetry relay; use direct fallback when unavailable | | Node.js `dd-trace` | 6.12.0 | Supported | Supported | Not supported | Prefer a compatible local telemetry relay; use direct fallback when unavailable | | Python `ddtrace` | 4.14.0 | Supported | Supported | Supported | Compatible local telemetry relay | Java CDN delivery requires `dd-openfeature` and `dd-java-agent`. The Java runtime must support loading `dd-java-agent` with the `-javaagent` JVM option. You can pass this option in the Java command or through `JAVA_TOOL_OPTIONS`. The listed versions provide the capabilities shown in the table. Other server SDKs use Agent Remote Configuration for flag delivery. Agentless delivery changes only the flag configuration source. Feature Flags events use a separate connection to a compatible local telemetry relay or the supported direct path. ## Agentless architecture{% #agentless-architecture %} Use agentless delivery when the serverless runtime can make outbound HTTPS requests to Datadog. For Java, the runtime must also let you set the `-javaagent` JVM option: 1. Use a supported SDK version. 1. For Java, load `dd-java-agent` with `-javaagent` or `JAVA_TOOL_OPTIONS`. See the Java setup for [Cloud Run Functions](https://docs.datadoghq.com/serverless/google_cloud_run/functions/java.md?tab=maven) or [Cloud Run containers](https://docs.datadoghq.com/serverless/google_cloud_run/containers/in_container/java.md) for examples. 1. Configure the API key, Datadog site, and environment in the serverless application: ```bash DD_API_KEY= DD_SITE= DD_ENV= ``` 1. Initialize or access the Datadog OpenFeature provider as described in the [Java](https://docs.datadoghq.com/feature_flags/server/java.md), [Node.js](https://docs.datadoghq.com/feature_flags/server/nodejs.md), or [Python](https://docs.datadoghq.com/feature_flags/server/python.md) setup. This starts CDN polling. No Feature Flags enablement or source setting is required. 1. Store `DD_API_KEY` in the serverless platform's secret manager and expose it only to the application process. The SDK polls the Datadog-managed CDN every 30 seconds by default and uses ETags for unchanged configuration. It preserves the last accepted configuration during temporary errors. If no configuration has been accepted, OpenFeature evaluations return the caller-provided default value. Tracer installation and initialization alone do not start CDN polling. Requests to the CDN contribute to server Feature Flags billing only after application code activates the provider. Agentless mode removes the Datadog Agent dependency for *flag configuration*. It does not remove language-specific tracer requirements. It also does not configure or enable APM and serverless telemetry. You can use the Datadog Lambda Extension, `serverless-init`, an Agent sidecar, or another supported telemetry path independently. ## Send feature flag telemetry{% #send-feature-flag-telemetry %} `serverless-init` is one compatible local telemetry relay. It is not a Feature Flags configuration source. Keep the default `agentless` source to load configuration from the CDN. Do not use `serverless-init` as a replacement for the Datadog Agent when you select `remote_config`. Agent Remote Configuration requires a Datadog Agent. Direct fallback means the SDK sends authenticated EVP events to Datadog when it cannot use a compatible local relay. Note the following behavior: - Experiment exposure events are emitted only for flags associated with an experiment. - Java and Python aggregate EVP flag evaluation events and send them by default. - To disable only the EVP flag evaluation event path, set `DD_FLAGGING_EVALUATION_COUNTS_ENABLED=false`. The `feature_flag.evaluations` metric is a separate OpenTelemetry (OTLP) signal. The standard `serverless-init` connection on port 8126 does not configure the OTLP endpoint for this metric. For no-Agent serverless environments, configure the serverless telemetry path for your platform before you enable this metric. See [Set Up Server-Side Flag Evaluation Metrics](https://docs.datadoghq.com/feature_flags/guide/server_flag_evaluation_metrics.md). ### Configure serverless-init{% #configure-serverless-init %} 1. Complete the [Serverless Monitoring](https://docs.datadoghq.com/serverless.md) setup for your platform. Those instructions provide the supported in-container and sidecar configurations, required environment variables, and network settings. 1. Apply these Feature Flags requirements: - Use `serverless-init` 1.9.13 or later. Earlier versions do not support the required EVP route. - Keep `DD_API_KEY` and `DD_SITE` in the application environment for agentless CDN configuration delivery. A sidecar also needs them for telemetry egress. - Do not configure an endpoint specific to Feature Flags. The SDK uses the standard tracer connection configured by the Serverless Monitoring setup. - Node.js and Java call `GET /info` on the tracer URL to discover the local EVP proxy. Python sends supported EVP events to the same URL without this discovery request. ### Verify telemetry egress{% #verify-telemetry-egress %} 1. Initialize the OpenFeature provider and confirm that it reaches a ready state. 1. Evaluate a flag associated with an experiment, then confirm that the experiment receives an exposure event. 1. When you use a local relay, check the application and `serverless-init` logs for connection errors to port 8126. 1. For Java and Python, confirm that `DD_FLAGGING_EVALUATION_COUNTS_ENABLED` is not set to `false` when you need EVP flag evaluation events. 1. If you use the `feature_flag.evaluations` metric, validate its separate OTLP path with [Set Up Server-Side Flag Evaluation Metrics](https://docs.datadoghq.com/feature_flags/guide/server_flag_evaluation_metrics.md). ## Agent-backed Remote Configuration{% #agent-backed-remote-configuration %} Set `DD_FEATURE_FLAGS_CONFIGURATION_SOURCE=remote_config` to explicitly use the existing Agent Remote Configuration path: ```bash # Serverless application DD_FEATURE_FLAGS_CONFIGURATION_SOURCE=remote_config DD_AGENT_HOST= DD_TRACE_AGENT_PORT=8126 ``` For Java, use compatible `dd-openfeature` and `dd-java-agent` versions. Use version 1.66.0 or later for both components. Configure the Agent with Remote Configuration and the API key: ```bash DD_REMOTE_CONFIGURATION_ENABLED=true DD_API_KEY= DD_SITE= ``` The serverless workload must be able to reach the Agent on a private network, and the Agent must be able to reach Datadog over HTTPS. Do not expose the Agent trace intake publicly. Explicitly selecting `remote_config` enables the Feature Flags Remote Configuration subscription, even if application code does not initialize the provider. These requests contribute to server Feature Flags billing. ## Operational considerations{% #operational-considerations %} - **Cold starts**: Blocking provider initialization waits for the first configuration and can add cold-start latency. Initialize asynchronously if serving caller-provided default values during startup is acceptable. - **Outbound connectivity**: Agentless delivery requires outbound HTTPS access to the Datadog-managed flag configuration service. - **API key ownership**: In agentless mode, the application owns `DD_API_KEY` for configuration. A `serverless-init` sidecar also needs the key for telemetry egress. In `remote_config` mode, the Agent owns the API key. - **Flag updates**: Delivery is eventually consistent. Allow for the SDK polling interval and application startup time when testing changes. - **Last-known-good behavior**: After a configuration has been accepted, temporary network failures or malformed responses do not replace it. - **Runtime support**: Java requires Java 11 or later. For Node.js and Python, check the tracer's runtime compatibility requirements. - **Kill switch**: `DD_FEATURE_FLAGS_ENABLED` defaults to `true`. Set it to `false` to disable the provider and both configuration delivery paths. Evaluations then return caller-provided default values. Datadog-managed agentless delivery is not available for Datadog for Government in these versions. Use Agent Remote Configuration on that site. If your deployment uses `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED`, see [Migrate from the legacy provider setting](https://docs.datadoghq.com/feature_flags/concepts/configuration_sources.md#migrate-an-existing-remote-configuration-setup). ## Environment notes{% #environment-notes %} ### AWS Lambda{% #aws-lambda %} Java, Node.js, and Python Lambda functions can use agentless configuration delivery when they run a minimum SDK version and can reach Datadog over HTTPS. Java functions must load `dd-java-agent` with `-javaagent`, either directly or through `JAVA_TOOL_OPTIONS`. A Java tracing layer can provide this setup. The Datadog Lambda Extension is not required for flag configuration. ### Google Cloud serverless environments{% #google-cloud-serverless-environments %} Java workloads can use agentless configuration delivery on Java 11 or later when the runtime can load `dd-java-agent`. The Java setup for [Cloud Run Functions](https://docs.datadoghq.com/serverless/google_cloud_run/functions/java.md?tab=maven) and [Cloud Run containers](https://docs.datadoghq.com/serverless/google_cloud_run/containers/in_container/java.md) uses `JAVA_TOOL_OPTIONS` to set `-javaagent`. Node.js and Python workloads require a supported tracer runtime. All runtimes require outbound HTTPS access. ### Azure Functions{% #azure-functions %} Java function apps can use agentless configuration delivery on Java 11 or later when the runtime can load `dd-java-agent`. Node.js and Python function apps require a supported tracer runtime. All runtimes require outbound HTTPS access. An external Datadog Agent is only required when `remote_config` is selected. ### Edge runtimes{% #edge-runtimes %} Some edge runtimes do not support the Datadog Node.js tracer APIs required by the Feature Flags provider. Verify tracer compatibility for the target platform before relying on agentless configuration delivery. ## Public API and local evaluation{% #public-api-and-local-evaluation %} The public [Feature Flags API](https://docs.datadoghq.com/api/latest/feature-flags.md) is intended for managing flags and environments. It is not a per-request flag evaluation API for server-side applications. Do not query Datadog APIs from each serverless invocation to evaluate flags. Use the server SDK, which periodically loads flag configuration and evaluates locally. ## Validate your setup{% #validate-your-setup %} Before enabling Feature Flags in production: 1. Confirm the application uses a minimum supported SDK version. For Java, confirm that the JVM loads `dd-java-agent`. 1. For agentless delivery, confirm the application has `DD_API_KEY`, `DD_SITE`, and `DD_ENV`. For Agent Remote Configuration, confirm the Agent has its API key and Remote Configuration enabled. 1. Initialize the OpenFeature provider and check that it reaches a ready state. 1. Change a non-production flag in Datadog and confirm that the workload receives the updated value after the polling interval. 1. Confirm that your application handles caller-provided defaults if configuration is unavailable during a cold start. 1. For telemetry, configure a supported relay and verify each required signal. Use the separate OTLP setup for `feature_flag.evaluations`. ## Further reading{% #further-reading %} Additional helpful documentation, links, and articles: - [Server-Side Feature Flags](https://docs.datadoghq.com/feature_flags/server.md) - [Server SDK Configuration Sources](https://docs.datadoghq.com/feature_flags/concepts/configuration_sources.md) - [Remote Configuration](https://docs.datadoghq.com/remote_configuration.md) - [Serverless Monitoring](https://docs.datadoghq.com/serverless.md)