Deploy n8n Fullpack

Deploy and Host N8N Fullpack on Railway

N8N Fullpack is a production-oriented n8n deployment architecture designed for scalable workflow automation on Railway.

This template includes a dedicated Primary instance, Webhook Processor, multiple Workers, external Task Runners, PostgreSQL, and Redis. It is designed for users who want more than a basic single-container n8n deployment and need queue-based execution, workload separation, and horizontal processing capacity.

About Hosting N8N Fullpack

N8N Fullpack separates the major n8n runtime responsibilities into dedicated services.

The Primary service hosts the n8n Editor UI, API, and orchestration layer. Production webhook traffic is handled independently by the Webhook Processor, while workflow executions are distributed through Redis to multiple Workers.

Each Worker is paired with its own external Task Runner to provide isolated task execution for supported nodes such as the Code node.

PostgreSQL stores persistent n8n application data, while Redis provides the execution queue used by the distributed Workers.

This architecture is suitable for production workloads where execution capacity, separation of responsibilities, and easier horizontal scaling are preferred over a minimal single-instance deployment.

Architecture

The template deploys the following services:

• Primary — n8n Editor UI, API, and main orchestration service
• Webhook Processor — Dedicated production webhook ingress
• Worker 1 — Processes queued workflow executions
• Worker 2 — Provides additional parallel execution capacity
• Runner 1 — External Task Runner paired with Worker 1
• Runner 2 — External Task Runner paired with Worker 2
• PostgreSQL — Persistent n8n database
• Redis — Queue backend used for distributed workflow execution

Simplified architecture:

                 Internet
                    │
        ┌───────────┴───────────┐
        │                       │
        ▼                       ▼
     Primary             Webhook Processor
        │                       │
        └──────────┬────────────┘
                   │
                 Redis
              Execution Queue
               /          \
              ▼            ▼
         Worker 1      Worker 2
             │             │
             ▼             ▼
         Runner 1      Runner 2

                   │
                   ▼
               PostgreSQL

Common Use Cases

• Production workflow automation
• High-volume workflow execution
• Webhook-based integrations
• API orchestration
• Backend automation
• Scheduled workflows
• ETL and data processing
• SaaS integrations
• Internal business automation
• AI workflow orchestration
• Multi-worker n8n deployments
• Queue-based workload processing

Dependencies for N8N Fullpack Hosting

This template uses:

• n8n for workflow automation and orchestration
• n8n Task Runners for external task execution
• PostgreSQL for persistent application data
• Redis for queue-mode workflow execution
• Railway Private Networking for internal service communication
• Railway Volumes for persistent storage where required

How the Services Work

Primary

The Primary instance provides:

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

Production webhook processing is disabled on the Primary instance because webhook traffic is delegated to the dedicated Webhook Processor.

Webhook Processor

The Webhook Processor receives production webhook requests and places workflow executions into the Redis-backed execution queue.

This keeps incoming webhook traffic separated from the Primary Editor and management workload.

Workers

The template includes two Workers.

Both Workers:

• Consume executions from Redis
• Share the same PostgreSQL database
• Share the same n8n encryption key
• Process workflows independently
• Increase parallel execution capacity

Additional Workers can be introduced later if more execution capacity is required.

Task Runners

Each Worker has its own external Task Runner.

The mapping is:

Worker 1 → Runner 1
Worker 2 → Runner 2

Task Runners provide isolated execution for supported task types and prevent those tasks from running directly inside the Worker process.

Runner services are internal-only and do not require public domains.

Public and Private Services

Only services that must receive internet traffic should be exposed publicly.

All internal communication should use Railway Private Networking.

Persistent Storage

Persistent storage is primarily required for database services.

The Primary instance can also use a Railway Volume mounted at:

/home/node/.n8n

Typical storage layout:

• Primary → /home/node/.n8n
• PostgreSQL → Railway-managed persistent volume
• Redis → Railway-managed persistent volume
• Workers → No volume required
• Webhook Processor → No volume required
• Task Runners → No volume required

Workflow definitions, credentials, users, and execution metadata are stored in PostgreSQL.

Important Configuration

Shared Encryption Key

All n8n services that access encrypted credentials must use the same:

N8N_ENCRYPTION_KEY

The Primary instance generates the encryption key, while Workers and the Webhook Processor reference the same value.

Changing this key after credentials have already been created can prevent n8n from decrypting existing credentials.

Queue Mode

The deployment uses:

EXECUTIONS_MODE=queue

Redis acts as the queue backend and distributes workflow executions between available Workers.

Production Webhook URL

Production webhook URLs are generated using the dedicated Webhook Processor domain.

The Primary service points its webhook URL configuration to the public Webhook Processor endpoint.

Manual Executions

Manual workflow executions from the Editor are offloaded to Workers.

This keeps the Primary instance focused on orchestration and management instead of execution workload.

Scaling

The template starts with two Workers to provide parallel processing capacity.

Scaling can later be performed by:

• Increasing Worker concurrency
• Adding additional Workers
• Increasing Worker CPU or memory
• Scaling webhook processing independently
• Scaling Primary resources independently

Redis and PostgreSQL remain shared infrastructure for all n8n runtime services.

N8N Fullpack vs Minimal n8n

Why Deploy N8N Fullpack on Railway?

Railway provides managed deployment infrastructure with private networking, persistent volumes, environment variable references, automatic HTTPS, service discovery, and integrated PostgreSQL and Redis services.

With N8N Fullpack, Railway can host the complete distributed n8n runtime while keeping internal services isolated from the public internet.

This template removes much of the manual infrastructure setup normally required for a queue-mode n8n deployment while still preserving a scalable service architecture.

After Deployment

After deployment:

1. Open the public Primary URL.
2. Create the initial n8n owner account.
3. Verify that the Editor loads normally.
4. Create a simple workflow.
5. Run the workflow manually and confirm execution is handled by a Worker.
6. Create a production webhook workflow.
7. Verify the generated webhook URL uses the Webhook Processor domain.
8. Check Worker logs to confirm queued executions are being processed.
9. Check Runner logs when executing Code nodes or other runner-supported tasks.

Your N8N Fullpack deployment is then ready for production workflow automation.