--- title: "Deploy n8n v3" description: "A scalable n8n 3.0 setup with dedicated workers, runners, and webhooks." category: "Automation" url: https://railway.com/deploy/n8n-v3 --- # Deploy n8n v3 A scalable n8n 3.0 setup with dedicated workers, runners, and webhooks. **[Deploy n8n v3 on Railway](https://railway.com/template/n8n-v3)** Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/n8n-v3/manifest.json - **Creator:** Rakit - **Category:** Automation - **Total deploys:** 1 ## Template content ### Webhook Processor https://devicons.railway.app/n8n - **Image:** n8nio/n8n:v3-nightly - **Start command:** `n8n webhook` - **Public domain:** Yes ### Worker https://devicons.railway.app/n8n - **Image:** n8nio/n8n:v3-nightly - **Start command:** `n8n worker --concurrency=10` ### Redis https://cdn.sanity.io/images/sy1jschh/production/0ce0bfdcfbdbf69662b1116671f97c2dd788b655-157x157.svg - **Image:** redis:8.2.1 - **Start command:** `/bin/sh -c "rm -rf $RAILWAY_VOLUME_MOUNT_PATH/lost+found/ && exec docker-entrypoint.sh redis-server --requirepass $REDIS_PASSWORD --save 60 1 --dir $RAILWAY_VOLUME_MOUNT_PATH"` ### Task Runner https://devicons.railway.app/n8n - **Image:** n8nio/n8n:v3-nightly ### Main https://devicons.railway.app/n8n - **Image:** n8nio/n8n:v3-nightly - **Start command:** `n8n start` - **Public domain:** Yes ### Postgres https://devicons.railway.app/i/postgresql.svg - **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18 ## Documentation # 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: ```text 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. ```text 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: ```text 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: ```text 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: ```text N8N_RUNNERS_MODE=external N8N_RUNNERS_BROKER_PORT=5679 ``` The Dedicated Runner connects to the Worker's private broker using: ```text 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: | Endpoint | Destination | |---|---| | Editor UI and REST API | Main | | Test webhooks | Main | | Production webhooks | Webhook Processor | | Webhook waiting endpoints | Webhook Processor | Both Main and Webhook Processor receive their own Railway HTTPS domain. ### Manual Workflow Executions Manual workflow executions are processed by Worker rather than Main. ```text 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: | Component | Concurrency | |---|---| | Worker | 10 workflow executions | | Task Runner | 5 Code node tasks | 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. ## Similar templates - [N8N Main + Worker](https://railway.com/deploy/n8n-main-worker) — Deploy and Host N8N with Inactive worker. - [Evolution API with n8n](https://railway.com/deploy/evolution-api-with-n8n) — Automate WhatsApp workflows with Evolution API, n8n, and Postgres. - [Postgres Backup](https://railway.com/deploy/postgres-s3-backups) — Cron-based PostgreSQL backup to bucket storage Open this page in a browser: https://railway.com/deploy/n8n-v3