datadog-serverless-init

packaged by Chainguard

Chainguard Container for datadog-serverless-init

Datadog serverless-init runs a containerized app and ships its logs, metrics, and traces to Datadog.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/datadog-serverless-init:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The datadog-serverless-init image is comparable to the upstream datadog/serverless-init and gcr.io/datadoghq/serverless-init images: it carries the same serverless-init binary at /datadog-init as its entrypoint, runs as root so the wrapped workload keeps the same runtime identity as upstream, and relies on the system CA bundle for TLS to the Datadog intake.

There are two intentional differences from upstream:

• Tags follow the Datadog Agent version scheme (7.83, 7.82, ...) rather than upstream's serverless 1.x tags, because this binary is built from the datadog-agent source and shares its version stream.
• No /bin/sh and no /dotnet.sh. serverless-init execs the wrapped command directly, so the image ships no shell. It also omits the /dotnet.sh .NET auto-instrumentation helper that upstream includes; the Datadog .NET auto-instrumentation flow for Azure Container Apps copies and runs that helper, so that specific path is not supported here. Follow the manual Datadog .NET tracer installation instead.

Prerequisites

• A Datadog API key (DD_API_KEY) and the destination site (DD_SITE).
• An application to wrap, provided in exec form (there is no shell to interpret shell-form commands).

Getting Started

serverless-init wraps your application: it starts a telemetry sidecar, execs your command, and forwards the command's exit code. Because /datadog-init is the image entrypoint, the container's command is the workload that gets wrapped.

Build an application image on top of this one and provide your command in exec form:

FROM cgr.dev/ORGANIZATION/datadog-serverless-init:latest

ENV DD_API_KEY=<your-datadog-api-key>
ENV DD_SITE=datadoghq.com
ENV DD_SERVICE=my-app

COPY app /usr/local/bin/app
CMD ["/usr/local/bin/app"]

To wrap a command at run time, pass it as arguments:

docker run --rm -e DD_API_KEY=<your-datadog-api-key> \
  cgr.dev/ORGANIZATION/datadog-serverless-init:latest /usr/local/bin/app

Configuration

serverless-init is configured through Datadog's DD_* environment variables. A typical Google Cloud Run or Azure Container Apps deployment sets at least the API key, site, and service metadata:

DD_API_KEY=<your-datadog-api-key>
DD_SITE=datadoghq.com
DD_SERVICE=my-app
DD_ENV=production
DD_VERSION=1.0.0

The sidecar exposes the APM trace receiver on 8126/tcp and DogStatsD on 8125/udp, so tracing and custom-metric libraries in the wrapped application can report to localhost without extra configuration. See the upstream documentation for the full set of options.

Documentation and Resources

• Datadog Serverless Monitoring
• Install serverless-init on Google Cloud Run
• Install serverless-init on Azure Container Apps
• datadog-agent source repository

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.