n8n "Extract from File" node with "Extract From PDF" kills the container with exit code 132

TL;DR

My workflow uploads a PDF through a Form node and passes it to the "Extract from File" node set to "Extract From PDF". When I execute it, the whole n8n container dies and restarts with no logs at all. It looks like an out-of-memory error but nothing is written to the logs before the restart.

When to use

You are seeing this: I am self-hosting n8n 1.110.1 in Docker (Ubuntu 24.04, Node 22). Use this skill when you run into "n8n "Extract from File" node with "Extract From PDF" kills the container with exit code 132".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: n8n 1.110.1. If you are on something much newer or older, the details may have shifted.

What was going on

I am self-hosting n8n 1.110.1 in Docker (Ubuntu 24.04, Node 22). My workflow uploads a PDF through a Form node and passes it to the "Extract from File" node set to "Extract From PDF". When I execute it, the whole n8n container dies and restarts with no logs at all. The PDF is only about 300kb. It looks like an out-of-memory error but nothing is written to the logs before the restart. Has anyone seen this and found a way around it?

The fix that worked

It is probably not actually running out of memory. Check what your container exits with and look at dmesg on the host: if you see lines like traps: node[...] trap invalid opcode ... in skia.linux-x64-musl.node and an exit code of 132, that is SIGILL, an illegal CPU instruction, not an OOM kill. The Extract from File node's PDF path pulls in skia as a native dependency, and that module uses CPU instructions that older CPUs like an Intel Celeron J4025 do not support, so the node crashes the process immediately with no logs. That is exactly what happened to several users on NAS-class hardware. n8n shipped a fix in December 2025 after users confirmed a test branch image (ghcr.io/n8n-io/n8n:branch-cat-1945-community-issue-out-of-memory-when-using-extract-from-file-amd64) resolved it on the affected machines, and it was merged into master and released with the latest nightly. So the fix is to update to a release newer than 2025-12-17, ideally latest. If you cannot update or are stuck on the affected hardware, work around it by avoiding the Extract from File node on PDF input and doing the text extraction outside n8n.

Where this came from

https://github.com/n8n-io/n8n/issues/19359

Someone asked: I am self-hosting n8n 1.110.1 in Docker (Ubuntu 24.04, Node 22). My workflow uploads a PDF through a Form node and passes it to the "Extract from File" node set to "Extract From PDF". When I execute it, the whole n8n container dies and restarts with no logs at all. The PDF is only about 300kb. It looks like an out-of-memory error but nothing is written to the logs before the restart. Has anyone seen this and found a way around it? The verified resolution: It is probably not actually running out of memory. Check what your container exits with and look at dmesg on the host: if you see lines like traps: node[...] trap invalid opcode ... in skia.linux-x64-musl.node and an exit code of 132, that is SIGILL, an illegal CPU instruction, not an OOM kill. The Extract from File node's PDF path pulls in skia as a native dependency, and that module uses CPU instructions that older CPUs like an Intel Celeron J4025 do not support, so the node crashes the process immediately with no logs. That is exactly what happened to several users on NAS-class hardware. n8n shipped a fix in December 2025 after users confirmed a test branch image (ghcr.io/n8n-io/n8n:branch-cat-1945-community-issue-out-of-memory-when-using-extract-from-file-amd64) resolved it on the affected machines, and it was merged into master and released with the latest nightly. So the fix is to update to a release newer than 2025-12-17, ideally latest. If you cannot update or are stuck on the affected hardware, work around it by avoiding the Extract from File node on PDF input and doing the text extraction outside n8n. Thread: https://vectle.com/threads/thr_nff-p6uQ2Lt43leQI-w3mg