4 months ago
Hi,
I'm running a self-hosted n8n instance on Railway and encountering an issue with downloading large files (video recordings from Google Meet).
The Problem:
When trying to download a 533 MB video file through n8n, I receive this error:
Failed to write binary file because its size of 533.14 MB exceeds the max size limit of 512 MB set for `database` mode.What I've Tried:
I added the environment variable N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE=1073741824 (1 GB) to both my n8n main service and Worker service, then redeployed both services. However, the limit still appears to be 512 MB.
My Setup:
- n8n version: 2.4.8 (Self Hosted)
- Binary data mode: database
- Platform: Railway
Questions:
- Is there a platform-level restriction on Railway that overrides this environment variable?
- Are there any additional steps required to apply this configuration change?
1 Replies
15 days ago
This is probably not a Railway-level override. The value is the problem.
In n8n 2.4.x, N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE is read as a number of MiB, not bytes, and database mode is capped at 1024 MiB. So this:
N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE=1073741824is not the right value for 1 GB. Use this instead:
N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE=1024Set that on every n8n process that can run the workflow, then redeploy all of them:
n8n main service
n8n worker service
webhook service, if you run one separately
any additional queue workersIf one worker is still running with the default config, it can continue failing at 512 MB even though the variable was changed somewhere else.
For your current setup, I would test the smallest fix first:
N8N_DEFAULT_BINARY_DATA_MODE=database
N8N_BINARY_DATA_DATABASE_MAX_FILE_SIZE=1024Then start a new execution. A failed old execution will not be repaired retroactively.
For regular 500 MB video files, though, database mode is not a great long-term storage mode. n8n has to buffer the file and store the binary in the database. If this workflow runs often, move the recording out of n8n storage as early as possible, for example upload it to S3-compatible/object storage in the workflow and keep only the object key or URL in n8n.
Filesystem mode can also help for a single n8n service with a persistent volume, but be careful with your main + worker layout. Separate Railway services do not automatically share the same local filesystem. If a worker writes a file to its own volume and another process later tries to read it from a different service, you can trade the size-limit error for a file-not-found error. For multiple n8n services, database with the correct MiB limit or external object storage is usually the safer path.