Issue Station
Sign In
Tools hereToolbox

n8n - 💡(How to fix) Fix n8n Docker image build fails — [email protected] segfaults during npm rebuild on node:24.14.1-alpine [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
n8n-io/n8n#28917•Fetched 2026-04-23 07:44:11
View on GitHub
Comments
2
Participants
2
Timeline
6
Reactions
0
Author
marty-sullivanmarty-sullivan
Participants
marty-sullivanmarty-sullivann8n-assistant[bot]n8n-assistant[bot]
Assignees
shortstackedshortstacked
Timeline (top)
commented ×2assigned ×1labeled ×1mentioned ×1

Error Message

  1. Observe builder stage 3/3 fail at npm rebuild sqlite3 isolated-vm with Segmentation fault (core dumped) followed by gyp ERR! UNCAUGHT EXCEPTION / ENOENT ... node_gyp_bins.

Root Cause

Root cause appears to be that the Dockerfile pins NODE_VERSION=24.14.1 but uses the unpinned node:24.14.1 alpine tag, which has rolled forward to a newer Alpine (now installing gcc 15.2.0-r2,
python3 3.12.13-r0, sqlite-libs 3.51.2). The combination of gcc 15.2 + node-gyp rebuild --release -j max + [email protected] crashes during compilation.

RAW_BUFFERClick to expand / collapse

Bug Description

Building the n8nio/n8n Docker image from the repo Dockerfile (docker/images/n8n/Dockerfile) fails in the builder stage at npm rebuild sqlite3 isolated-vm. The [email protected] native compile terminates with Segmentation fault (core dumped), followed by cascading "No such file or directory" errors on node-gyp dependency files.

Root cause appears to be that the Dockerfile pins NODE_VERSION=24.14.1 but uses the unpinned node:24.14.1 alpine tag, which has rolled forward to a newer Alpine (now installing gcc 15.2.0-r2,
python3 3.12.13-r0, sqlite-libs 3.51.2). The combination of gcc 15.2 + node-gyp rebuild --release -j max + [email protected] crashes during compilation.

The exact same Dockerfile, lockfile, and Node version built successfully for [email protected] — no source changes to docker/ or pnpm-lock.yaml have been made between 2.17.3 and 2.17.5. The build regressed solely because of the upstream Alpine/toolchain drift behind the floating tag.

To Reproduce

  1. Check out [email protected] (or current master).
  2. Run the equivalent of the build:docker script that produces the n8n image, on an x86_64 Linux builder (e.g., AWS CodeBuild Amazon Linux 2 host).
  3. Observe builder stage 3/3 fail at npm rebuild sqlite3 isolated-vm with Segmentation fault (core dumped) followed by gyp ERR! UNCAUGHT EXCEPTION / ENOENT ... node_gyp_bins.

Expected behavior

The Docker image builds reproducibly regardless of when node:24.14.1-alpine was last republished upstream. The [email protected] release should be rebuildable with the same outcome as [email protected].

Debug Info

N/A (build-time failure, instance never starts)

Operating System

Docker

n8n Version

v2.17.5 (regressed from 2.17.3)

Node.js Version

24.14.1

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted

extent analysis

TL;DR

Pin the Alpine version in the Dockerfile to prevent toolchain drift and ensure reproducible builds.

Guidance

  • Identify the specific Alpine version that was used in the successful build of [email protected] and pin it in the Dockerfile.
  • Verify that the pinned Alpine version is compatible with the Node.js version (24.14.1) and the required dependencies (e.g., gcc, python3, sqlite-libs).
  • Consider using a more specific Docker image tag, such as node:24.14.1-alpine3.17, to reduce the likelihood of toolchain drift.
  • Test the updated Dockerfile with the pinned Alpine version to ensure that the build is successful and reproducible.

Example

# Instead of using the floating tag
# FROM node:24.14.1-alpine

# Pin the Alpine version
FROM node:24.14.1-alpine3.17

Notes

The issue is specific to the combination of Node.js version, Alpine version, and dependencies. Pinning the Alpine version may not be the only solution, but it is a likely cause of the problem. Further investigation may be needed to ensure that the pinned version is compatible with all dependencies.

Recommendation

Apply workaround: Pin the Alpine version in the Dockerfile to prevent toolchain drift and ensure reproducible builds. This approach allows for a more controlled and predictable build environment, reducing the likelihood of similar issues in the future.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The Docker image builds reproducibly regardless of when node:24.14.1-alpine was last republished upstream. The [email protected] release should be rebuildable with the same outcome as [email protected].

#optimization#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING