Deploy and Host n8n with Workers and Task Runners on Railway (queue mode, production n8n 2.0)

n8n is an open source workflow automation platform, and queue mode is how it runs in production. Instead of one container doing everything, the main instance handles the editor and webhooks while workers execute workflows from a Redis queue, and external task runners execute Code node JavaScript and Python in an isolated container. Since n8n 2.0, task runners are enabled by default and Python in the Code node requires task runners in external mode. This template deploys that entire production topology on Railway in one click.

About Hosting n8n in Queue Mode (n8n Docker, self hosted)

A single n8n container works for a handful of scheduled workflows. Under real load it becomes the bottleneck: long executions slow down the editor, webhooks time out during bursts, and one heavy Code node can take the whole instance down. Queue mode splits those responsibilities across services that scale independently.

This template deploys these services, connected over Railway's private network at deploy time:

Main: n8n editor, REST API, webhooks and schedules, exposed on an HTTPS domain. In queue mode it enqueues executions instead of running them.
Worker: pulls executions from Redis and runs the workflows. This is the service you scale.
Task runner (n8nio/runners): executes Code node JavaScript and Python outside the worker process.
Redis: the job queue between main and workers.
PostgreSQL: workflows, credentials and execution history.

Why Deploy n8n with Workers on Railway

Railway bills by resource usage, not by workflow execution. Workers that sit idle cost very little, and when the queue backs up you add replicas without touching the editor. Secrets, the shared encryption key, the runner auth token and every connection string are generated and wired for you.

Option	With n8n queue mode on Railway	With the other option
Single instance n8n	Editor stays responsive, workers scale independently	One container handles UI, webhooks and executions
n8n Cloud	No execution limits, full control of the environment	Priced by executions, no custom runtime
Zapier / Make	Custom code in JavaScript and Python, self hosted	Priced per task or operation, limited code
Manual install (VPS)	Five services wired in one click	You configure Redis, runners, broker, proxy and TLS

Common Use Cases for n8n with Workers and Task Runners

High volume webhooks that must not block the editor or time out during traffic spikes.
Python in the Code node for data processing, parsing and scripting.
AI agents and LLM pipelines with large payloads and long executions.
Data pipelines mixing connectors with custom JavaScript or Python logic.
Teams sharing one instance where the editor has to stay fast while workflows run.
Isolating untrusted or heavy code so a bad script cannot crash a worker.

Dependencies for n8n Queue Mode Hosting

Deployment Dependencies

PostgreSQL for workflows, credentials and execution history. SQLite is not supported in queue mode.
Redis as the job queue.
Worker service(s) running the official n8nio/n8n image.
Task runner service(s) running the official n8nio/runners image.

Implementation Details (environment variables)

Variable	Purpose
`EXECUTIONS_MODE=queue`	Main enqueues executions, workers run them
`N8N_ENCRYPTION_KEY`	Shared by main and workers to read credentials. Never change it
`N8N_RUNNERS_MODE=external`	Code node runs in the separate runner service
`N8N_RUNNERS_AUTH_TOKEN`	Shared secret between n8n and the runner
`N8N_RUNNERS_STDLIB_ALLOW`	Python standard library modules allowed (set on the runner)
`N8N_RUNNERS_EXTERNAL_ALLOW`	External Python packages allowed (set on the runner)
`OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS`	Makes test runs execute on workers like production

Queue mode vs task runners: what each one solves

Queue mode distributes whole workflow executions across workers through Redis. It solves throughput: more executions in parallel, and an editor that stays responsive.

Task runners isolate Code node execution in a separate process or container. They solve safety and flexibility: custom code cannot crash the worker, and Python runs natively.

They solve different problems and are used together in production, which is exactly what this template deploys.

How to use n8n after deploying

Open the public domain of the main service and create the owner account.
Build workflows as usual. Executions are queued and run on the workers automatically.
Use the Code node in JavaScript or Python. Both run on the task runner.
When executions start waiting in the queue, add worker replicas.

Is n8n free? (n8n license and pricing)

The n8n Community Edition is free to self host under the n8n Sustainable Use License, with no execution limits. n8n Cloud starts at $24 per month and is priced by executions. Self hosting on Railway costs only the infrastructure.

Monthly cost of self hosting n8n in queue mode on Railway

A typical project costs around $3-5 per month with usage-based billing. Queue mode runs more services than a single instance, so the baseline is higher, but cost scales with actual load rather than with execution count.

Troubleshooting n8n Workers and Task Runners

"Task request timed out after 60 seconds": almost never slow code. The runner did not connect to the task broker. Check that N8N_RUNNERS_AUTH_TOKEN is identical on both sides and that the broker port (5679) is reachable. If the runner logs do not show it registering with the broker, that is the problem.

Python imports blocked: the allow lists (N8N_RUNNERS_STDLIB_ALLOW and N8N_RUNNERS_EXTERNAL_ALLOW) belong on the runner service, not on main. Set there, they take effect after a redeploy.

Workers cannot read credentials: main and every worker need the same N8N_ENCRYPTION_KEY. Back it up: losing it means re-entering every credential.

A workflow works in production but fails when testing: manual executions run on main unless OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true.

Executions pile up in the queue: add worker replicas. For heavy workflows, more workers with lower concurrency is more stable than one worker with high concurrency.

Community nodes missing after redeploy: set N8N_REINSTALL_MISSING_PACKAGES=true so they are reinstalled on boot.

Frequently Asked Questions (FAQs)

Do I need queue mode? If webhooks time out, the editor slows down during executions or you run heavy workflows, yes. For a few scheduled workflows a day, a single instance is enough.

Do I need task runners to use Python in n8n? In n8n 2.x, Python in the Code node runs through task runners in external mode, which this template provides.

How many workers should I run? Start with one and add replicas when executions wait in the queue.

Can I use extra Python packages? Yes. Allow them with N8N_RUNNERS_EXTERNAL_ALLOW on the runner, and extend the runner image with the packages you need.

Can I migrate from a single instance n8n? Yes. Point the template at the same PostgreSQL data and reuse the same N8N_ENCRYPTION_KEY.

Does queue mode support webhooks? Yes. Main receives webhooks and enqueues them, so bursts do not block the editor.

Related templates

n8n with FFmpeg: queue mode with FFmpeg on the workers for video and audio automation.
Directus: a REST/GraphQL API and admin panel your workflows can read from and write to.

[Updated Oct '26]