How We Run n8n in Production
We run n8n in production for every client workflow we build. Not the cloud version - self-hosted, on our own infrastructure, configured for the kind of reliability that business-critical automations demand.
This post is a look at how we run n8n at HadesFlow - the architectural decisions we’ve made and why they matter when workflows need to fire reliably around the clock.
n8n in Queue Mode
The single biggest decision in our setup is running n8n in queue mode. Out of the box, n8n runs in regular mode - one process handles everything sequentially. That works fine for building and testing workflows, but in production, a single long-running execution blocks everything behind it.
Queue mode changes the game. The main n8n instance handles webhooks and triggers, then pushes executions into a Redis-backed queue. Dedicated worker processes pick up jobs independently and run them in parallel. One slow workflow doesn’t block the rest. Failures stay isolated.
We deploy everything with Docker Compose - the n8n main instance, workers, Redis, and PostgreSQL each in their own container. This gives us the ability to restart or scale any component without touching the others.
Monitoring n8n in Production
Running n8n self-hosted means you own the uptime. We built a monitoring layer around our n8n deployment using Grafana with custom dashboards that track what matters: workflow execution rates, success/failure counts, queue depth, worker health, and the underlying server resources.
When something goes wrong - a worker stops responding, executions start failing, disk fills up - we get an alert in real time. We don’t find out from a client asking why their automation didn’t run. The entire monitoring setup is managed as code, so dashboards and alerts are versioned and reproducible across environments.
Keeping n8n’s Database Healthy
One thing that catches people off guard with self-hosted n8n is how fast the execution data grows. Every workflow run gets logged, and over time that table gets heavy.
We run automated cleanup that prunes old execution logs on a schedule, plus daily database backups with rotation. It keeps query performance consistent and means we never have to think about it - it just runs.
Separate Environments for n8n
We run two n8n environments: test and production. The test instance is where we build, experiment, and break things. Production is streamlined - only the services that need to be running. Every workflow proves itself in test before it reaches a client’s production automation.
Both environments use the same Docker Compose structure, so what works in test works in production. No surprises at deploy time.
Why We Self-Host
n8n Cloud is a solid product, but self-hosting gives us the control we need: queue mode for parallel execution, full observability into what’s happening at every layer, custom backup and retention policies, and the ability to tune the infrastructure to our workload.
For an agency running dozens of client workflows, that control is the difference between hoping things work and knowing they do.
Running n8n in production or thinking about it? We’re happy to share what we’ve learned. Get in touch for a free consultation.