How to Deploy n8n on Railway: A Production Setup Guide

Railway is a good answer to the n8n hosting question for a lot of businesses — Postgres add-on with a click, no Kubernetes overhead, sensible defaults, and a deployment model that doesn't require you to think about infrastructure most of the time. It's not the cheapest option at scale, and it's not always the right answer. This guide covers how to set it up for real production workloads, what to watch out for, and where it stops being the right call.

The setup below is what I use on production n8n deployments running real-time integrations into accounting, banking, and operational systems. None of it is theoretical.

Why Railway works for n8n

Three things make Railway a sensible host for n8n specifically:

1. Native Postgres add-on. n8n needs a database for anything beyond toy workloads. Railway's Postgres provisioning is a button click — connection string, backups, and persistence handled. No separate provider to manage credentials across.
2. No Kubernetes overhead. Railway runs your containers without exposing the orchestration layer. For a self-hosted n8n instance running 10–50 workflows, that's the right level of abstraction. Heroku-style simplicity, modern infrastructure underneath.
3. Sensible scaling primitives. Vertical scaling (more CPU/RAM per container) for the n8n main service. Horizontal scaling via queue mode workers when you actually need it — most deployments won't, but the option is there.

What it's not good at: low-cost long-tail workloads. If you're running n8n with five workflows that fire weekly, a single Hetzner VPS at €5/month is cheaper. Railway's usage-based pricing rewards consistent moderate workloads, not occasional ones.

What you need before you start

Three things in place before you spin anything up:

• A Railway account. Sign up via railway.com — they have a starter trial credit, then it's usage-based [?]. Verify current pricing on their site; their billing model has changed before.
• An understanding of n8n's licensing. n8n is fair-code under the Sustainable Use License. Self-hosting for your own internal automation is fine; reselling n8n itself as a hosted product is not. Read their terms if there's any doubt — most consulting use is fine.
• A backup destination. You need somewhere outside Railway to ship workflow exports and Postgres backups to. Object storage somewhere (R2, B2, S3) works. Don't skip this — Railway's own backups are insurance against database loss, not against you accidentally deleting workflows.

Deploying n8n on Railway

The fastest path is via Railway's template gallery, but the template is opinionated about defaults that don't all match production needs. Going slightly manual gives you a cleaner setup:

Step 1: Create the project and add Postgres

Create a new Railway project. Add a Postgres service to it (Add → Database → PostgreSQL). Railway provisions an instance with a connection string automatically. Note the values — you'll wire them into n8n shortly.

Step 2: Deploy n8n as a Docker service

Add a new service in the same project (Add → Empty Service or Deploy from Docker Image). Use n8nio/n8n:latest as the image. For production, pin to a specific version tag (e.g. n8nio/n8n:1.65.0) so you control upgrades rather than getting them at deploy time.

Step 3: Configure environment variables

In the n8n service's Variables tab, add the following. Anything marked critical must be set before the first deploy — changing them later (especially the encryption key) corrupts your credentials store.

Variable	Value	Notes
DB_TYPE	postgresdb	Tells n8n to use Postgres, not the default SQLite
DB_POSTGRESDB_HOST	${{Postgres.PGHOST}}	Railway template variable references the Postgres service
DB_POSTGRESDB_PORT	${{Postgres.PGPORT}}
DB_POSTGRESDB_DATABASE	${{Postgres.PGDATABASE}}
DB_POSTGRESDB_USER	${{Postgres.PGUSER}}
DB_POSTGRESDB_PASSWORD	${{Postgres.PGPASSWORD}}
N8N_ENCRYPTION_KEY	Random 32+ char string	CRITICAL — generate once, store in a password manager, never change. Loses credential decryption if rotated.
WEBHOOK_URL	https://your-domain.com/	CRITICAL — must be the external URL n8n is reachable at. Webhooks generated by n8n use this as the base.
N8N_HOST	your-domain.com	The hostname n8n binds to
N8N_PROTOCOL	https
N8N_PORT	5678	The internal port; Railway maps this externally
GENERIC_TIMEZONE	Africa/Johannesburg	Or your operational timezone
N8N_RUNNERS_ENABLED	true	Recommended for performance from n8n v1.65+

Railway's template variable syntax (${{Postgres.PGHOST}}) automatically wires the Postgres service to n8n without you copying connection strings manually. Use it.

Step 4: Attach a custom domain

In the n8n service's Settings → Networking, add a custom domain. Railway provides a your-project.up.railway.app URL by default; for production you'll want a real domain (e.g. n8n.yourcompany.com) for trustworthy webhook URLs and easier SSL management. Railway handles SSL via Let's Encrypt automatically once the CNAME is set.

Once the domain is live, update WEBHOOK_URL and N8N_HOST to match. Redeploy.

Step 5: First login and credential migration

Open your domain in a browser. n8n's first-run flow creates the owner account. Use a real email — n8n uses it for password reset and (with SMTP configured) workflow failure notifications.

