Deploy and Host n8n on Railway

n8n is a fair-code workflow automation platform — a self-hostable alternative to Zapier and Make that connects 400+ apps, APIs, and databases through a visual node editor, with full code escape hatches when drag-and-drop isn't enough. This template deploys a lean, durable setup: a single n8n instance backed by PostgreSQL, so your workflows and credentials survive every redeploy without the cost and complexity of a full multi-worker cluster.

What This Template Deploys

Both services run on Railway's private network with credentials injected automatically. A persistent volume holds n8n's encryption key and local files. No Redis, no worker pool — the simplest shape that still keeps your data safe.

About Hosting n8n

The default n8n runs on SQLite, and on a container platform that is a trap: SQLite lives on the local filesystem, so a redeploy can wipe your execution history, and it locks up under concurrent writes. The fix is PostgreSQL. This template wires it in from the start, so workflows, credentials, and history persist properly.

There is one variable that matters more than any other: N8N_ENCRYPTION_KEY. n8n encrypts every stored credential with it. Generate it once, keep it stable, and back it up somewhere safe — because if it changes or is lost, every credential in your instance becomes permanently unreadable and you re-enter them all by hand. This template sets a persistent key and stores it on the volume so a redeploy doesn't regenerate it, which is the single most common way self-hosted n8n users lose access to their work.

This is a single-instance deployment by design. It runs one n8n process that serves the editor, the API, and webhooks together — ideal for personal automation and small-team workflows, and the cheapest durable way to run n8n. When you outgrow it and need to process high volumes in parallel, n8n's queue mode with dedicated workers and Redis is the next step, and this instance's data migrates to it cleanly.

Typical cost: ~$5–10/month on Railway's Hobby plan for n8n and Postgres — versus n8n Cloud's paid plans that meter executions. Self-hosting removes per-execution caps entirely; you pay only for the compute you use.

How It Compares

Zapier and Make lead on sheer integration count and polish. n8n wins on flat pricing, custom-code flexibility, and keeping your workflow data and API keys on infrastructure you own.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — n8n and PostgreSQL build automatically (~3 minutes)
2. Confirm N8N_ENCRYPTION_KEY is set and the volume is mounted at /home/node/.n8n
3. Set WEBHOOK_URL to your Railway public domain so webhook nodes generate correct URLs
4. Open your Railway URL and create the first owner account
5. Build a workflow, add credentials, and run a test execution

No SQLite-to-Postgres migration, no DevOps setup, no reverse proxy to configure.

Common Use Cases

• Zapier / Make replacement — run unlimited automations at a flat cost instead of paying per task or operation
• AI agent workflows — chain LLM calls, tools, and data sources visually, storing chat and execution logs in Postgres
• API and webhook orchestration — receive webhooks, transform payloads, and fan out to other services
• Scheduled data jobs — sync databases, generate reports, and move data between systems on a cron schedule
• Internal tooling — wire together the SaaS apps your team already uses without writing a backend
• Notification and alerting pipelines — route events from your stack into Slack, email, Telegram, or Discord

Configuration

N8N_ENCRYPTION_KEY is the one to protect. It encrypts every credential in your instance. Keep it stable across redeploys and store a copy somewhere safe — if it's lost, all saved credentials become permanently unreadable.

Set WEBHOOK_URL to your real domain. Webhook and OAuth callback URLs are generated from it. If it's wrong, external services can't reach your workflows.

Dependencies for n8n Hosting

• Railway account — Hobby plan (~$5–10/month) covers n8n and Postgres
• A persistent Railway volume for the encryption key and local files (included)
• Optional: SMTP credentials for the email node and user invitations
• Optional: Redis and worker services later, if you migrate to queue mode for scale

Deployment Dependencies

• n8n GitHub Repository
• n8n Documentation
• n8n Environment Variables Reference
• Railway n8n Guide

Implementation Details

The template runs the official n8nio/n8n image on port 5678 against a Railway PostgreSQL service. DB_TYPE is set to postgresdb and the connection values come from Railway reference variables, so n8n creates its tables in Postgres on first boot rather than falling back to SQLite. A Railway volume is mounted at /home/node/.n8n, which holds the encryption key and local settings that must persist across redeploys.

N8N_ENCRYPTION_KEY is set explicitly and stored on the volume so it is not regenerated on redeploy — the failure mode that renders stored credentials unreadable. This single-instance shape runs the editor, API, and webhook handling in one process, which keeps both the architecture and the Railway bill minimal.

For high-volume, parallel execution, n8n supports queue mode with a Redis broker and dedicated worker and webhook services. That is a heavier and more expensive topology; this template deliberately targets the durable single-instance case, and its Postgres data carries over cleanly if you later scale up.

Frequently Asked Questions

Why Postgres instead of the default SQLite? SQLite lives on the local filesystem, so a redeploy can wipe execution history, and it locks under concurrent writes. Postgres persists your data properly and handles real workloads. This template uses it from the first deploy.

What is N8N_ENCRYPTION_KEY and why does it matter so much? n8n encrypts every stored credential with it. If the key changes or is lost, all saved credentials become permanently unreadable and must be re-entered. Keep it stable and back it up — this is the most common way self-hosted users lose their work.

Do my workflows survive a redeploy? Yes. Workflows, credentials, and history live in Postgres, and the encryption key and local files live on the mounted volume. Both persist across redeploys.

Is this really the cheapest way to run n8n with a database? It's the cheapest durable shape — one n8n process plus Postgres, no Redis or worker pool. The multi-worker queue-mode templates cost more because they run more services. If you don't need parallel high-volume execution, you don't need them.

Can I run Python in Code nodes? Yes, via external task runners. Set N8N_RUNNERS_ENABLED=true; the default JavaScript runner works out of the box.

When should I move to queue mode? When a single process can't keep up — long workflows blocking the UI, or webhook ingestion falling behind. At that point add Redis and worker services; your Postgres data migrates cleanly to the larger setup.

My webhooks aren't triggering — why? Almost always because WEBHOOK_URL doesn't match your actual Railway domain. Set it exactly, including the scheme, so n8n generates reachable webhook URLs.

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 get durable workflow automation at the lowest sensible cost — one n8n instance and PostgreSQL pre-wired over a private network, automatic HTTPS, a persistent encryption key, and a clean path to queue mode when you outgrow it. Automate everything, keep your workflows and API keys on infrastructure you own, and skip the per-execution billing of hosted automation tools.