Add serverless guidance for Feature Flags server SDKs#37110
Merged
leoromanovsky merged 8 commits intoJun 18, 2026
Conversation
Contributor
Preview links (active after the
|
A-Rindone
reviewed
May 29, 2026
A-Rindone
approved these changes
May 29, 2026
Contributor
|
Opened DOCS-14576 to follow up with editorial review. |
aarsilv
approved these changes
May 29, 2026
- add link to Feature Flags API docs - add alert explaining EXPERIMENTAL_ env var
- add/update further reading links
Avoid commitments or predictions of future functionality, and only cover current capabilities in documentation.
joepeeples
approved these changes
Jun 8, 2026
joepeeples
left a comment
joepeeples
left a comment
Contributor
There was a problem hiding this comment.
I thought I had approved this last week, but GitHub kept the review as pending/in-progress. Approving again, with a couple comments
leoromanovsky
commented
Jun 18, 2026
Comment on lines
+6313
to
+6317
| - name: Implementation Patterns | ||
| url: feature_flags/implementation_patterns | ||
| parent: feature_flags | ||
| identifier: feature_flags_implementation_patterns | ||
| weight: 4 |
Contributor
Author
There was a problem hiding this comment.
@annabfenske For your awareness we have a chicken or egg problem with implementation patterns; I'm moving the doc here based on (#37350).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Feature Flags server SDK documentation did not explain how serverless workloads receive Remote Configuration payloads. Users running on AWS Lambda, Google Cloud Run, Azure Functions, and similar platforms need clear guidance that the Datadog Agent is the supported path for server-side flag payload delivery today, and that deeper serverless support is planned for a future release.
Changes
This PR adds a new Serverless Environments guide under the Feature Flags Implementation Patterns folder. The guide explains the Agent-backed Remote Configuration flow, required environment variables, operational considerations, local evaluation, public API limitations, and validation steps.
It also adds environment-specific notes for AWS Lambda, Google Cloud Run services and functions, Azure Functions, AWS Fargate/container tasks, and managed edge/function platforms. The wording now avoids claiming unverified external-Agent connectivity as confirmed support; it tells users to validate an Agent-backed architecture in a non-production environment before relying on it for feature flag delivery.
The PR adds the Implementation Patterns folder to the Feature Flags left navigation and keeps the server SDK overview linked to the serverless guidance through both inline copy and further reading. It also clarifies that
DD_REMOTE_CONFIGURATION_ENABLEDis the Agent Remote Configuration setting, whileDD_REMOTE_CONFIG_ENABLEDis a tracer-side setting used by some SDKs.Decisions
The guidance stays high level and architecture-focused instead of duplicating language-specific SDK setup. The page explicitly calls out that the public Feature Flags API is for management, not per-request flag evaluation, and that application-owned defaults or static configuration are outside Remote Configuration delivery when no Agent path is available.
The document uses validate-first wording for external Agent patterns, especially for Cloud Run, until those specific deployment models are confirmed separately.
Validation
git diff --check origin/master...HEADconfig/_default/menus/main.en.yamlgit diff --name-only --diff-filter=U