If you're migrating from an existing n8n instance, export workflows and credentials from the old instance, then import them via the n8n CLI inside the Railway container. Credentials exported with an encryption key can only be imported into an instance with the same key — which is why you set N8N_ENCRYPTION_KEY deliberately in Step 3.

Production essentials

The default setup is enough to run workflows. The following make it durable over time:

Persistent storage for the n8n volume

n8n stores some operational data on disk (binary file uploads, custom community nodes if installed). On Railway, mount a persistent volume to /home/node/.n8n in the n8n service's Settings → Volumes. Without this, that data evaporates on every redeploy.

Queue mode for higher throughput

For workloads above a few hundred executions per hour, switch to queue mode. This separates the n8n main service from worker processes that execute workflows. The benefits: failed workers don't take down the main service, workers can scale horizontally, and webhook responsiveness improves because the main service isn't blocked by long-running executions.

Setup requires Redis (Railway add-on, button click) and additional environment variables. See n8n's queue mode docs for the specifics — they change occasionally with new releases.

For most consulting-grade deployments (under ~5,000 executions/day), single-service mode is fine. Don't add queue mode until you actually need it.

SMTP for failure notifications

Wire n8n's email settings (N8N_EMAIL_MODE=smtp plus host/port/user/password vars) to a real SMTP provider (Resend, Postmark, AWS SES — all have free tiers). Without this, failed workflow executions are invisible unless you're checking the executions tab manually.

For Resend specifically, the SMTP credentials are in your Resend dashboard under SMTP settings; the format slots directly into n8n's variables.

Backups and monitoring

Two layers of protection:

Postgres backups

Railway snapshots Postgres on a schedule [?] — verify current backup policy in their docs, the retention period has changed before. As insurance, set up your own backup: a scheduled job that runs pg_dump and ships the output to an external object store (Cloudflare R2 is cheapest, B2 is fine, S3 works).

The simplest implementation is an n8n workflow itself: a Cron node firing daily, an Execute Command node running pg_dump, an HTTP node uploading to R2's S3-compatible API. Self-contained, runs in the same environment as everything else.

Workflow exports

n8n's REST API can list and export all workflows as JSON. Run this nightly and ship the exports to object storage alongside the Postgres backups. Recovery from a catastrophic Postgres loss is dramatically faster if you have a recent JSON export of every workflow.

Monitoring

Three things to monitor:

1. n8n service uptime. Use Uptime Kuma (free, self-hostable on the same Railway project, or on Oracle Cloud Free Tier) hitting /healthz every minute.
2. Failed executions. Wire SMTP per above so n8n alerts you on workflow failures.
3. Queue depth. If you go to queue mode, watch the Redis queue depth — sustained backlog means workers are undersized.

Cost reality check

Railway pricing is usage-based: you pay for CPU-seconds and memory-GB-hours consumed, plus database storage and egress [?]. The actual monthly bill depends entirely on workload, but rough benchmarks from real deployments:

• Light deployment (5–10 workflows, occasional triggers, ~500 executions/day): around $5–10/month
• Moderate (20–40 workflows, scheduled + webhook, ~3,000 executions/day): $15–25/month
• Heavier (50+ workflows, queue mode, ~10,000+ executions/day): $30–60/month with workers

Add Postgres usage on top — typically $5–15/month at moderate scale [?].

Confirm current pricing on Railway's site before committing. The numbers above are observational from production deployments and reflect the pricing model as of mid-2026 [?].

When Railway isn't the right answer

Honest list of when to pick something else:

• Very low budget, very low traffic. A €5/month Hetzner VPS running n8n + Postgres in Docker is cheaper than Railway for trivial workloads. Tradeoff: you manage the OS, backups, and SSL yourself.
• You need SA region specifically for latency. Railway doesn't have an SA region as of writing [?]. EU and US regions add 150–250ms latency to SA-bound webhooks. For most n8n use cases (async automation), this doesn't matter. For sub-second webhook responses to a customer-facing app, it might.
• You're price-optimising at scale. At 10,000+ executions per day sustained, dedicated infrastructure (Hetzner dedicated, Oracle Cloud paid tier, AWS reserved instances) is cheaper per execution. The crossover is around the $50–100/month mark.
• You want a fully managed n8n. n8n.cloud exists. It's more expensive but they handle everything including updates. If you don't want to think about infrastructure at all, that's the trade.

For everything in the middle — most SA consulting projects, most SME operational automation — Railway is the answer most of the time.

Disclosure

Railway is a referral link. I use Railway for production n8n deployments and recommend it on technical grounds; the link earns Gainly a small credit if you sign up through it. The recommendation stands regardless of the referral — there's a footer note on this guide that says the same thing.

---

Some links in this guide are affiliate links. If you sign up through them, Gainly may earn a commission — at no cost to you. We only recommend tools we'd recommend regardless.