Hello everyone,
I am experiencing a critical crash loop when trying to run any n8n version starting from 2.11.1 (including 2.11.2, 2.12.0, and latest) on an ARM64 architecture. The container crashes immediately after initializing and activating workflows.
My Environment:
OS: Ubuntu 24.04 LTS (Noble)
Architecture: ARM64 (Oracle Cloud Free Tier Ampere instance)
Deployment: Docker Compose (managed via Portainer) behind Traefik
Database: PostgreSQL 13
Failing n8n Versions: 2.11.1, 2.11.2, 2.12.0, latest
Last Working Version: 2.10.4
Symptoms / Logs:
When pulling the latest image, the container starts, successfully connects to the database, and begins activating workflows. However, right after the workflows are activated, the container throws a fatal error and enters an infinite crash loop:
2026-03-10T17:18:44.498Z | info | Activated workflow “Projeto F1B2: 24h Lembrete Entrada Grupo” (ID: DR0I4pvqwerCsZMQ) {“scopes”:[“workflow-activation”],“workflowName”:“Projeto F1B2: 24h Lembrete Entrada Grupo”,“workflowId”:“DR0I4pvqwerCsZMQ”,“file”:“active-workflow-manager.js”,“function”:“activateWorkflow”}
2026-03-10T17:18:44.504Z | debug | No codex available for: stickyNote {“file”:“directory-loader.js”,“function”:“addCodex”}
2026-03-10T17:18:47.968Z | debug | User settings loaded from: /home/node/.n8n/config {“file”:“instance-settings.js”,“function”:“loadOrCreate”}
2026-03-10T17:18:48.277Z | debug | Received CLI command {“execPath”:“/opt/nodejs/node-v24.13.1/bin/node”,“scriptPath”:“/usr/local/bin/n8n”,“args”:,“flags”:{},“file”:“cli-parser.js”,“function”:“parse”}
2026-03-10T17:18:48.281Z | error | Last session crashed {“file”:“crash-journal.js”,“function”:“init”}
Root Cause Analysis:
After some deep troubleshooting, it appears this is caused by a Segmentation fault (core dumped) related to the isolated-vm component introduced in recent versions. The prebuilt isolated-vm native binary seems to be completely incompatible with ARM64 Alpine (musl) environments. Since the official 2.x Docker images are based on Alpine, it instantly kills the container on ARM processors.
Previously, we could easily work around Alpine OS limitations by using the -debian image tags, but it seems these tags are no longer being actively published for the 2.x branch on Docker Hub.
Current Workaround:
Currently, the only way to keep the instance running stably on an ARM64 cloud server is to strictly pin the Docker image to n8nio/n8n:2.10.4, which avoids the isolated-vm crash altogether.
I hope this report helps in addressing the ARM64 musl compatibility issue in upcoming releases, or perhaps consider bringing back the -debian tags for the latest v2 builds to support ARM users. Let me know if I can provide any additional logs or test any specific fixes on my end!