---
title: "Deploy n8n ETL"
description: "API to Postgres data pipelines"
category: "Automation"
url: https://railway.com/deploy/n8n-etl
---

# Deploy n8n ETL

API to Postgres data pipelines

**[Deploy n8n ETL on Railway](https://railway.com/template/n8n-etl)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/n8n-etl/manifest.json

- **Creator:** onepush
- **Category:** Automation

## Template content

### Redis https://cdn.sanity.io/images/sy1jschh/production/0ce0bfdcfbdbf69662b1116671f97c2dd788b655-157x157.svg

- **Image:** redis:8.2
- **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"`

### n8n

- **Image:** n8nio/n8n:2.36.8
- **Health check:** /healthz
- **Public domain:** Yes

### n8n-worker

- **Image:** n8nio/n8n:2.36.8
- **Start command:** `n8n worker`
- **Health check:** /healthz

### Postgres https://devicons.railway.app/i/postgresql.svg

- **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18

## Documentation

# Deploy and Host self hosted n8n ETL (Open-Source ETL Automation) on Railway

The moment you need real data pipelines—not just a one-off script—you face a choice: stitch together cron jobs and hope for the best, or stand up a queue-based worker that survives load spikes. n8n in queue mode on Railway gives you the second option without the DevOps heartburn. You get a webhook-friendly editor, a Redis-backed queue, and Postgres as both the system database and your target warehouse. This stack is for operators who want API-to-Postgres pipelines that don't fall over at 3 a.m.

If you only need a single editor with no workers, use the [cheapest n8n without queue mode](https://railway.com/deploy/n8n) listing instead — this template is the queue-mode stack for real pipelines.

Self-host n8n ETL on Railway in queue mode with an n8n editor, dedicated worker, PostgreSQL, and Redis Bull so webhooks and long workflows stay off the UI—flat infrastructure cost instead of per-task SaaS billing.

Self-host n8n ETL on Railway in queue mode with an n8n editor, dedicated worker, PostgreSQL, and Redis Bull so webhooks and long workflows stay off the UI—flat infrastructure cost instead of per-task SaaS billing.

## About Hosting n8n ETL open-source software on Railway (self hosted n8n template)

Most people first meet n8n as a single-container automation tool running on SQLite. That works for low-volume workflows, but it breaks the moment you try to run concurrent ETL jobs or long-running transformations. SQLite locks, executions pile up, and your webhook responses start timing out. Queue mode changes the architecture: the main editor instance stops executing workflows directly. Instead, it enqueues jobs into Redis Bull, and separate worker containers pull them off the queue and run them. This separation means you can scale workers horizontally when your API extract jobs spike, without touching the editor that's serving your team.

On Railway, this becomes a three-service template: the n8n editor, one or more n8n workers, and a Redis instance for the Bull queue. Postgres sits alongside as both n8n's system database and the destination for your transformed data. The editor container runs the same `n8nio/n8n:2.36.8` image you'd use locally, but with `EXECUTIONS_MODE=queue` set. Workers run the identical image with the `n8n worker` command. Both point at the same Postgres and Redis. The volume at `/home/node/.n8n` holds your credentials, workflow definitions, and encryption keys. Lose that volume and you lose access to every stored credential—this is not a stateless app.

## Why Deploy n8n ETL, the Airbyte alternative on Railway (Railway Free Trial)

Airbyte is excellent at moving data between systems when the connectors already exist and your transformation needs fit inside dbt. But Airbyte's connector model has an opinion: you configure sources and destinations through its UI, and custom extraction logic means building a connector or dropping into raw SQL. n8n comes at the problem from the other direction. You write the extraction logic as a visual workflow—an HTTP request to a REST API, a cron trigger, a webhook listener—then transform the JSON response with JavaScript or built-in mapping nodes, and upsert the result into Postgres. No connector catalog to wait on. No separate dbt project for basic field mapping. If your API returns something weird, you fix it in the workflow, not in a connector's GitHub repo.

That said, Airbyte wins on breadth of prebuilt connectors and on change data capture for databases. If you're syncing twenty SaaS tools into a warehouse with minimal transformation, Airbyte's catalog will get you there faster. But when your pipeline is custom—a partner API that returns nested XML, a GraphQL endpoint with pagination quirks, a cron job that checks an SFTP folder—n8n's workflow model is simply more direct. You're not fighting an abstraction layer; you're writing the pipeline itself.

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 ETL 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.

### Railway vs Other Hosting Providers and VPS for n8n ETL self hosting

| Provider | Queue-mode complexity | Scaling workers | Cost predictability | Postgres + Redis management |
|----------|----------------------|------------------|---------------------|-----------------------------|
| DigitalOcean | Manual: provision droplet, install Docker, wire Redis + Postgres yourself, set up a process manager | Manual: clone worker containers and update DNS or load balancer config | Predictable per-droplet pricing, but you pay for idle capacity | You manage both services: backups, updates, security groups |
| AWS | High: ECS or EKS required for queue mode; IAM, VPC, and security group setup before anything runs | Elastic: ECS service scaling works well, but configuration is a project | Easy to overprovision; costs creep through NAT gateways, ALBs, and EBS | RDS and ElastiCache are solid, but each is a separate managed service with its own bill |
| Hetzner | Manual: bare metal or cloud server, Docker Compose, systemd for workers | Manual: add worker containers and restart the stack | Very cheap, especially for dedicated servers | Self-managed Postgres and Redis unless you use managed offerings |

Railway handles the queue-mode plumbing natively. The template wires editor, worker, Redis, and Postgres together with the right environment variables already set. You can scale the worker service from one replica to five with a slider, and Railway routes traffic to the editor while workers just consume from Redis. No load balancer config, no security group rules, no IAM policies. The tradeoff is less control over the underlying infrastructure—if you need custom kernel parameters or specific Postgres extensions, a VPS gives you that and Railway doesn't.

## Common Use Cases for hosted n8n ETL

The Schedule/HTTP trigger to map-fields to Postgres upsert pattern covers most operational ETL needs. You set a cron trigger for every fifteen minutes, hit a REST endpoint, map the JSON response fields to your Postgres columns, and use the Postgres node's upsert mode to insert or update rows based on a conflict target. This replaces a surprising amount of custom Python that someone wrote once and nobody dares touch.

Beyond that baseline, you'll see these patterns in the wild: webhook-triggered loads where a third-party service POSTs JSON to your n8n instance and you transform and load it within seconds; multi-step pipelines that extract from one API, join against Postgres for enrichment, then load into a different table; scheduled full-refresh jobs that truncate a staging table and rebuild it nightly; and incremental syncs that track a high-water mark—usually a `updated_at` timestamp—stored in Postgres between runs. Teams also use n8n ETL for data quality checks: a workflow that pulls new rows, validates them against rules, and writes failures to a quarantine table while loading the good rows.

## Dependencies for n8n ETL Docker hosted on Railway

This listing depends on four coordinated Railway services: the n8n editor (`n8nio/n8n:2.36.8` on port 5678), an `n8n worker` replica of the same image, PostgreSQL with `DB_TYPE=postgresdb`, and Redis for the Bull queue. SQLite cannot run queue mode. Set `EXECUTIONS_MODE=queue`, `WEBHOOK_URL`, `N8N_PROXY_HOPS=1`, `N8N_ENCRYPTION_KEY`, and `EXECUTIONS_DATA_PRUNE=true`.

### Deployment Dependencies for Managed n8n ETL Service (ETL & Data Pipelines)

This stack has four moving parts, and each one matters. Postgres is the system database for n8n—it stores workflows, credentials, and execution history. In queue mode, Postgres is mandatory; SQLite cannot run queue mode because multiple workers can't share a SQLite file without corrupting it. Redis runs the Bull queue that holds pending jobs. The n8n editor container is the UI and API surface. The n8n worker container is the execution engine. You can run multiple workers, but every worker must point at the same Postgres and Redis, and every worker must have the same `N8N_ENCRYPTION_KEY`. Mismatched encryption keys across workers will cause credential decryption failures that are maddening to debug because they only show up at execution time.

### Implementation Details for n8n ETL (Using n8n official docker image)

The Docker image `n8nio/n8n:2.36.8` serves both the editor and the worker. The editor runs the default command—the container starts the n8n server on port 5678. The worker container overrides the command to `n8n worker`. Both containers need the same core environment variables: `DB_TYPE=postgresdb` with the Postgres connection string, `EXECUTIONS_MODE=queue`, and the Redis connection details. `WEBHOOK_URL` tells n8n what public URL to use when generating webhook endpoints—set this to your Railway-provided URL or custom domain. `N8N_PROXY_HOPS=1` accounts for Railway's proxy layer so n8n correctly reports client IPs and builds URLs. `N8N_ENCRYPTION_KEY` is the encryption key for stored credentials; generate a random string once, store it somewhere safe, and never change it. `EXECUTIONS_DATA_PRUNE=true` keeps the database from ballooning by pruning old execution data automatically.

The volume at `/home/node/.n8n` is non-negotiable. This is where n8n stores its config, database (if you were on SQLite, which you're not here), and encrypted credentials. On Railway, attach a volume to both the editor and worker containers. The worker technically needs read access to the volume for credential decryption, though in practice most of the heavy lifting happens in Postgres.

## How does n8n ETL compare against other ETL and data pipeline platform


## 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-etl