Repository navigation
Azure Function ZIP deployment crashes in amd64 Oryx build on Apple Silicon arm64 #564
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
paolosalvatori commentedon Oct 27, 2026
Hi @eltan148, thanks a lot for the detailed report, it made this much easier to track down.
What's happening
To build a function app (or a web app deployed from code), LocalStack runs Microsoft's Oryx build image,
mcr.microsoft.com/oryx/build, the same build system App Service uses on Linux. Microsoft publishes that image for amd64 only, and theoryxtool inside it is a .NET 8 app.On an Apple Silicon Mac, Docker Desktop runs amd64 images under emulation. It uses Rosetta when "Use Rosetta for x86_64/amd64 emulation on Apple Silicon" is turned on, and QEMU otherwise. The
qemu: uncaught target signal 11 (Segmentation fault)line in your log means your Docker Desktop was using QEMU. Microsoft doesn't support .NET under QEMU ("The QEMU emulator is not supported to run .NET apps", see the .NET 8 supported OS notes), and that's where the build crashed. Thesignal 6 (Aborted)you saw with Python 3.12 is the same failure. Other .NET users hit the same crash on M1 Macs: dotnet/runtime#94909.It also explains why
DOCKER_FLAGS=--platform=linux/arm64didn't change anything: there is no arm64 Oryx image to pull.Can it be fixed?
The root cause is outside our control. It's in Microsoft's image, and only Microsoft can publish an arm64 build of it. The request has been open since 2023: microsoft/Oryx#2133. A 👍 there doesn't hurt.
What we can fix is how LocalStack reacts. When the build crashed under QEMU, the emulator kept waiting for a build container that never exited, and after 30 minutes it failed the deployment. It should have done what it already does on arm64 machines that can't run amd64 images at all: fail the build right away and install the function's Python packages natively. That's why this sample passes on our arm64 CI. We're fixing that in the emulator, and the fix will ship in an upcoming
localstack/localstack-azureimage. We're also adding a note for Mac users to the samples' READMEs: localstack/localstack-azure-samples#145.Workaround for now
Turn on Rosetta in Docker Desktop:
bash scripts/deploy.shagain.With Rosetta, QEMU is out of the picture, and .NET is built to detect Rosetta, so the build should get through. If a deployment is already stuck, you can also run
docker killon itsls-oryx-build-...container (docker ps --filter name=ls-oryx-build). LocalStack then treats the build as failed, installs the Python packages itself and finishes the deployment.The Storage Account timeout you mentioned at the beginning is unrelated. If it comes back, please open a separate issue.
Could you let us know whether it works with Rosetta?
paolosalvatori commentedon Oct 27, 2026
FYI: @gtsiolis @lazarkanelov @mmaureenliu @DrisDary @bryansan-local see my reply ☝️