Deploy n8n

Deploy and Host n8n 3.0 on Railway

Deploy n8n 3.0.0 on Railway with a dedicated worker, PostgreSQL, Redis, and external JavaScript and Python task runners. This five-service stack configures queue mode, generated encryption secrets, HTTPS webhook URLs, and shared file storage in PostgreSQL.

Release status: n8n published 3.0.0 on October 27, 2026 as a pre-release. This template pins that version and matching runners. It is a new installation; it does not upgrade an existing n8n 2.0 deployment. Check the official release before choosing it for critical workflows.

Why Deploy n8n 3.0 on Railway?

• A responsive editor with a separate execution worker. Production webhooks and manual runs use queue mode. The worker starts with concurrency 5; change its start command to tune concurrency.
• External JavaScript and Python runners. Code nodes execute in a separate service with an authenticated private connection. The runner service receives its broker token, not your database password or encryption key. Idle language processes shut down after 15 seconds and restart when work arrives.
• Files work across the editor and worker. Binary data uses PostgreSQL instead of separate container filesystems. No shared filesystem, S3 bucket, or n8n external-storage licence is required for this configuration. The per-file limit is set to 64 MiB to keep database growth manageable.
• Standard Railway databases. PostgreSQL and Redis retain their usual connection variables, generated passwords, private hostnames, and persistent volumes. n8n connects over private networking.
• Persistent encrypted credentials. A generated master encryption key is shared by the editor and worker through a variable reference. Workflows, users, credentials, executions, and binary files live in PostgreSQL; Redis persists queue state.
• Controlled updates and retention. n8n and runners use matching 3.0.0 images pinned by digest. Completed execution data is pruned after seven days, with a maximum of 10,000 retained records. You choose when to update.

“Pro Stack” describes this deployment's infrastructure. It does not unlock n8n's paid Business or Enterprise features.

Dependencies for n8n 3.0

Deployment Dependencies

All five services are included. No AI API key, external database account, or S3 account is required to deploy. Railway provides private networking, the web domain, and the two database volumes.

Only the editor receives a public web domain. Worker readiness and runner health checks are configured separately. This is a single-worker deployment, not a high-availability cluster.

About Hosting n8n 3.0

The editor, worker and runners use official n8n container images. PostgreSQL and Redis use the standard Railway images and connection variables, with persistent volumes and generated passwords.

First deployment

1. Deploy the template into your Railway workspace. No AI provider key is required to start.
2. Wait for the databases, editor, worker, and runners to become healthy. Initial database migrations can take a few minutes.
3. Open the n8n-main Railway domain and create your owner account using n8n's normal setup screen. Claim your instance promptly after deployment.
4. Create a workflow and publish it. Production webhook URLs already use your HTTPS domain.
5. Add provider credentials inside n8n only for the integrations you use. OpenAI, Anthropic, other AI providers, and ordinary API integrations require their own accounts where applicable.

The initial timezone is Europe/Paris. Change GENERIC_TIMEZONE and TZ on the editor and worker if your scheduled automations use another timezone.

JavaScript, Python, and file workflows

JavaScript and native Python Code nodes use the external runners. The default runner images keep their module allowlists restricted. Additional Python or npm dependencies require a customised runners image and explicit allowlists; setting an arbitrary environment variable does not install packages.

The default task timeout is explicitly set to 300 seconds on n8n and the runners. File workflows use N8N_DEFAULT_BINARY_DATA_MODE=database on both n8n services. Keep these settings consistent when adding workers. Large file workloads can increase PostgreSQL storage, memory, and backup costs; review the 64 MiB limit before raising it.

For additional workers, provide each worker with its own runner service pointing at that worker's private broker hostname. Copy the database, queue, encryption-key, and binary-storage references. Do not point every runner at the first worker.

Persistence, backups, and restart behaviour

PostgreSQL and Redis have persistent volumes. n8n containers are replaceable: core application data and binary files are kept in the database, with encryption material supplied through persistent Railway variables. Manually added files inside application containers are not durable.

Enable the required Railway volume backup schedule on PostgreSQL after deployment and test restoring a backup. A persistent volume alone is not a backup. Preserve N8N_ENCRYPTION_KEY securely alongside your recovery procedure: a database backup without the matching key is insufficient to recover encrypted credentials.

Keep the editor, worker, and databases running for scheduled jobs and webhook automation. The language runners can idle internally; the stack does not rely on Railway serverless sleep. Railway charges for the resources and storage actually used by all five services.

For planned maintenance, stop new requests at the editor first, drain and stop the worker, then stop the runners and databases. The template sets explicit runner shutdown deadlines; stopping the worker before its runners lets the broker drain cleanly. Let queued work finish before planned maintenance, or validate your interruption and retry procedure with a disposable workflow first.

Updating or moving from n8n 2.0

Update the editor, worker, and runners together to a matching release. Back up the database and encryption key first. Digest pinning intentionally prevents unreviewed major upgrades through a moving latest tag.

To move existing n8n 2.0 workflows, review n8n's v3 breaking changes, use its migration report, and test copied workflows. This template creates a fresh database; it does not migrate your old installation automatically. Imported credential backups require a compatible encryption-key procedure.

Common Use Cases

• Receive webhooks and process API automations through a dedicated execution queue.
• Transform data with JavaScript or native Python Code nodes in external runners.
• Generate files on workers and download them from the editor through shared database storage.
• Build AI workflows after configuring your chosen model provider inside n8n.

Frequently asked questions

Can I self-host n8n v3 on Railway without an AI API key?

Yes. The editor, queues, code runners, and non-AI workflows start without one. Configure credentials in n8n when you add an integration that requires them.

Why use this instead of a single n8n container?

Use this when you need separate execution capacity, native Python and JavaScript runners, and binary files shared across services. A single-container installation can cost less for light workloads. This stack trades additional services for execution isolation and explicit storage configuration.

Is n8n 3.0 stable?

The pinned 3.0.0 release is currently marked pre-release upstream. This template makes that status explicit and keeps the installed version reproducible. Passing deployment tests does not guarantee that every integration or imported workflow is compatible.

Can I use community nodes or paid n8n features?

Follow n8n's supported installation and licensing process. v3 disables unverified community packages by default. Paid features still require the appropriate n8n licence. This template does not bypass those restrictions.

Official references

• n8n 3.0.0 release
• Queue mode
• External task runners
• Binary data configuration