Deploy and Host n8n on Railway

n8n is an open-source workflow automation tool for connecting APIs, databases and AI models without writing glue code. It ships a visual editor, hundreds of integrations, a REST API and a Code node for custom JavaScript or Python, a self-hosted alternative to Zapier, Make and Workato, with your credentials and execution history staying in your own database.

About Hosting n8n

Most n8n templates run a single container on SQLite. That is fine for a demo and fragile for anything real: one process serves the editor, receives webhooks and runs every execution, so a long job blocks the rest and the database lives on a disk you cannot query. This template runs n8n in queue mode instead. The main instance serves the editor and receives webhooks, a separate worker pulls executions off a Redis queue, and PostgreSQL holds workflows, credentials and execution history. Both n8n processes share one encryption key, which is what lets the worker decrypt stored credentials. Scaling means raising the worker's replica count rather than rebuilding anything, and execution data is pruned after 14 days so the database does not grow unbounded.

Common Use Cases

Run scheduled and webhook-triggered automations that keep responding while a long job is still executing
Build AI agent and RAG pipelines that call LLMs, vector stores and internal APIs
Sync records between a CRM, a database and a spreadsheet on a schedule
Replace per-task Zapier or Make billing with a flat-cost self-hosted runner

Dependencies for n8n Hosting

PostgreSQL for workflows, credentials and execution history
Redis for the execution queue
A persistent volume for the n8n home directory

Implementation Details

Every service runs an official image, so there is no custom Dockerfile to maintain. The main instance and the worker both use n8nio/n8n; the worker runs the same image with the start command 'n8n worker --concurrency=5' and inherits N8N_ENCRYPTION_KEY from the main service by reference. Binary data is stored in the database rather than on disk, so both processes can reach it without an S3 bucket. RAILWAY_RUN_UID is set to 0 so n8n can write to the attached volume, and N8N_PROXY_HOPS is set for Railway's proxy so webhook URLs and rate limiting see the real client address.

No variables need filling in before you deploy. Open the generated URL once it is live and create the owner account on first boot. First boot runs database migrations, so allow a few minutes before the editor answers.

FAQ

Do I need queue mode? If you only ever run a couple of light workflows, no. The moment you have a workflow that takes minutes, or webhooks that must stay responsive while something else runs, a single-container n8n starts timing out and this setup does not.

How do I add more workers? Raise the replica count on the n8n-worker service. Each worker runs five jobs in parallel by default.

Where are my credentials stored? Encrypted in PostgreSQL with the generated N8N_ENCRYPTION_KEY. Keep that value if you ever migrate, or the stored credentials cannot be decrypted.

How do I upgrade n8n? Change the image tag on both the n8n and n8n-worker services to the same new version and redeploy. Database migrations run on boot.

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.