Deploy and Host N8N on Railway

This variant: n8n queue mode with workers and webhook processors, behind one URL. n8n's full scaling architecture: dedicated processes for the editor, for incoming webhooks and for executions. n8n is an open-source workflow automation platform with 400+ integrations, AI agent nodes and a visual editor: a self-hosted alternative to Zapier and Make with no per-execution fees.

About Hosting N8N

This template deploys six services:

Caddy: the only public service. It sends production traffic (/webhook/*, /webhook-waiting/*, /form/*, /form-waiting/*, /mcp/*) to n8n-webhook and everything else to n8n.
n8n: the editor, API, schedules and test webhooks. Production webhooks are switched off here.
n8n-webhook: receives production webhooks, forms and MCP calls, and queues them.
n8n-worker: runs every execution.
Redis and Postgres: the job queue, and all persistent data.

Every n8n service is pinned to 2.40.7. The first boot runs n8n's database migrations, which takes about a minute. Then open the public URL and create the owner account right away: the first visitor to an unclaimed instance becomes its owner.

Common Use Cases

Take high webhook volume (payments, form submissions, chatbots) without the editor slowing down
Keep production traffic isolated from people building workflows
Scale webhook intake and execution capacity independently

Dependencies for N8N Hosting

Nothing to bring. Every secret (Postgres and Redis passwords, n8n encryption key) is generated at deploy time.
Optional: API keys for the services your workflows connect to, added later as n8n credentials.

Deployment Dependencies

n8n: https://github.com/n8n-io/n8n
Docker image: https://hub.docker.com/r/n8nio/n8n
Webhook processor docs: https://docs.n8n.io/hosting/scaling/queue-mode/#webhook-processors
Caddy: https://caddyserver.com

Implementation Details

Why one URL and a router. n8n's webhook processors only serve production webhooks; test webhooks (/webhook-test/*, used by "Listen for test event") only exist on the main instance. n8n shows both kinds of URL on a single base, so giving the webhook processor its own domain breaks one of them. Caddy routes by path on one domain, which is the load-balancer setup n8n's docs describe:
```
@production path /webhook/* /webhook-waiting/* /form/* /form-waiting/* /mcp/*
handle @production {
	reverse_proxy {$WEBHOOK_UPSTREAM}
}
handle {
	reverse_proxy {$MAIN_UPSTREAM}
}
```
Other N8N variants. This creator also publishes n8n with Postgres only, queue mode with workers only, a single-service SQLite version, and a version with external task runners for Python Code nodes.
Scaling. Add replicas to n8n-worker and n8n-webhook in their settings. If you use the MCP Server Trigger, keep n8n-webhook at one replica: n8n needs every /mcp connection on the same instance.
Shared settings. Webhook processors and workers read N8N_ENCRYPTION_KEY, the URLs and the timezone from n8n by reference. Back up the encryption key: without it, stored credentials cannot be decrypted.
No volumes on n8n services. Binary data lives in Postgres (n8n's queue-mode default) and N8N_REINSTALL_MISSING_PACKAGES=true reinstalls community nodes on boot.
Custom domain. Attach it to Caddy, then set N8N_EDITOR_BASE_URL and N8N_WEBHOOK_URL on n8n to https://your-domain.
Upgrading. All three n8n services must run the same version. Change the n8nio/n8n tag on each, then redeploy them together.

Why Deploy N8N on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying N8N on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.