Datadog

Qovery creates it as a Helm release on the environment’s own cluster, as a Blueprint service in one of your environments.


Catalog name	`helm-datadog`
Category	Observability
Provider	HELM
Engine	helm
Major versions (latest release)	`7` (3.0.4)
Source	HELM/datadog/7

New to this? You don’t need to know Kubernetes or Helm. Qovery installs Datadog on your cluster with Helm and runs it for you: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment.

Create it

Console
CLI and API
Coding agent

Open the environment, then New service › Blueprint.
Find Datadog in the catalog and pick the major version.
Fill in the variables. Required ones are marked; the others use their defaults.
Create the service, and deploy it now or later.

List the catalog to get the latest tag, then create the service from it. qovery api signs the requests with your CLI session.

ORG_ID="REPLACE_WITH_ORGANIZATION_ID"
ENV_ID="REPLACE_WITH_ENVIRONMENT_ID"

qovery api "organization/$ORG_ID/blueprint/catalog" | jq '.. | objects | select(.name? == "helm-datadog")'

cat > blueprint.json <<'EOF'
{
  "name": "helm-datadog",
  "tag": "HELM/datadog/7/3.0.4",
  "icon": "app://qovery-console/datadog",
  "variables": [
    {
      "name": "datadog_api_key",
      "value": "REPLACE_WITH_DATADOG_API_KEY",
      "is_secret": true
    },
    {
      "name": "datadog_site",
      "value": "REPLACE_WITH_DATADOG_SITE"
    }
  ]
}
EOF
BLUEPRINT_ID=$(qovery api "environment/$ENV_ID/blueprint" --method POST --input - < blueprint.json | jq -r .id)
rm blueprint.json   # it can hold secret values
qovery api "blueprint/$BLUEPRINT_ID/deploy" --method POST
qovery api "blueprint/$BLUEPRINT_ID"   # status of the latest deployment

Replace each REPLACE_WITH_ value. Add optional variables to variables the same way.

