Deploy and Host n8n on Railway

n8n is a workflow automation tool: you connect apps, APIs and databases on a canvas, and it runs the result on a schedule, on a webhook, or on demand. This template deploys it in queue mode, the configuration n8n recommends for production, with a dedicated worker process, Postgres and Redis.

About Hosting n8n

Most n8n templates run a single container that both serves the editor and executes workflows. That is the development shape: one long-running execution blocks the UI, and a crash in a workflow takes the editor down with it. This template splits the two.

Four services, all from official upstream images with fully pinned tags:

n8n — the editor and API. Public domain, healthcheck on /healthz.
Worker — the same image running n8n worker. It pulls jobs off the queue and executes them. Its health endpoint is switched on, so Railway restarts it if it wedges instead of leaving it silently idle.
Postgres — workflows, credentials and execution history, on a volume.
Redis — the job queue, on a volume so queued work survives a restart. Private network only; there is no public proxy in front of it.

Everything is pre-configured. There are no fields to fill in on the deploy screen, and every variable carries a description explaining what it does and when to change it.

Details that are easy to get wrong on Railway and are already handled here:

The encryption key for stored credentials is generated once and shared with the worker. Without that the worker cannot decrypt the credentials attached to the jobs it picks up.
N8N_PROXY_HOPS is set to 1. Left at its default, every request looks like it came from Railway's edge, which quietly disables rate limiting and the login-attempt lockout.
The Redis client is told to resolve IPv6 and the private-networking flag Alpine images need is set, so the queue actually connects.
n8n exits when it cannot reach Redis, and its default patience is shorter than a Redis restart. The timeout is raised so a routine restart of the queue is not an outage.
The webhook base URL uses N8N_WEBHOOK_URL, not the deprecated WEBHOOK_URL.

Common Use Cases

Internal integrations: move data between a CRM, a spreadsheet and a database without writing a service for each pair.
Scheduled jobs: nightly reports, syncs and cleanups, with the run history and error output kept for two weeks.
Webhook endpoints: receive a call from a third-party service and act on it — the public domain is provisioned as part of the deploy.
AI pipelines: chain model calls with retrieval and post-processing, where a single run can take minutes and should not block the editor.

Dependencies for n8n Hosting

Deployment Dependencies

n8n — the upstream project, and its official n8nio/n8n image
PostgreSQL for persistent state
Redis as the job queue between the editor and the worker

Implementation Details

Images are pinned to exact versions rather than a moving tag, so an upstream release cannot change what is running under a live project. Bump them deliberately by editing the image in the service settings.
The editor and the worker carry no volume. Nothing on their disk needs to survive a deploy, which is what lets you raise the worker's replica count when one is not enough.
The Code node runs JavaScript. The upstream image ships no Python interpreter, so Python is switched off rather than offered and failing at run time. NODE_FUNCTION_ALLOW_BUILTIN and NODE_FUNCTION_ALLOW_EXTERNAL are present and empty if you want to open the sandbox up.
Execution history is pruned after 14 days by default (EXECUTIONS_DATA_MAX_AGE). This is the setting that decides how fast the Postgres volume fills.
Postgres and Redis are reachable only from inside the project. To connect a client from outside, add a TCP proxy to the service yourself.

Resource Usage and Cost

Four services use roughly 1–1.5 GB of RAM when idle, plus 3 GB of volume. That works out to about $15–25/month on Railway for an instance running light workflows; heavy or frequent executions cost more, and almost all of the difference lands on the worker.

If you only ever run short workflows and want the cheapest possible instance, you can delete the Worker and Redis services and set EXECUTIONS_MODE to regular on the editor — at the cost of everything described at the top of this page.

Why Deploy n8n on Railway?

Railway gives this stack the things it actually needs and nothing it does not: a private network between the four services, volumes for the two that hold state, a public domain with TLS for the editor and its webhooks, and per-service scaling so the worker can grow without touching the editor.

The alternative is a VM with a compose file, where the private network, the certificates, the restart policy and the backups are all yours to maintain. Here they are part of the deploy.