Founder of Goodspeed
Self-hosting n8n is the reason a lot of teams choose it in the first place. You get a powerful automation platform running on your own infrastructure, with your data staying where you control it and none of the per-task pricing that makes hosted tools expensive at volume. The catch is that running it well at scale is a real discipline, not a one-click affair.
A single container is fine for a proof of concept. Production is different. At scale you need a proper database, a plan for the execution data that piles up, a way to add capacity as load grows, monitoring so you see problems early, backups you have actually tested, and security that holds up. Skip these and you end up with an instance that is slow, fragile, or quietly exposed.
This guide covers how we self-host n8n for teams that depend on it. It walks through why you self-host, the infrastructure choices, the database, pruning, scaling, monitoring, backups, and security, in the order that matters. The goal is automation you own that stays reliable as it grows.
Why self-host n8n in the first place
The three reasons teams self-host are control, cost, and data. Control means you decide the version, the resources, the network, and exactly how workflows run, rather than living inside the limits of someone else's cloud. You can install community nodes, run custom code, and integrate with internal systems that a hosted tool would never reach. Your automation is genuinely yours.
Cost is the second driver. Hosted automation platforms often charge per task or per operation, which is fine until you scale and then becomes punishing. Self-hosted n8n runs as many executions as your hardware allows for the price of that hardware, so high-volume automation gets dramatically cheaper. And data is the third: when everything runs on infrastructure you own, sensitive records never pass through a third party, which for many teams is not a preference but a requirement.
Docker or a virtual machine
Almost everyone should self-host n8n with Docker. Containers give you a reproducible setup, clean upgrades by swapping the image tag, and an easy path to the multi-service architecture you will need at scale. Docker Compose lets you define n8n, the database, and any supporting services in one file, so rebuilding or moving the whole stack is straightforward rather than a day of manual work.
A plain virtual machine still has its place. If your organisation standardises on VMs, or you want full control of the operating system, you can run n8n directly with a process manager. But you take on more maintenance and lose the easy reproducibility. For most teams the pattern is a VM or managed host that runs Docker, giving you a stable machine underneath and containerised services on top. That combination scales cleanly as your needs grow.
PostgreSQL over SQLite, every time at scale
n8n defaults to SQLite so it works instantly, and for a small personal instance that is fine. At scale it is a liability. SQLite is a single file with limited concurrent-write support, so as executions pile up and, especially, as you add workers or queue mode, it becomes a bottleneck and a corruption risk. This is not a marginal preference, it is the single most important infrastructure decision.
PostgreSQL is the answer. It handles many concurrent connections, which is exactly what a busy n8n instance with multiple processes demands. It copes with the large execution tables that high-volume automation produces, and it supports the indexing and pruning you rely on to keep queries fast. Migrate to Postgres before you scale, not after you hit a wall, because moving the database under load is far more painful than setting it up correctly at the start.
Prune execution data before it buries you
By default n8n saves the full data of every execution, and at scale that table grows relentlessly. Millions of rows of execution history slow the editor, drag out the Executions view, and bloat your backups. Left unchecked it is one of the most common reasons a healthy instance gradually turns sluggish, and it is entirely avoidable with a retention policy set from day one.
Use the EXECUTIONS_DATA_PRUNE and EXECUTIONS_DATA_MAX_AGE variables to automatically delete executions older than a set age, and cap the maximum count too. Decide deliberately what you keep: for many high-volume workflows, saving only failed executions gives you what you need to debug while shedding the vast weight of successful runs. Pruning is not housekeeping you do later. It is core capacity planning that keeps the database, and therefore the whole instance, fast.
Scaling out with queue mode and workers
A single n8n process has a ceiling. When executions start queueing behind each other, or a heavy workflow blocks lighter ones, you scale horizontally with queue mode. In this architecture the main instance receives triggers and pushes each execution onto a Redis queue, and separate worker processes pull jobs off and run them in parallel. Add more workers and you add more throughput.
This is what lets self-hosted n8n handle serious volume. Rather than buying an ever-bigger single machine that will hit the same wall, you spread the work across as many workers as your load needs, tuning concurrency per worker to match your hardware. Queue mode requires PostgreSQL, Redis, and a shared encryption key, so build those foundations first. For any instance running high volume or long jobs, this is the difference between keeping pace and backing up.
Monitoring with N8N_METRICS
You cannot run something at scale that you cannot see. n8n can expose Prometheus-compatible metrics through the N8N_METRICS environment variable, giving you execution counts, durations, and, in queue mode, queue depth. Feed those into your monitoring stack and you get graphs and alerts for the numbers that actually predict trouble, rather than finding out from a user that automation has stalled.
Watch the signals that matter: rising average execution time, a queue that is not draining, workers running hot on CPU or memory, and error rates creeping up. Pair the metrics with health checks on each container so an unhealthy process gets restarted or flagged automatically. Good monitoring turns operating n8n from a series of surprises into calm, routine maintenance, which is exactly what you want from infrastructure your business depends on.
Back up the database and the encryption key
Your n8n instance is only as safe as your last tested backup. The two things you must protect are the database, which holds your workflows, credentials, and execution history, and the encryption key, without which those stored credentials cannot be decrypted. Back up the database on a regular schedule with standard PostgreSQL tooling, and store the N8N_ENCRYPTION_KEY somewhere secure and separate.
The mistake people make is assuming a backup exists rather than proving it. Test your restore process on a fresh instance so you know it actually works and how long it takes, because the middle of an outage is the wrong moment to discover a gap. Keep copies off the primary machine, so a failure of that machine does not take your backups with it. Reliable, tested recovery is what separates real production from a demo that happens to be live.
Secure access with authentication and least privilege
A self-hosted n8n instance can reach a lot of your systems, which makes access control non-negotiable. Enable user management so every person has their own account rather than a shared login, and use strong, unique credentials. Never expose an unauthenticated editor to the public internet, because anyone who finds it can read your workflows and trigger your automations.
Apply least privilege to the credentials n8n stores too. Each connected service should use an account scoped to only what the relevant workflows need, so a mistake or a breach cannot cascade across everything. Rotate credentials periodically, keep your encryption key secret, and separate production from any test instance so experiments never touch live systems. Treating n8n as the sensitive piece of infrastructure it is, rather than an internal toy, is what keeps a powerful tool from becoming a liability.
Put HTTPS and a reverse proxy in front
Never run production n8n on plain HTTP. All traffic to the editor and, importantly, to your webhook endpoints should be encrypted, because those requests carry credentials and business data. The standard approach is to place a reverse proxy such as Nginx, Caddy, or Traefik in front of n8n to terminate TLS, so certificates and encryption are handled cleanly in one place.
A reverse proxy earns its keep beyond encryption. It gives you a single controlled entry point where you can add rate limiting, IP restrictions, and sensible headers, and it lets you route webhook traffic separately from the editor if you scale that out. Set the WEBHOOK_URL correctly so n8n generates the right public addresses behind the proxy. Getting the network edge right closes off a whole category of exposure that no workflow setting can address.
Manage configuration and upgrades deliberately
At scale, configuration should live in version control, not in someone's memory. Keep your Docker Compose files, environment variables, and any custom setup in a repository so the whole stack is reproducible and every change is reviewable. When configuration is codified, standing up a replacement instance or a staging copy is a quick, reliable operation rather than an anxious reconstruction from notes.
Handle upgrades with the same care. n8n releases often, and while updates bring real improvements, you do not want to discover a breaking change in production. Pin to specific versions rather than always pulling latest, test new versions on a staging instance with copies of your real workflows, and upgrade on a schedule you control. Deliberate change management keeps a fast-moving platform stable, which is precisely what a business-critical automation system needs.
Separate environments so testing never hits production
Once automation matters, you need somewhere to change it safely. Running a separate staging instance, ideally identical to production but pointed at test systems, lets you build and break workflows without any risk to live data or live integrations. It is the difference between confidently shipping a change and crossing your fingers every time you edit a production workflow.
Keep the environments genuinely isolated. Staging should use its own database, its own credentials, and its own encryption key, so an experiment cannot reach real customer records or fire real messages. Promote workflows from staging to production through an export and import step you control, and you get a clean, auditable path for change. As your n8n footprint grows, this separation is what lets a team work on it in parallel without stepping on each other or on live operations.
Plan capacity so scale never surprises you
Scaling well is proactive, not reactive. Rather than waiting for the instance to fall over, watch the trend of your key metrics and add capacity before you hit the ceiling. If execution volume is climbing month on month, if the queue is starting to hold jobs longer, or if workers are regularly near their memory limit, those are your signals to add a worker or provision more resources ahead of demand.
Right-size the components to their jobs. Give workers the CPU and memory that your heaviest workflows genuinely need, provision the database for concurrent load and a growing dataset, and keep Redis healthy since the whole queue depends on it. Capacity planning is not glamorous, but it is what keeps self-hosted n8n feeling fast and dependable as usage grows, instead of lurching from one performance fire to the next.
Self-host n8n properly, and it scales with you
Self-hosting n8n well is a handful of disciplines done consistently. Run it in Docker, put it on PostgreSQL, prune your execution data, and scale out with queue mode and workers when volume demands it. Monitor with N8N_METRICS, back up the database and encryption key and test the restore, and lock down access with authentication, least privilege, HTTPS, and separated environments.
Get those foundations right and you own a fast, reliable automation platform that costs a fraction of hosted alternatives at scale, with your data staying entirely under your control. That is the whole promise of self-hosting, delivered properly. If you want a team that builds automation you own, see our n8n case studies, including HubSync, or book a free call with our n8n team.
Written By
Founder of Goodspeed