[BUG] datadog/serverless-init:1.9.10 missing linux/arm64 platform

[thorfi]

Agent version

1.9.10

Bug Report

Release of 1.9.10 has lost the arm64 platform

Reproduction Steps

docker pull --platform linux/arm64 datadog/serverless-init:1.9.10

output:

Error response from daemon: no matching manifest for linux/arm64 in the manifest list entries: no match for platform in manifest: not found

Error response from daemon: no matching manifest for linux/arm64 in the manifest list entries: no match for platform in manifest: not found

https://hub.docker.com/r/datadog/serverless-init/tags

Docker Hub tags screenshot as at 2026-04-15T09:40+10:00

Operating System

Darwin mac 25.4.0 Darwin Kernel Version 25.4.0: Thu Mar 19 19:31:56 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T6030 arm64

[Prince-Mendiratta]

+1

[sam-portia]

+1 this is causing issues for local dev - we initially pinned to 1.9.9, but then that version is impacted by this Go compiler vulnerability

[SamuelMS]

Were ARM64 builds intentionally dropped?

[thorfi]

@SamuelMS

Were ARM64 builds intentionally dropped?

According to datadog support this container is only for Azure and GCP.

However, IMO this is a very short sighted change with zero notice to customers who were already using the linux/arm64 platform version.

We logically want to be able to run the same containers on arm64 as well as amd64, because otherwise we have to build and run very different container setups for cloud and local, which makes no sense.

Very poor form, datadog. Please reconsider.

[Lewis-E]

Hi @thorfi @sam-portia @Prince-Mendiratta -- could you all please provide details on the environments where you are currently using the arm64 image of serverless-init? Is it local mac development for all three of you as per the top level os note or varied use-cases?

[Lewis-E]

We've collected some data on the varied use-cases, and you can expect a .11 with the unofficial arm64 availability added back in within a few days. We'll be looking into a long-term way to support local development specifically. In the meantime, we would strongly encourage opening zendesk tickets for those of you who have not already done so to track this issue

[Prince-Mendiratta]

Hi @thorfi @sam-portia @Prince-Mendiratta -- could you all please provide details on the environments where you are currently using the arm64 image of serverless-init? Is it local mac development for all three of you as per the top level os note or varied use-cases?

@Lewis-E Yeah, local mac development. We're working with Cloudflare Workers.

[Lewis-E]

@Prince-Mendiratta just to be sure I understand-- you're using the arm64 image for local mac development, and then are using logpush/tailworkers/the default integration for cloudflare workers? Or have you found a serverless-init configuration for cloudflare workers? (Would be surprised, given the size limits.)

[thorfi]

We've collected some data on the varied use-cases, and you can expect a .11 with the unofficial arm64 availability added back in within a few days. We'll be looking into a long-term way to support local development specifically. In the meantime, we would strongly encourage opening zendesk tickets for those of you who have not already done so to track this issue

Hi @Lewis-E ! I have opened a Zendesk ticket already. Assuming you can search the titles, it's called "docker container datadog/serverless-init:1.9.10 missing linux/arm64 platform"

Thank you for the good news regarding a .11 with linux/arm64 platform restored, that will be greatly appreciated.

In our case we are nightly building a multi-platform container image in Azure DevOps Pipelines and pushing it to Azure Container Registry, then deploying the linux/amd64 platform version to Azure Container App via Azure Resource Manager and pulling the linux/arm64 platform version to local macOS for developer use (either as a DevContainer or just to run the apps in the same unix environment as production).

Or in my case as the responsible DevOps engineer if I'm debugging/testing container changes then I also build the container image locally on macOS while I'm going through the change/build/test cycle so I don't have to wait on Azure DevOps Pipelines runs each time through the cycle.

For obvious reasons we don't want to have to run a completely different Dockerfile build for macOS as that defeats half the point of having a container image in the first place.

Also - I'm hoping that Azure Container Apps will someday launch support for arm64 (Azure Kubernetes Service arm64 support went General Availability in 2023 and that's the under-the-hood platform that ACA is actually running on) and it would be good to be able to switch to that without changing anything.