Self-hosting
Deploy n8n on Railway: Your Own Instance in 10 Minutes
Self-host n8n without touching a server: deploy from Railway's template, set the critical env vars, add a domain, and know what it'll cost.
There’s a gap between “pay n8n Cloud per execution” and “administer a Linux box.” A lot of people fall into that gap: they want their own n8n instance with unlimited executions, but they have no desire to configure firewalls, renew certificates, or babysit a VPS.
That’s the case for Railway. You deploy n8n from a template, Railway owns the infrastructure — servers, TLS, networking, restarts — and you own the instance. No SSH, no Docker Compose files, no Caddy. This guide gets you deployed properly: template, the env vars that actually matter, a domain, and an honest look at costs and trade-offs.
What you’ll need
- A Railway account (GitHub login works).
- 10–15 minutes.
- Optionally, a domain — Railway gives you a usable
*.up.railway.appURL out of the box, so it’s not required to start.
Step 1 — Deploy from the template
In Railway, create a New Project and search the template marketplace for n8n. Pick a template that includes Postgres (some minimal ones run SQLite on a volume; Postgres is the production-shaped choice, and it’s what n8n recommends for anything serious).
Deploying the template creates a project with two services — the n8n app and a Postgres database — already wired together with a persistent volume for n8n’s data directory. Wait for the first deploy to go green.
That’s genuinely most of the setup. The difference between “it deployed” and “it’s set up properly” is the next step.
Step 2 — Set the env vars that matter
Open the n8n service → Variables. Templates pre-fill most of this, but verify these five by hand — they’re the difference between a durable instance and future pain:
# THE one you must control. n8n encrypts all credentials with it.
N8N_ENCRYPTION_KEY=<generate: openssl rand -hex 32>
# Must match the public URL, or webhooks register with wrong addresses.
N8N_HOST=your-app.up.railway.app
N8N_PROTOCOL=https
WEBHOOK_URL=https://your-app.up.railway.app/
# So schedules fire when you expect.
GENERIC_TIMEZONE=Europe/MadridAlso confirm the database variables (DB_TYPE=postgresdb, DB_POSTGRESDB_HOST, etc.) reference Railway’s Postgres service — templates wire these automatically using variable references, which conveniently survive password rotations.
Redeploy the service after changes; n8n reads variables at boot.
Step 3 — Create your account and add a domain
Open the service’s public URL. n8n greets you with the owner account setup — use a strong password and enable two-factor auth immediately (Settings → Personal → Two-factor). On Railway there’s no firewall for you to configure, so the login screen is the entire wall between the internet and your automations.
For a custom domain: service → Settings → Networking → Custom Domain, add n8n.yourdomain.com, create the CNAME record it shows you, and Railway provisions the certificate. Then update N8N_HOST and WEBHOOK_URL to the new domain and redeploy.
Step 4 — Sanity-check with a real workflow
Build a trivial webhook workflow: Webhook trigger → Edit Fields → Respond to Webhook. Activate it and curl the production URL:
curl https://n8n.yourdomain.com/webhook/testA response proves the full chain — DNS, TLS, routing, WEBHOOK_URL config — works end to end. If it does, you’re production-ready. (If you’re new to n8n itself, continue with your first real AI workflow.)
What it costs
Railway bills a small subscription plus usage (CPU, memory, storage consumed). n8n idles light — a personal instance with moderate workflows typically lands around $5–15/month all-in, with Postgres included in the usage math.
Compare the three models honestly:
| Railway | VPS (Hetzner) | n8n Cloud | |
|---|---|---|---|
| Monthly cost | ~$5–15 (usage-based) | ~€4–6 (flat) | from ~€24 |
| Executions | Unlimited | Unlimited | Metered |
| Server admin | None | Yours | None |
| Ops you still own | Env vars, updates, backups | Everything | Nothing |
| Control | Medium | Full | Low |
Full cost analysis across all three: n8n Cloud vs Self-Hosted.
What you still own (don’t skip this)
Managed infrastructure ≠ managed instance. Three responsibilities remain yours:
- Updates. Railway won’t bump your n8n version for you forever — check the template’s update flow (usually: redeploy with a newer image tag). The safe-update routine applies here too: read release notes, back up, then bump.
- Backups. Railway keeps your volume and database alive, but “the platform probably won’t lose it” is not a backup strategy. Schedule
pg_dumpoff-platform (a scheduled workflow inside n8n itself can dump to object storage — pleasantly recursive) and keep the encryption key in your password manager. - Access security. Strong owner password, 2FA, and don’t share the editor URL casually. The hardening guide has a section on what applies when there’s no server to harden.
Railway vs the VPS: our take
Choose Railway if the words “SSH key” lower your quality of life, you value deploy-and-forget, and $10-ish/month is fine. It’s real self-hosting in the sense that matters: your instance, your data, unlimited executions.
Choose the VPS if you want the lowest flat cost, full control (custom nodes, queue mode, weird networking), or you simply enjoy owning the stack. It’s 30–45 minutes of honest setup with our step-by-step guide, and everything about it is yours.
Either way you’ve escaped per-execution pricing — which, for most people reading this site, was the whole point.