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 is the lightest possible way to run it: one service, no database container, using n8n's built-in SQLite store on a persistent volume. It's the cheapest self-hosted n8n that doesn't lose your work.

What This Template Deploys

One container. A Railway volume mounted at /home/node/.n8n holds the SQLite database, the encryption key, and local files — so everything survives redeploys without a separate database service to pay for.

About Hosting n8n

n8n stores its workflows in SQLite by default, and on a container platform that is either perfectly fine or a disaster, depending on one thing: whether the storage directory is on a persistent volume. Without a volume, /home/node/.n8n is ephemeral and a single redeploy wipes every workflow and credential you've built. With one, SQLite is a legitimate production store for personal and low-volume use.

This template mounts that volume. Your workflows, credentials, and execution history live on it and persist across restarts, redeploys, and upgrades.

The variable that matters most is N8N_ENCRYPTION_KEY. n8n encrypts every stored credential with it. Set it once, keep it stable, and back it up — if it changes or is lost, every saved credential becomes permanently unreadable and you re-enter them all by hand. This template pins it explicitly rather than letting n8n regenerate one, which is the single most common way self-hosted users lose access to their work.

SQLite's limit is concurrency: it locks the database on writes, so many simultaneous executions will queue behind each other. For one person or a small set of scheduled workflows that never matters. For heavy parallel processing, move up to PostgreSQL.

Typical cost: ~$5/month on Railway's Hobby plan — one service, no database container, no per-execution billing.

Which n8n Setup Do You Need?

Start here if you're one person automating your own stack. Move to Postgres when concurrent executions start queueing, and to queue mode when a single process can't keep up. Workflows export and import cleanly between all three.

Deploy in Under 5 Minutes

1. Click Deploy on Railway and wait for the build (~2 minutes)
2. Confirm the volume is mounted at /home/node/.n8n — without it, everything is lost on redeploy
3. Confirm N8N_ENCRYPTION_KEY is set, and save a copy somewhere safe
4. Set WEBHOOK_URL to your Railway public domain so webhook nodes generate correct URLs
5. Open your Railway URL, create the owner account, and build your first workflow

No database to provision, no DevOps setup, no reverse proxy.

Common Use Cases

• Personal automation — connect the apps and APIs you use daily without paying Zapier per task
• Scheduled jobs — nightly syncs, report generation, and cron-driven data movement
• Webhook handling — receive events from services, transform payloads, and forward them onward
• AI workflows — chain LLM calls and tools visually for personal agents and assistants
• Notification routing — push alerts from your stack into Slack, Telegram, Discord, or email
• Prototyping automations — build and test workflows cheaply before scaling to a larger setup

Configuration

The volume at /home/node/.n8n is everything. Your SQLite database, encryption key, and local files all live there. Without it, a redeploy erases every workflow and credential.

Enable execution pruning. SQLite grows with every run. Setting EXECUTIONS_DATA_PRUNE=true keeps the database small and responsive over months of use.

Dependencies for n8n Hosting

• Railway account — Hobby plan (~$5/month) runs the single service
• A persistent Railway volume mounted at /home/node/.n8n (included)
• Optional: SMTP credentials for the email node
• Optional: a PostgreSQL service later, if you outgrow SQLite

Deployment Dependencies

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

Implementation Details

The template runs the official n8nio/n8n image on port 5678 as a single service. DB_TYPE stays at sqlite, and a Railway volume mounted at /home/node/.n8n holds database.sqlite, the encryption key, and any local files n8n writes — so a single volume covers the entire application state and there is no separate database service.

N8N_ENCRYPTION_KEY is set explicitly rather than left to auto-generate. n8n writes a key into its config directory on first boot, but pinning it as an environment variable guarantees it survives even if the volume is ever recreated, which is the failure mode that renders stored credentials unreadable.

SQLite serialises writes, so parallel executions queue rather than running concurrently. That is invisible for scheduled jobs and personal automations, and becomes noticeable under sustained multi-user load — the point at which moving to PostgreSQL is worth it. Workflows and credentials export cleanly, so upgrading later is a migration you control rather than a rebuild.

Frequently Asked Questions

Do my workflows survive a redeploy? Yes, because the SQLite database sits on the mounted Railway volume. Without that volume they would not — it's the single most important part of this setup.

Is SQLite good enough for production? For personal use and low-volume scheduled workflows, yes. It serialises writes, so heavy concurrent execution will queue. That's the signal to move to PostgreSQL.

What is N8N_ENCRYPTION_KEY and why does it matter so much? n8n encrypts every stored credential with it. If it changes or is lost, all saved credentials become permanently unreadable and must be re-entered. Keep it stable and back it up.

How is this different from the Postgres n8n template? This runs one service with SQLite; that one runs two services with PostgreSQL. This is cheaper and simpler; that one handles concurrent executions better. Workflows move between them cleanly.

Will the database grow forever? It will unless you prune. Set EXECUTIONS_DATA_PRUNE=true and an appropriate EXECUTIONS_DATA_MAX_AGE to discard old execution records automatically.

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 URLs.

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

How do I move to PostgreSQL later? Export your workflows and credentials from the UI, deploy the Postgres-backed setup, and import them. Keep the same N8N_ENCRYPTION_KEY so credentials decrypt correctly.

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 workflow automation at the lowest possible cost that still keeps your data — one service, a persistent volume, a pinned encryption key, automatic HTTPS, and a clean upgrade path when you outgrow it. Automate everything, own your workflows and API keys, and skip per-execution billing entirely.