Deploy and Host n8n with workers on Railway

n8n with workers is a scalable automation setup that combines the n8n main application, queue workers, Redis, PostgreSQL, and persistent storage. It is designed for users who want a more production-ready n8n deployment for high-volume workflows, concurrent webhook processing, background jobs, and reliable workflow execution.

About Hosting n8n with workers

Hosting n8n with workers on Railway involves deploying multiple connected services: the main n8n web application, one or more n8n worker services, Redis for queue-based job processing, and PostgreSQL for workflow and execution data. The main n8n service provides the web UI and receives webhook/API traffic, while workers process workflow executions in the background. Redis acts as the queue broker between the main service and workers, and PostgreSQL stores n8n data reliably. Railway handles deployments, service networking, public access, and scaling, making it easier to run a scalable automation stack without manually managing servers.

Note This is an advanced n8n with workers template. It runs multiple Railway services and may cost more than a basic single-service n8n deployment.

Common Use Cases

Running scalable workflow automation with background workers
Processing high-volume webhooks and API-triggered workflows
Building internal automation tools for business operations
Running ETL, data sync, and scheduled workflow jobs
Separating the n8n web UI from execution workers for better reliability
Using PostgreSQL-backed persistence for production-style n8n deployments

Dependencies for n8n with workers Hosting

n8n main application service using the official n8n Docker image
n8n worker service using the same official n8n Docker image
Redis service for queue-based workflow execution
PostgreSQL service for persistent workflow and execution data
Railway Volume mounted on the n8n main service for local files
Public HTTP access through Railway for the n8n web UI

Deployment Dependencies

Official n8n documentation: https://docs.n8n.io
n8n queue mode documentation: https://docs.n8n.io/hosting/scaling/queue-mode/
n8n environment variables: https://docs.n8n.io/hosting/configuration/environment-variables/
Official n8n Docker image: https://hub.docker.com/r/n8nio/n8n
Railway PostgreSQL: https://docs.railway.com/guides/postgresql
Railway Redis: https://docs.railway.com/guides/redis
Railway Public Networking: https://docs.railway.com/networking/public-networking
Railway Volumes: https://docs.railway.com/reference/volumes
Railway CLI: https://docs.railway.com/guides/cli
Railway SSH guide: https://docs.railway.com/guides/ssh

Architecture

This template uses a queue-based n8n architecture:

Browser / Webhooks
  |
  v
n8n Main Application
  |
  v
Redis Queue
  |
  v
n8n Worker Service(s)
  |
  v
PostgreSQL

The n8n main application provides the web UI, receives webhook traffic, and sends workflow execution jobs to Redis. The worker service consumes jobs from Redis and executes workflows in the background. PostgreSQL stores workflows, credentials metadata, executions, settings, and other n8n application data.

Services

This template should include the following Railway services:

n8n Main Application

The main n8n service runs the web UI and webhook/API entrypoint.

Image: n8nio/n8n:latest
Role: Web UI, API, webhook receiver, queue producer
Public: Yes

n8n Worker

The worker service processes workflow executions from the Redis queue.

Image: n8nio/n8n:latest
Role: Background workflow execution worker
Public: No

Redis

Redis is used as the queue broker between the main n8n service and worker services.

Role: Queue backend
Public: No

PostgreSQL

PostgreSQL stores n8n workflow data, credentials metadata, executions, settings, and persistent application data.

Role: Primary database
Public: No

Public Web Access

Expose only the n8n main application service publicly. The worker, Redis, and PostgreSQL services should remain private.

Recommended public port:

After deployment, open the generated Railway domain or your custom domain in a browser to access the n8n web UI.

Persistent Storage

This template uses persistent storage across the main stateful services:

n8n Main Application mounts a Railway Volume at /home/node/.n8n for local n8n files and encryption-related data.
PostgreSQL uses its default persistent data path at /var/lib/postgresql/data.
Redis uses its default persistent data path at /data.
n8n Worker is stateless and does not require a volume by default.

The n8n worker service processes queued jobs from Redis and uses the same PostgreSQL database as the main n8n service. For workloads that require shared binary files or external file persistence, use external object storage or a dedicated shared storage strategy.

Authentication and Security

n8n creates its owner account during the first setup in the web UI. After opening the public Railway URL, complete the initial n8n owner setup screen and save the login credentials securely.

For production-style deployments, keep the same encryption key across the n8n main service and worker service. This ensures credentials and encrypted workflow data remain readable by all n8n services in the stack.

Recommended security practices:

Use a strong encryption key shared between n8n main and worker services.
Keep Redis and PostgreSQL private inside the Railway project.
Expose only the n8n main application service publicly.
Use a strong owner account password during first setup.
Avoid changing the encryption key after credentials have been created.

SSH Usage

SSH is optional and mainly useful for diagnostics. Most users should access n8n through the public web UI.

Prerequisites

Ensure you have the necessary setup in place:

The Railway CLI installed on your local machine
Logged in with your Railway account using:

railway login

Usage

You can copy the exact SSH command directly from the Railway dashboard:

Navigate to your project in the Railway dashboard.
Right-click on the n8n main or n8n worker service you want to inspect.
Select Copy SSH Command from the dropdown menu.
Paste the command into your local terminal to connect to the running container.

Once connected, you can inspect files, review logs, verify environment variables, test Redis or PostgreSQL connectivity, or debug the running n8n service.

Implementation Details

This template deploys n8n as a multi-service Railway stack:

n8n Main Application + n8n Worker + Redis + PostgreSQL + Persistent Storage

Both the main n8n service and worker service use the official n8n Docker image:

FROM n8nio/n8n:latest

The main n8n service should run the web application and listen on port 5678. The worker service should run in worker mode and should not be exposed publicly. Both services must use the same PostgreSQL database, Redis queue backend, and encryption key.

This stack is more suitable for production-style automation workloads than a single-service n8n deployment because workflow execution can be handled by dedicated workers while the main service remains focused on the web UI, API, and webhook traffic.

Why Deploy n8n with workers 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 with workers 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.