Paste this into Claude Code, Cursor, Codex or another coding agent with the Qovery agent skills installed (curl -fsSL https://skill.qovery.com/install.sh | bash).

Prompt

Add the Qovery Blueprint Datadog (helm-datadog) to one of my Qovery environments and deploy it. Ask me for datadog_api_key and datadog_site.
Ask me before deploying to a production environment.
Docs: https://www.qovery.com/docs/configuration/blueprints/helm-datadog.md

You don’t add any file to your repository. Qovery creates the Blueprint from the Console or the API.

Variables and outputs

Generated from qbm.yml at HELM/datadog/7/3.0.4, the manifest the Console form is built from.

All 7 variables

Name	Type	Required	Default	Secret	Description
`datadog_api_key`	string	Yes		Yes	From Organization Settings → API Keys
`datadog_site`	string	Yes	`datadoghq.com`		Datadog site your account belongs to
`cluster_name`	string				Leave empty to use the Qovery cluster name, lowercased and hyphenated. Else lowercase letters, digits, - and _, dot-separated, alphanumeric at both ends.
`enable_logs`	string		`true`		Collect container logs from all pods
`enable_apm`	string		`false`		Enable the APM trace-agent port for application tracing
`agent_memory`	string		`512Mi`		Request and limit of the node agent container, as a Kubernetes quantity
`cluster_agent_memory`	string		`512Mi`		Request and limit of the cluster agent container, as a Kubernetes quantity

Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint’s name; see Aliases Qovery creates for outputs for the naming rules and the cases where no alias is created.

All 1 outputs

Name	Secret	Description
`datadog_cluster_agent_service`		In-cluster Datadog cluster-agent service name

Reference

From the Blueprint’s README. Deploys the Datadog Agent on Kubernetes via the official datadog/datadog Helm chart (3.240.0, Agent v7) — a per-node metrics/logs DaemonSet plus the Datadog cluster agent.

Credentials

A Datadog API key supplied as the sensitive datadog_api_key variable, plus the datadog_site matching your account’s region. Data appears in your Datadog account (no in-cluster endpoint to connect to).

Variables

Required Variables

Name	Type	Sensitive	Description
`datadog_api_key`	string	yes	Datadog API key (Organization Settings → API Keys)
`datadog_site`	string		Datadog site (`datadoghq.com`, `datadoghq.eu`, `us3/us5/ap1`, gov). Default suggestion: `datadoghq.com`.

Optional Variables

Name	Type	Default	Description
`cluster_name`	string	Qovery cluster name	Cluster name tag applied to all Datadog telemetry. Leave empty to use the Qovery cluster’s own name, lowercased and hyphenated. Otherwise: lowercase letters, digits, hyphens and underscores, optionally dot-separated, starting and ending alphanumeric (e.g. prod-eu)
`enable_logs`	string	`true`	Collect container logs from all pods (`true`/`false`)
`enable_apm`	string	`false`	Enable the APM trace-agent port (`true`/`false`)
`agent_memory`	string	`512Mi`	Memory request/limit for the node agent container
`cluster_agent_memory`	string	`512Mi`	Memory request/limit for the cluster agent container

Outputs

Name	Description
`datadog_cluster_agent_service`	In-cluster Datadog cluster-agent service name

Notes

cluster_name is optional and defaults to the actual Qovery cluster name, taken from the qovery_cluster_name variable the engine injects into every blueprint and passed through Tera’s slugify. 1.x defaulted it to the placeholder qovery-cluster, so installs that never touched the field tagged all telemetry with a name matching no real cluster. Slugifying is required because Qovery cluster names are unconstrained while the chart validates this value, so a name carrying uppercase or spaces is lowercased and hyphenated. Set the variable explicitly to use a different tag; an explicit value is passed through unchanged and must satisfy Datadog’s own rule, which the pattern and maxLength mirror: at most 80 characters of lowercase letters, digits, hyphens and underscores, optionally dot-separated, starting and ending with an alphanumeric.
The Datadog Operator is explicitly disabled (datadog.operator.enabled: false). Chart 3.240.0 enables it by default, which adds 7 cluster-scoped CRDs; because CRDs are singular per cluster, the first environment to install would own them and every later Datadog install on that cluster would fail with a Helm ownership error. The agent is deployed directly by this chart, so the Operator was unused. 1.x shipped it.
The Cluster Agent’s admission controller is disabled (clusterAgent.admissionController.enabled: false). Its Service is named <release>-cluster-agent-admission-controller, and since Qovery release names are helm-z<id>-<service name>, a service name longer than 13 characters pushes it past Kubernetes’ 63-character limit and the deploy fails. It injects APM/DogStatsD config only into pods labelled admission.datadoghq.com/enabled=true, which Qovery services do not carry, so nothing is lost — configure tracers as described below. 1.x shipped it enabled.
Service name length. With the admission controller gone the longest suffix the chart appends is -kpi-telemetry-configmap (24 characters), so a Qovery service name above ~24 characters will still breach the 63-character limit on a resource name. Keep the service name short.
Deploys cluster-wide resources (DaemonSet, ClusterRole/Binding, cluster agent) — allowClusterWideResources: true.
Resources are set explicitly for the node agent (agent_memory) and the cluster agent (cluster_agent_memory); tune agent_memory for high-cardinality nodes.
APM: with enable_apm=true, point tracers at the agent on the node (or the datadog.apm socket) per Datadog’s APM setup docs.
Chart pinned to 3.240.0. This is the official Datadog chart (not Bitnami).

Overview

Account & Organization

Clusters & Cloud

Source Control

Projects & Environments

Services

Deployment & CI/CD

Environment Variables & Secrets

Observability

Notifications

Networking & Advanced

Create it

Variables and outputs

Reference

Credentials

Variables

Required Variables

Optional Variables

Outputs

Notes

​Create it

​Variables and outputs

​Reference

​Credentials

​Variables

​Required Variables

​Optional Variables

​Outputs

​Notes

Create it

Variables and outputs

Reference

Credentials

Variables

Required Variables

Optional Variables

Outputs

Notes