Deploy n8n v3

Deploy and Host n8n v3 on Railway

n8n v3 is the next generation of n8n workflow automation, with improvements focused on reliability, stability, and security.

This Railway template deploys n8n v3 using a distributed architecture with a dedicated Main instance, Webhook Processor, Worker, external Task Runner, PostgreSQL, and Redis.

It provides queue-based workflow execution, isolated code execution, and dedicated webhook handling without the overhead of multiple Workers and Runners.

⚠️ Preview Release: This template currently uses n8n v3 nightly images. These are development builds intended for testing and evaluation, not stable production use. Upgrade to matching stable images when n8n v3 becomes generally available.

About Hosting n8n v3

Hosting n8n v3 on Railway enables a modular workflow automation environment with separate services for management, webhook handling, workflow execution, and code execution.

The Main instance provides the Editor UI, REST API, workflow scheduling, and orchestration. A dedicated Webhook Processor handles production webhook traffic, while Redis distributes workflow executions to a dedicated Worker.

The Worker runs workflows independently and communicates with an external Task Runner to execute JavaScript and Python Code nodes in an isolated environment.

PostgreSQL stores persistent application data, while Railway Private Networking keeps internal services connected without exposing them publicly.

This architecture provides a scalable foundation for automation workloads while keeping infrastructure complexity and resource usage manageable.

Architecture

Simplified architecture:

                    Internet
                       |
             +---------+---------+
             |                   |
             v                   v
         n8n Main         Webhook Processor
       Editor / API        Production Webhooks
             |                   |
             +---------+---------+
                       |
                       v
                 Redis Queue
                       |
                       v
                  n8n Worker
               Concurrency: 10
                       |
                 Task Broker
                  Port 5679
                       |
                       v
                Dedicated Runner
               Max Concurrency: 5

                 PostgreSQL
             Shared n8n Database

Common Use Cases

• Workflow and business process automation
• Webhook-based integrations
• REST API orchestration
• Scheduled background jobs
• SaaS and third-party integrations
• ETL and data transformation
• Backend automation
• AI-powered workflows
• Internal business automation
• JavaScript and Python Code node execution
• Queue-based workflow processing

Dependencies for n8n v3 Hosting

This template includes:

• n8n v3 — Workflow automation and orchestration
• n8n Task Runners — External JavaScript and Python execution
• PostgreSQL — Persistent workflow, credential, and execution data
• Redis — Execution queue and job coordination
• Railway Private Networking — Internal service communication
• Railway Volumes — Persistent storage for PostgreSQL, Redis, and Main where configured

PostgreSQL and Redis use Railway database services rather than manually configured database containers.

How the Services Work

Main

The Main instance manages:

• n8n Editor UI
• REST API
• Workflow configuration
• Credential management
• Workflow scheduling
• Execution orchestration
• Manual execution coordination

Production webhook handling is disabled on Main because a dedicated Webhook Processor handles those requests.

Manual executions are offloaded to the Worker, reducing execution workload on the Main instance.

Webhook Processor

The Webhook Processor provides a dedicated public endpoint for production webhooks.

It receives incoming requests, coordinates webhook-triggered executions, and submits execution jobs to Redis for processing by the Worker.

Separating webhook traffic helps protect Editor responsiveness during periods of increased webhook activity.

Test webhooks remain accessible through Main.

Worker

The template includes one dedicated Worker with an initial concurrency configuration of 10.

The Worker:

• Consumes workflow executions from Redis
• Retrieves workflow information from PostgreSQL
• Executes workflow nodes
• Coordinates Code node tasks with the external Runner
• Updates workflow execution results and status

The Worker is not publicly accessible and communicates with other services through Railway Private Networking.

Dedicated Task Runner

The template includes one external Task Runner, paired with the Worker.

Worker
  |
  | Private Task Broker :5679
  |
  v
Dedicated Task Runner
  |
  +-- JavaScript Code Tasks
  |
  +-- Python Code Tasks

The Task Runner provides isolated execution for supported tasks, including JavaScript and Python Code nodes.

The initial configuration allows up to five concurrent runner tasks.

The Runner connects to the Worker using a shared authentication token and Railway Private Networking.

It does not require a public domain, database credentials, or a persistent volume.

Important Configuration

Shared Encryption Key

Main generates the shared encryption key:

N8N_ENCRYPTION_KEY

Worker and Webhook Processor reference the same value.

This allows all n8n runtime services to decrypt stored credentials consistently.

Important: Preserve this key across deployments and backups. Replacing it can make existing encrypted credentials inaccessible.

Queue Mode

All n8n runtime services use:

EXECUTIONS_MODE=queue

Redis manages pending execution jobs, while Worker processes the queued workflows.

This separates execution processing from the Main Editor and webhook ingress services.

External Task Runner

The Worker uses:

N8N_RUNNERS_MODE=external
N8N_RUNNERS_BROKER_PORT=5679

The Dedicated Runner connects to the Worker's private broker using:

N8N_RUNNERS_TASK_BROKER_URI
N8N_RUNNERS_AUTH_TOKEN

The Runner authentication token must match the token configured on Worker.

The n8n and Runner Docker images must also use compatible, matching versions.

Production Webhook URL

Production webhook URLs use the dedicated Webhook Processor public domain.

Main is configured to generate production webhook URLs that point to the Webhook Processor.

The public endpoints are separated as follows:

Both Main and Webhook Processor receive their own Railway HTTPS domain.

Manual Workflow Executions

Manual workflow executions are processed by Worker rather than Main.

OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true

This allows one dedicated Task Runner to serve the Worker without requiring an additional Runner for Main.

Worker and Runner Concurrency

The default deployment uses:

These settings control different workloads.

Worker concurrency determines how many workflow executions can be processed simultaneously, while Runner concurrency limits the number of supported code tasks that can execute concurrently.

Resource-intensive Code nodes may require additional Runner memory, CPU, or lower concurrency settings.

Why Deploy n8n v3 on Railway?

Railway simplifies deploying a distributed n8n environment by providing:

• Container-based service deployment
• PostgreSQL and Redis service templates
• Automatic HTTPS and public domains
• Private networking between services
• Environment variable references
• Persistent volumes
• Centralized deployment logs
• Resource monitoring and scaling controls

This template preconfigures the essential components needed for queue-based automation, dedicated webhook handling, and isolated Code node execution.

After Deployment

1. Open the public Main URL.
2. Create the initial n8n owner account.
3. Verify that the Editor UI loads correctly.
4. Create a simple test workflow.
5. Run the workflow manually and confirm Worker processes it.
6. Create a JavaScript or Python Code node and verify Runner execution.
7. Create and activate a production webhook workflow.
8. Verify that the production webhook URL uses the Webhook Processor domain.
9. Send a test HTTP request to the production webhook endpoint.
10. Inspect Worker and Runner logs for successful execution.
11. Verify that PostgreSQL and Redis connections remain healthy.
12. Configure backups and review resource usage.