"Self-hosted n8n in production: queue mode, workers and Redis"
A production n8n setup splits one main process from scalable workers through Redis, stores data in PostgreSQL, and treats backups, secrets, monitoring and upgrades as real work.
A single n8n container is fine for a prototype. For production, run it in queue mode: one main process takes in triggers and serves the editor, Redis holds the queue of pending executions, and separate worker processes run the workflows. Pair that with a PostgreSQL database instead of the default SQLite file, and you have a setup that scales and survives restarts.
- 01Triggerwebhook or schedule
- 02Mainqueues the execution
- 03Redisholds the queue
- 04Workerruns the workflow
- 05PostgreSQLstores the results
The rest of this guide covers what each piece does and what you need around it.
Main process vs workers
In the default mode, one n8n process does everything: it listens for webhooks, fires schedules, serves the UI and runs every workflow. One heavy execution can slow the editor, and a crash can lose whatever was running. Queue mode splits those jobs.
| Component | Role | Scale it by |
|---|---|---|
| Main instance | Receives triggers, serves editor and API, queues executions | Keep one, make it reliable |
| Workers | Pull executions from the queue and run them | Adding more, on several machines |
| Webhook processors (optional) | Receive webhook traffic only | Adding more for request bursts |
| Redis | Carries the queue between main and workers | Managed service or hardened container |
| PostgreSQL | Stores workflows, credentials and execution results | Storage, backups, pruning |
Long or CPU-heavy workflows no longer block incoming triggers, and capacity grows by adding workers.
Why Redis, and why not SQLite
Redis is the message broker between main and workers. It only carries the queue. Workflow definitions, credentials and execution results still live in the database, so Redis does not need to be treated like your system of record. It does need to be reachable by every n8n process: restrict network access to it and set a password.
Execution history grows quickly. Configure pruning so successful runs expire after a sensible window, and keep failed runs longer for debugging. Unbounded execution data is one of the most common reasons a self-hosted instance slows down over time.
Scaling workers
Start with a small number of workers and let measurements guide you.
- Watch queue depth. If jobs wait longer than your tolerance, add workers.
- Watch worker CPU and memory. Large files or big JSON payloads need more memory per worker.
- Tune concurrency per worker. Higher helps workflows that mostly wait on external APIs; lower protects workers doing heavy transformations.
- Respect downstream rate limits. More workers can mean more simultaneous calls to a throttled vendor API.
Secrets and credentials
n8n encrypts stored credentials with an encryption key. Every main and worker process must use the same key, or workers cannot decrypt credentials.
Other habits worth adopting:
- Inject configuration through environment variables or a secrets manager rather than baking values into images.
- Give each integration its own least-privilege credential instead of one broad key.
- Limit who can create or edit credentials, and put the editor behind single sign-on or a VPN where you can.
- Never log secrets from Code nodes.
Backups
Back up three things, and write down how to rebuild the environment (the Docker compose file, Terraform or equivalent) so recovery does not depend on one person's memory.
- The database, with automated backups and a restore you test on a schedule
- The encryption key, stored separately and securely
- Workflows exported to version control, so changes are reviewable and an instance can be rebuilt from files
- The environment definition, so the stack can be recreated
Monitoring and alerting
You cannot rely on someone noticing that a workflow stopped. Set up observability on three levels.
| Level | What to watch | Alert when |
|---|---|---|
| Infrastructure | CPU, memory, disk on main, workers, Redis, database | Resources near limits |
| Queue | Depth and age of the oldest waiting job | The queue keeps growing |
| Workflows | Failed executions and scheduled heartbeats | A run fails or is missing |
Use n8n's error workflow feature so any failed execution sends an alert with the workflow name, the node and the error. Expose the health endpoints and metrics n8n provides to your monitoring stack.
Upgrades
Treat n8n upgrades like any application release.
- Read the release notes for breaking changes.
- Pin the version in your image tag. Avoid floating "latest" tags in production.
- Run the main instance and all workers on the same version.
- Back up the database, then test the upgrade in a staging copy with your real workflows.
- Upgrade, watch the queue and error alerts, and keep a rollback plan.
How this looks at Techdome
Techdome engineers production-grade self-hosted n8n workflows. Our automation sprints case study covers five rapid deployments on n8n Enterprise, with an average sprint of two to four days and a reported reliability of 99.9%. Our Irish pharmaceutical distribution case study combined n8n Enterprise with Docker and AWS for an automated SFTP order and invoice integration into a national wholesale ERP.
We do not publish the internals of any client cluster here. What we describe above is the general shape of a sound production setup. See the n8n and workflow automation page, or the DevOps and cloud page for the infrastructure side.
Takeaways
- Use queue mode in production: a main process, Redis and one or more workers.
- Use PostgreSQL, prune execution data, and test your restores.
- Share one encryption key across all processes, and store and back it up as a top-tier secret.
- Monitor the queue and wire error workflows to an alert someone owns.
- Pin versions, stage upgrades and keep the main instance and workers aligned.
Have a project like this? Talk to our engineers.
