Serverless Environments

Docs > Feature Flags > Implementation Patterns > Serverless Environments

Overview

Datadog Feature Flags server SDKs receive flag configuration through Remote Configuration. The Datadog Agent is required for this flow: it connects to Datadog, receives signed Remote Configuration payloads, validates those payloads, and makes the resulting feature flag configuration available to the Datadog SDK in your application.

After the SDK receives the payload, flag evaluation happens locally in your application. The SDK does not make a network request to Datadog for each flag evaluation.

Serverless runtimes that cannot run or reach a Datadog Agent do not support Feature Flags server SDK payload delivery.

Agent-backed architecture

Some serverless workloads can be configured to reach private network resources. In those environments, you may be able to route tracer traffic to a Datadog Agent running on stateful infrastructure, such as EC2, ECS, EKS, a Google Compute Engine VM, GKE, an Azure VM, or AKS. This pattern depends on your cloud networking, runtime, and SDK support. Validate it in a non-production environment before relying on it for feature flag delivery.

Configure the Agent with Remote Configuration enabled. The Agent uses the full-word Remote Configuration variable:

    DD_REMOTE_CONFIGURATION_ENABLED=true
    DD_API_KEY=<DATADOG_API_KEY>
    DD_SITE=<DATADOG_SITE>
    

Configure the serverless application to use the Agent as its trace Agent endpoint and enable the Feature Flags provider:
```
    DD_AGENT_HOST=<PRIVATE_AGENT_HOSTNAME_OR_IP>
    DD_TRACE_AGENT_PORT=8126
    DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
    
```
The EXPERIMENTAL_ prefix is retained for backwards compatibility; the provider itself is stable.
Some language tracers also support or require a tracer-side Remote Configuration setting, such as DD_REMOTE_CONFIG_ENABLED=true. This is separate from the Agent’s DD_REMOTE_CONFIGURATION_ENABLED setting. See the language-specific Feature Flags server SDK setup for the variables required by your SDK.

Configure the standard service tags used by the server SDK:

    DD_SERVICE=<YOUR_SERVICE_NAME>
    DD_ENV=<YOUR_ENVIRONMENT>
    DD_VERSION=<YOUR_APP_VERSION>
    

Use the language-specific Feature Flags server SDK setup after the Agent connection is available. See Server-Side Feature Flags for setup by language.

Operational considerations

Treat the Datadog Agent as part of the runtime dependency chain for server-side flag delivery:

Network path: The serverless workload must be able to reach the Agent on the trace Agent port, typically 8126. The Agent must be able to reach Datadog over HTTPS.
Private connectivity: Keep the Agent endpoint on a private network. Do not expose the Agent trace intake publicly.
High availability: If the Agent is unavailable during startup, SDKs use default values until the first configuration payload is available. Run enough Agent capacity for the serverless workload’s concurrency and availability requirements.
Cold starts: Blocking provider initialization can increase cold-start latency. If startup latency is more important than immediately serving remote flag values, initialize asynchronously and rely on defaults until the provider is ready.
Flag updates: Remote Configuration delivery is eventually consistent. Allow for the Agent polling interval and SDK startup time when testing a newly changed flag.

Environment notes

AWS Lambda

AWS Lambda does not support direct Feature Flags server SDK payload delivery through the Datadog Lambda Extension alone. The Lambda Extension can collect telemetry, but it is not a replacement for the Agent Remote Configuration path required by Feature Flags server SDKs.

If the Lambda function runs in a VPC and can reach private infrastructure, you can validate an Agent-backed architecture with a Datadog Agent running on stateful infrastructure, such as EC2, ECS, or EKS. Configure the function’s Agent endpoint and Feature Flags provider settings as described in Agent-backed architecture.

For Java Lambda functions, the Java Feature Flags SDK expects the Datadog Java tracer runtime to receive Remote Configuration from the Agent. Native-image builds, such as Quarkus native or GraalVM AOT applications, are not a supported direct path for Java Feature Flags server SDK payload delivery.

Google Cloud Run services

Cloud Run services can use Datadog serverless monitoring instrumentation, including in-container and sidecar approaches for telemetry. Remote Configuration for Feature Flags server SDKs is not supported directly in Cloud Run managed services. If your Cloud Run service can reach private network resources, validate an external Agent-backed architecture in a non-production environment before using it for feature flag delivery.

Google Cloud Run functions and Cloud Functions

Cloud Run functions and Cloud Functions do not support direct Feature Flags server SDK payload delivery. If your networking model allows access to a private Agent endpoint, validate the Agent-backed architecture before relying on it. Otherwise, rely on application defaults.

Azure Functions

Azure Functions do not support direct Feature Flags server SDK payload delivery. If the function app can reach private Azure infrastructure, validate an Agent-backed architecture with the Agent on an Azure VM, AKS, or another supported stateful compute environment.

AWS Fargate and container tasks

If your serverless container environment lets you run a Datadog Agent sidecar or otherwise connect to a supported Agent, use the standard server SDK setup. In this model, the task or service behaves like any other application connected to an Agent with Remote Configuration enabled.

Managed edge and function platforms

Platforms such as Vercel Functions, Netlify Functions, and Cloudflare Workers do not provide a supported Agent runtime or private Agent connection model for Feature Flags server SDKs. These platforms are not supported for server-side Feature Flags payload delivery.

Public API and local evaluation

The public Feature Flags API 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 with an Agent-backed Remote Configuration path when available. If no Agent path is available, use application-owned defaults or static configuration. This fallback is outside Remote Configuration delivery and does not provide signed payload validation or live updates.

Validate the Agent-backed architecture

Before using an external Agent endpoint for serverless feature flag delivery:

Verify that the Agent has Remote Configuration enabled with datadog-agent status.
Confirm that the serverless workload can connect to the Agent trace endpoint.
Initialize the OpenFeature provider and check that it reaches a ready state.
Change a non-production flag in Datadog and confirm that the serverless workload receives the updated value after the Remote Configuration polling interval.