Repository navigation
Azure Function ZIP deployment crashes in amd64 Oryx build on Apple Silicon arm64 #143
Description
Description
On Apple Silicon (arm64), deploying an Azure Function from a ZIP through LocalStack Azure creates an Oryx build container, but the build crashes under QEMU while installing the detected Python runtime.
The Azure Function App and API Management resources are created successfully. The failure occurs specifically during the ZIP deployment/build step.
Environment
- Host: macOS on Apple Silicon
- Host architecture: arm64
- Docker: Docker Desktop 29.9.1
- Docker server architecture: aarch64
- CPUs: 14
- Docker memory: approximately 15.6 GiB
- LocalStack image: localstack/localstack-azure:latest
- LocalStack version: 2026.11.0.dev325
- LocalStack build date: 2026-10-23
- LocalStack build hash: f13a02f08d
- Oryx image: mcr.microsoft.com/oryx/build:github-actions-debian-bookworm-20260415.1
Reproduction
Repository: https://github.com/localstack/localstack-azure-samples
Sample: samples/api-management-function-app/python
With Azure CLI interception enabled:
lstk az start-interception
cd samples/api-management-function-app/python
bash scripts/deploy.sh
The deploy script eventually executes az functionapp deploy with resource group local-rg, function app local-inventory-functionapp-test, source inventory_function.zip, type zip, and async true.
Observed result
The deployment creates a container similar to ls-oryx-build-jguvch. The container starts, but the Oryx build process crashes:
Detected following platforms:
python: 3.11.14
Falling back to CDN for 'python' version '3.11.14'.
Version '3.11.14' of platform 'python' is not installed.
Generating script to install it...
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
The Docker image architecture is image_arch=amd64, os=linux. The container is therefore an amd64 Oryx build running under emulation on an arm64 host.
A previous run with Python 3.12 showed the same class of failure, ending with qemu: uncaught target signal 6 (Aborted).
Additional observations
- Storage Account creation initially exposed a separate LocalStack/Azurite timeout. After a clean Docker/LocalStack restart, Storage creation completed successfully.
- App Service Plan creation completed successfully.
- Function App creation completed successfully.
- API Management service creation completed successfully.
- API Management named value and Function App settings completed successfully.
- Only the Function ZIP deployment/build fails.
- An equivalent native arm64 Azurite container starts in approximately 1 second, so the blocker is not a general Docker startup failure.
- Forcing DOCKER_FLAGS=--platform=linux/arm64 through an lstk environment profile did not change the Oryx image architecture; the generated Oryx image remained amd64 and the same QEMU segmentation fault occurred.
Expected result
The Azure Function ZIP deployment should either run the Oryx build with an arm64-compatible image, provide a documented configuration to select or override the Oryx build image/platform, or fail with a clear unsupported-architecture diagnostic.
Questions
- Is Azure Function/App Service Oryx deployment currently supported on arm64/macOS Apple Silicon?
- Is there a supported configuration to select an arm64 Oryx build image?
- Can the Oryx build image be overridden for Azure Function ZIP deployments?
- Is the amd64 Oryx image expected to work under QEMU on Apple Silicon, or should this sample be restricted to amd64 hosts?
- Could LocalStack detect this architecture mismatch and return a more actionable error?
Activity
Tell Mac users which samples need Rosetta (#145)
paolosalvatori commentedon Nov 11, 2026
Thanks for the detailed report, and sorry for the slow answer. This is addressed in the emulator, in the samples and in the docs. Your questions in order:
Is Oryx deployment supported on arm64 and Apple silicon?
Yes, with Docker Desktop's Rosetta emulation turned on. The function app itself runs natively on arm64, but the emulator builds each code deployment with Microsoft's Oryx build image, which Microsoft publishes for amd64 only (microsoft/Oryx#2133 asks for arm64). In Docker Desktop's settings, under General, select the Apple Virtualization framework as the Virtual Machine Manager (Docker VMM has no Rosetta) and turn on Use Rosetta for x86_64/amd64 emulation on Apple Silicon.
Is there an arm64 Oryx build image, or a way to override the image?
There is no arm64 Oryx build image yet.
LS_AZURE_ORYX_BUILD_IMAGE_TO_USEsets the build image (configuration), but until Microsoft publishes an arm64 variant there is nothing to point it at.DOCKER_FLAGSapplies to the LocalStack container, not to the build containers the emulator starts, which is why--platform=linux/arm64changed nothing.Is the amd64 image expected to work under QEMU?
No. The
oryxbuild tool is a .NET app, and .NET does not support QEMU: the segmentation fault and the abort you saw come from that. Under Rosetta, the build is expected to work.Could LocalStack detect this and fail with an actionable error?
It does now, from
localstack/localstack-azure:latestversion 2026.11.0.dev395 (2026-10-28) on:api-management-function-app/python, then gets itsrequirements.txtinstalled natively, so the deployment should complete even under QEMU.BUILD_EMULATEDwarning the first time a build runs. It says that the build image is amd64-only and that .NET does not support QEMU, and it tells you to turn on Docker Desktop's Rosetta emulation on Apple silicon.The samples and the docs say the same now: every sample whose code is built with Oryx has a note for Macs with Apple silicon in its prerequisites (#145), and so do the Function App and Web App docs.
We could not test this on an Apple silicon Mac ourselves. If you pull the latest image and run the sample again, with Rosetta on or off, please let us know how it goes. The storage account timeout you saw once is a separate problem: if it comes back, please open a new issue with the LocalStack logs.