Hi Railway team,

I’m running a self‑hosted n8n instance on Railway (currently version 2.8.3, with binaryDataMode: filesystem) and after a recent redeploy I hit several issues that left a critical flow (Mistral OCR) down for several hours.​​

Here’s the context and what I observed, so you can review it and possibly improve the template or docs.

Deployment context

• Project with 4 services:

  • Primary (n8n main / editor, with webhooks)

  • Worker (executions in queue mode)

  • Postgres

  • Redis

• Relevant env vars in Primary before changes:

  • EXECUTIONS_MODE="queue"

  • QUEUE_BULL_REDIS_* pointing to the Redis service

  • N8N_DEFAULT_BINARY_DATA_MODE="filesystem"

  • DB_TYPE="postgresdb" and the usual DB vars

• Initial deployment worked fine, including a flow that receives a PDF via Webhook, sends it to Mistral OCR and returns the extracted text.

Issue 1: Binary errors after redeploy

After doing a redeploy of the Primary service only (Worker kept the previous config), flows handling PDF uploads started failing:

1. In the v2 Webhook node I could see the PDF correctly in the Binary tab as file (name, mime type, size ~3.35 MB).​

2. The next node (first the native Mistral OCR node, later an HTTP Request) failed with binary‑related errors, for example:

   json

   { "error": "No binary data manager found for: database" }

   and later:

   json

   { "errorMessage": "File not found", "errorDetails": { "errorExtra": { "filePath": "/home/node/.n8n/storage/workflows/.../binary_data/xxxx" } } } ```[5][6]

My understanding is:

• The Webhook runs on Primary and stores the binary on its local filesystem.

• The flow execution runs on Worker (queue mode), which has a different filesystem, so that path /home/node/.n8n/storage/.../binary_data/... does not exist there.

• Hence the File not found and “binary data manager” issues when using binaryDataMode=filesystem.

What I had to do

To get things working again:

1. Changed EXECUTIONS_MODE from "queue" to "regular" on Primary.​

2. Removed the QUEUE_BULL_REDIS_* variables and disabled the Worker service, so everything now runs on Primary.

After that, binary errors disappeared and the PDF flow started working again, but I had to give up queue mode / worker separation.

Issue 2: Native Mistral OCR node unusable for several hours

At the same time, the native Mistral OCR node in n8n became unstable:

• For a long period it returned internal errors related to reading the uploaded file, similar to the filesystem problems above (it couldn’t find the PDF even though the Webhook showed it in Binary).

• I tried a workaround using an HTTP Request to the new https://api.mistral.ai/v1/ocr endpoint, manually building document.document_url as a data URL data:application/pdf;base64,..., but hit the same low‑level issue: item.binary.file.data held the filesystem-v2 identifier instead of the actual content, which reinforced the suspicion that runner and binary storage weren’t aligned.​​

Once I switched to EXECUTIONS_MODE="regular" and ran everything on a single instance, the native Mistral OCR node started working again without any config changes.

So effectively, the broken Primary+Worker + filesystem setup made the OCR module unusable for several hours.

Issue 3: Python runner for Code node

When using the new Code node (JavaScript/Python), I got this error:

json

{ "errorMessage": "Python runner unavailable: Python 3 is missing from this system", "errorDescription": "Internal mode is intended only for debugging. For production, deploy in external mode: https://docs.n8n.io/hosting/configuration/task-runners/#setting-up-external-mode" }

This makes sense because the n8n image used by the Railway template doesn’t include Python 3. The workaround was:

• Switch Code nodes to JavaScript, or

• Disable the internal Python runner via N8N_PYTHON_RUNNER_DISABLED=true.

I know n8n recommends external Task Runners for Python, but from the Railway template it can be confusing because the Code node shows Python as an option even though the current image has no Python installed.