Deploy and Host n8n on Railway

n8n is the open-source workflow automation platform — 400+ integrations, a visual node editor, and native AI agent nodes, all self-hosted with no per-execution fees. This template deploys n8n 2.32.5 backed by a dedicated PostgreSQL 17 database on a persistent volume, so your workflows, credentials, and execution history survive every redeploy.

About Hosting n8n

The common way to self-host n8n is a single container writing to SQLite on ephemeral disk. That works right up until the first redeploy, when every workflow and saved credential disappears. This template runs n8n against its own PostgreSQL 17 service over Railway's private network, with the database on a mounted volume — the arrangement n8n itself recommends for production.

N8N_ENCRYPTION_KEY is generated once at deploy and held constant. That key is what n8n uses to encrypt stored credentials; if it changes, every saved credential becomes unreadable, which is the usual reason a "working" self-hosted n8n breaks after a restart. Binary data is written to Postgres rather than to container-local disk, so file-producing workflows behave correctly across restarts and replicas. The webhook and editor base URLs are wired to the Railway public domain automatically, so webhook-triggered workflows and OAuth callbacks resolve on the first try instead of pointing at localhost. Task runners are enabled, which is how current n8n versions isolate Code-node execution.

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.

• Persistence that actually persists — Postgres 17 on a volume, not SQLite on ephemeral disk.
• Credentials survive restarts — a stable encryption key is generated at deploy and never rotates underneath you.
• Webhooks work immediately — editor and webhook URLs bound to your Railway domain, no manual reconfiguration.
• Current release — n8n 2.32.5 with task runners enabled, not a year-old pinned tag.
• No execution pricing — unlimited workflow runs on flat infrastructure cost instead of per-task cloud billing.

Common Use Cases

• AI agent orchestration — chain LLM calls, vector stores, and tools into workflows with human approval steps.
• Internal integrations — sync CRM, billing, support, and database records without writing glue services.
• Scheduled data pipelines — pull from APIs on a cron, transform, and load into your warehouse.

Dependencies for n8n Hosting

• A PostgreSQL 17 service with a volume mounted at /var/lib/postgresql/data (included in this template).
• Roughly 2GB RAM for the n8n service under normal workflow load; heavier AI or data workflows benefit from more.

Deployment Dependencies

• n8n — upstream project (Sustainable Use License)
• n8n documentation — workflow, node, and environment variable reference
• n8n on Docker Hub — the image this template deploys

Implementation Details

Two services on Railway's private network:

The Postgres service is private — it has no public domain, and is reachable only over the internal network via ${{postgres.RAILWAY_PRIVATE_DOMAIN}}.

On first deploy, open your public domain and create the owner account. Health is exposed at two paths:

curl https:///healthz             # process is up
curl https:///healthz/readiness   # database connection is live

/healthz/readiness returning {"status":"ok"} confirms n8n is talking to Postgres. To upgrade n8n later, change the image tag on the n8n service and redeploy — your workflows and credentials are in Postgres and are unaffected.