Deployment

How the Datadog Agent gets from this repo to a customer host. The story spans operating systems, packaging formats, container images, and Kubernetes / cloud orchestration.

Distributions

Format	Where it's built	Where it lives
deb	Bazel (packages/agent/linux/) and legacy Omnibus	apt repos hosted by Datadog
rpm	Bazel and legacy Omnibus	yum repos hosted by Datadog
MSI	Windows MSI build (packages/agent/windows/, omnibus/config/projects/agent.rb)	Windows download URL
Docker	Dockerfiles/agent/, Dockerfiles/cluster-agent/, Dockerfiles/dogstatsd/	Docker Hub: datadog/agent, datadog/cluster-agent, datadog/dogstatsd
Helm chart	External repo: helm-charts	helm.datadoghq.com
Kubernetes Operator	External repo	helm.datadoghq.com
Lambda extension	cmd/serverless-init/	AWS Lambda layers
Cloud Run / App Service init	cmd/serverless-init/	Distroless container
Chocolatey	chocolatey/	community.chocolatey.org

Build systems

The repository has been migrating from Omnibus (Ruby-driven, legacy) to Bazel (newer). Both still produce shipping artifacts.

• omnibus/ — Ruby DSL describing how to build deb/rpm/MSI packages. The historical home; still in use.
• packages/ — Bazel-driven package definitions. New artifacts go here.
• bazel/ — Bazel toolchains, repository declarations, eBPF macros, code-generation rules.
• tasks/omnibus.py, tasks/package.py, tasks/msi.py — Invoke wrappers around the build steps.

A typical Bazel package build:

bazel build //packages/agent/linux:debian
bazel build //packages/agent/linux:rpm
bazel build //packages/agent/windows:msi

A typical Omnibus build (legacy):

dda inv omnibus.build --base-dir=/some/work-dir

Docker images

Dockerfiles/ contains one subdirectory per shipped image. The Agent image (Dockerfiles/agent/) supports several flavors:

• Standard — the regular host Agent.
• Cluster Agent — Dockerfiles/cluster-agent/.
• DogStatsD Alpine — Dockerfiles/dogstatsd/alpine/.
• Cluster Checks Runner — runs only the Cluster Checks Runner Agent flavor.
• JMX-enabled Agent — bundles JMXFetch.
• Slim variants — without Python checks for memory-constrained deployments.
• eBPF-enabled — for system-probe deployments.

Multi-arch (amd64, arm64) images are produced via Docker buildx in CI.

Kubernetes deployment

The canonical way to run the Agent in Kubernetes is via the Datadog Operator or the Helm chart. Both are external repos. The Operator is the recommended path for new deployments.

A typical setup runs:

• A DaemonSet of node Agents (one Agent + Trace Agent + Process Agent + System Probe per node).
• A Deployment of Cluster Agents (typically 1–2 replicas).
• Optionally a Deployment of Cluster Checks Runners.

The Cluster Agent is the canonical talker to the Kubernetes API for cluster-level metadata, which the node Agents pick up via gRPC.

Helm chart values cover hundreds of knobs corresponding to the Agent's config keys. The Operator additionally manages reconciliation, RBAC, and rolling upgrades.

Serverless deployment

For serverless, the Agent ships as a Lambda extension (or equivalent) — see cmd/serverless-init/. The same model applies to AWS Fargate (sidecar pattern), Cloud Run, and Azure App Service. Each environment has its own bootstrap code under cmd/serverless-init/cloudservice/.

Datadog Installer

The Datadog Installer (cmd/installer/) is the supported way to install and upgrade the Agent on hosts that aren't Kubernetes. It pulls Agent updates over Remote Config and switches the active version atomically.

See Apps: Installer.

CI/CD pipeline

The repository has two CI systems:

• GitLab CI (.gitlab-ci.yml + .gitlab/) — primary. Builds, unit tests, integration tests, packaging, and deploys.
• GitHub Actions (.github/workflows/) — auxiliary. Repo housekeeping, release automation, doc builds, some lints.

GitLab is where builds and packaging actually happen. The full pipeline matrix covers:

• Linux amd64, arm64.
• Windows.
• macOS.
• Multiple kernel versions for eBPF (KMT).
• Multiple Python versions for the Python loader.
• Multiple architectures for Docker.
• E2E tests on AWS / GCP / Azure.

The pipeline is so large that several tasks/*.py modules exist purely to manage it: tasks/pipeline.py, tasks/gitlab_helpers.py, tasks/notify.py.

Release management

• Release branches follow 7.NN.x (where NN is the minor version).
• Each minor has Release Candidates (7.NN.x-rc.M) before the final release.
• Release notes are aggregated from releasenotes/notes/*.yaml into CHANGELOG.rst.
• Release coordination is tooled in tasks/release.py and the release.json file.
• tasks/quality_gates.py and static_quality_gates/ define the static quality gates (binary size, dependency licenses, etc.) that must pass before release.

Multi-Region Failover

For HA-critical customers, the Agent supports Multi-Region Failover (MRF): metrics, logs, and traces flow to a primary intake and to a secondary intake, with automatic failover. Configuration is in forwarder_* and mrf_* keys; implementation in comp/forwarder/defaultforwarder/ and comp/remote-config/rcservicemrf/.

Configuration delivery

Once installed, the Agent receives configuration updates via three mechanisms:

• Local files — datadog.yaml, system-probe.yaml, conf.d/*.
• Environment variables — DD_* overrides.
• Remote Config — pushed by the backend at runtime. See Systems: Remote Config.

This combination is what enables Fleet Automation: a customer can update Agent behavior across thousands of hosts without re-deploying.

Internal tooling

• tasks/omnibus.py, tasks/package.py, tasks/msi.py, tasks/winbuild.py — packaging.
• packaging/ — additional packaging helpers (datadog-installer-related).
• chocolatey/ — Chocolatey package definitions.
• Dockerfiles/ — Docker images.
• bazel/rules/ — Bazel rules for builds.
• tasks/buildimages.py — manages the buildimages used in CI.

Related pages

• Apps: Installer — the installer/upgrader binary.
• Systems: Remote Config — runtime configuration delivery.
• How to contribute: Tooling — dda inv task reference.
• Reference: Configuration — config keys.