Self-Hosting n8n in Production: A Practitioner's Guide

Self-hosting n8n is the default choice for teams who want workflow automation without per-execution pricing, data leaving their perimeter, or a hard ceiling on what they can build. It is also a real piece of infrastructure: a Node.js application, a Postgres database, a Redis queue when you scale, and a set of operational habits that decide whether it runs for years or falls over in month three.

This guide is written for engineers and ops leads who have decided (or are deciding) to run n8n themselves. It covers architecture choices, the licence you are actually agreeing to, security, scaling patterns, backup and disaster recovery, and the honest cost comparison with n8n Cloud. No hand-waving.

Why teams self-host n8n instead of using n8n Cloud

The commercial pitch for n8n Cloud is convenience: managed hosting, automatic updates, SSO on higher tiers, and support. The pitch for self-hosting is control and unit economics. Both are legitimate. The question is which trade-off fits your organisation.

Three reasons teams self-host in practice:

Execution volume. n8n Cloud is priced per execution, with the Starter plan capping at 2,500 workflow executions per month and higher tiers scaling upward. Once you are running scheduled jobs, webhook-driven integrations, and internal automations across departments, executions add up quickly. A single self-hosted instance on a £40/month VPS can handle tens of thousands of executions without additional metering. At high volume the crossover is not close.

NDData residency and sensitive integrations. If your workflows touch patient data, financial records, HR systems, or anything covered by contractual data-processing restrictions, keeping the execution engine inside your own VPC or on infrastructure you control removes an entire category of vendor risk. The ICO's guidance on international data transfers and the UK GDPR accountability principle both push toward this pattern when the data is meaningful.

Custom code and unrestricted nodes. Self-hosted n8n lets you install community nodes, run arbitrary code in Code nodes without the restrictions applied on Cloud, and integrate with private network resources (internal APIs, databases, on-prem systems) that a cloud tenant cannot reach without a VPN back-tunnel.

Reasons not to self-host: you have no one to own the infrastructure, your workflows are low-volume and low-sensitivity, or you need SOC 2 attestation on the platform itself rather than the workflows you build on it. In those cases n8n Cloud is the cheaper answer once you cost engineering time honestly.

Understand the licence before you commit

n8n uses the Sustainable Use Licence, a fair-code licence rather than a traditional open-source one. Read it before you deploy at any scale. In practice it allows:

• Internal business use, including commercial use inside your organisation, for free.
• Modification for your own internal purposes.
• Self-hosting at any scale for your own workflows.

It restricts:

• Offering n8n as a hosted service to third parties (a competitor SaaS).
• Removing or altering the licensing, branding, or attribution in the software.

For 99% of self-hosting scenarios - running automations inside your business, or an agency running automations on infrastructure the client owns - the licence is permissive and does what you need. If you are building a productised offering where clients log in to an n8n instance you run, talk to n8n's commercial team about an embed licence. Do not guess.

Architecture: single-instance vs queue mode

There are two supported deployment topologies. Pick based on execution volume and reliability requirements, not on what looks impressive on a diagram.

Single-instance (main mode)

One n8n process handles the UI, webhooks, and workflow execution. Data lives in Postgres (do not use the SQLite default for anything you care about). This is the right pattern for most mid-market deployments: up to roughly 10,000 executions per day, workflows that do not need parallelism beyond what a single Node.js event loop provides, and teams who value operational simplicity.

Minimum viable production spec: 2 vCPU, 4GB RAM, 40GB SSD, managed Postgres 14+ with automated backups. Docker Compose deployment. Expect to spend around £40-80/month on infrastructure at this size.

Queue mode

The main process handles UI and webhooks. Executions are pushed onto a Redis-backed BullMQ queue and picked up by one or more worker processes. This is the pattern for high throughput, long-running workflows, or any workload where you cannot afford a webhook to be blocked while a slow execution finishes.

Queue mode adds Redis as a dependency and requires thinking about worker concurrency, queue backpressure, and how to handle a worker that dies mid-execution. It is the right answer when you are consistently above ~10 concurrent executions or running workflows that take more than 30 seconds. Below that it is over-engineering.

A reasonable queue-mode setup: one main container (2 vCPU, 2GB), 2-4 worker containers (2 vCPU, 4GB each), managed Redis, managed Postgres. Kubernetes if your organisation already runs it, otherwise Docker Compose on a beefier VM works fine.

Setting up a production-grade instance

The n8n docs cover the mechanics of Docker deployment. What they cover less is the set of production defaults you should apply before anything hits real traffic.

Use Postgres, not SQLite. SQLite is the container default and it will corrupt under any real concurrency. Point DB_TYPE=postgresdb at a managed Postgres instance (RDS, Cloud SQL, Supabase, or DigitalOcean's managed offering). Enable point-in-time recovery.

Externalise secrets. Never bake credentials into the Docker image or Compose file. Use environment variables sourced from a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) or at minimum a .env file kept out of version control. Set N8N_ENCRYPTION_KEY once, store it in your secrets manager, and never rotate it casually - re-encrypting all stored credentials is a manual exercise.

Put a reverse proxy in front. Caddy or Nginx handles TLS termination, forces HTTPS, and lets you set sensible headers. Let's Encrypt for certificates. Set N8N_HOST, N8N_PROTOCOL=https, and WEBHOOK_URL to your public hostname so webhook URLs generate correctly.

Turn on user management and enforce SSO where possible. User management is free on self-hosted. SAML SSO and LDAP are Enterprise features - if your organisation requires them, factor the licence cost in. For teams under 10 people, native user management with strong passwords and 2FA is defensible.

Pin your version. Do not run n8nio/n8n:latest. Pin to a specific version tag and upgrade deliberately. n8n ships breaking changes in minor versions occasionally, and you want to know when you took the update.

Configure execution data retention. By default n8n stores full execution data indefinitely. This will blow up your Postgres instance within months. Set EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE to something reasonable (168 hours / 7 days is a common starting point). Successful executions rarely need to be kept longer than that; failures are what you actually want to inspect.

Security: what you are responsible for

When you self-host, you own the security posture. The attack surface is not enormous, but it is real: workflows contain credentials for every system they touch, so a compromised n8n instance is a compromised HubSpot, Salesforce, Postgres, S3 bucket, and Slack workspace all at once.

Baseline controls:

• Network isolation. If your workflows only need to be triggered internally, do not expose the instance to the public internet. Put it behind your VPN or in a private subnet with an internal load balancer. If you need public webhooks, expose only /webhook/* paths through a proxy and keep the editor UI private.
• TLS everywhere. No plain HTTP, even inside a VPC. Certificates are free.
• Credential hygiene. Use n8n's credential store rather than hardcoding secrets in workflow nodes. Rotate credentials when people leave. Audit which workflows use which credentials before you delete anything.
• Backups you have tested. A backup you have not restored is a wish. Once a quarter, restore your Postgres backup and your N8N_ENCRYPTION_KEY into a staging instance and confirm workflows execute. This catches encryption-key drift before it becomes a disaster.
• Update cadence. Track n8n's release notes. Security patches ship regularly. A monthly upgrade window is a reasonable minimum.
• Audit logging. Enterprise tier includes audit logs; on community edition, capture container stdout/stderr into a log aggregator (Loki, CloudWatch, Datadog) and set alerts on failed login attempts and workflow execution failures.

For UK organisations processing personal data, self-hosted n8n makes your GDPR position simpler in one respect (no additional processor to add to your ROPA for the platform itself) and harder in another (you are the controller for the operational security of the instance). The ICO's guidance on security under UK GDPR is the relevant reference.

Scaling patterns and what breaks first

Three things fail in production, roughly in this order:

Postgres fills up. Execution data pruning is not on by default. A workflow running every minute, storing 50KB of execution data each time, adds 2GB per month. Multiply by fifty workflows and you have a database problem within a quarter. Fix: aggressive pruning, and move to a larger managed Postgres tier before you need to.

Webhooks time out. On single-instance mode, a long-running workflow blocks the webhook response. HubSpot, Stripe, and other webhook senders retry aggressively when they time out, and you end up with duplicate executions. Fix: move to queue mode, or restructure workflows to acknowledge the webhook immediately and process async.

Memory leaks in long-lived workers. Node.js processes accumulate memory. Set a container restart policy that recycles workers on a schedule (nightly) or based on memory thresholds. This is boring and it works.

Scaling horizontally in queue mode is straightforward: add more worker containers, scale Redis if the queue backs up. The main process rarely needs to scale - it is doing very little work compared to the workers. What does need thought is Postgres connection limits: each worker holds a connection pool, and it is easy to exhaust a small managed database's connection cap with a dozen workers. Use PgBouncer or size the database accordingly.

The honest cost comparison

Infrastructure cost is the easy part. The full picture:

n8n Cloud (Pro tier, ~£50/month): 10,000 executions/month included, managed everything, updates handled. Break-even against self-hosting is roughly where you exceed the included execution volume or need a feature the Pro tier does not include.

Self-hosted, single instance: ~£40-80/month infrastructure (VPS + managed Postgres + backups). Add ~2-4 hours per month of engineering time for updates, monitoring, and occasional troubleshooting. At a loaded engineering cost of £80/hour that is £160-320/month in labour. Total: £200-400/month, effectively uncapped executions.

Self-hosted, queue mode: ~£150-300/month infrastructure. 4-8 hours per month of engineering time. Total: £470-940/month, supporting workloads that would cost thousands per month on Cloud.

The self-hosted numbers only make sense if you actually have someone doing the work. A common pattern we see: teams self-host to save money, then the person who set it up leaves, no one owns the instance, updates lapse, and eighteen months later there is a production incident nobody knows how to fix. If you cannot name the person who will own the instance for the next two years, use Cloud.

Frequently asked questions

Can I self-host n8n for free commercially?

Yes, for your own internal business use. The Sustainable Use Licence explicitly permits commercial use inside your organisation, including modifying the source, as long as you are not offering n8n as a hosted service to third parties or removing the branding. An agency running n8n on infrastructure owned by a client for that client's workflows is fine. An agency running a shared multi-tenant n8n instance where clients log in and build their own workflows is the case that needs a commercial conversation with n8n. When in doubt, read the licence text or email n8n directly.

What is the minimum server spec for a production n8n instance?

For a single-instance deployment handling up to 10,000 executions per day: 2 vCPU, 4GB RAM, 40GB SSD, and a managed Postgres 14+ database with at least 2GB RAM and 20GB storage. Do not use SQLite in production - it will corrupt under concurrency. Expect infrastructure cost of £40-80/month on a mainstream provider (Hetzner, DigitalOcean, AWS Lightsail). Above 10,000 daily executions or with workflows running longer than 30 seconds, move to queue mode with separate worker containers and Redis.

How do I back up a self-hosted n8n instance?

Two things need backing up: the Postgres database (which contains workflows, credentials, and execution history) and the N8N_ENCRYPTION_KEY environment variable. Without the encryption key, credentials in a restored database are unreadable. Use your managed Postgres provider's automated backups with point-in-time recovery enabled, and store the encryption key in a secrets manager separately. Test the restore process at least quarterly by restoring to a staging instance and confirming workflows execute. A backup you have not tested is not a backup.

Is self-hosted n8n GDPR-compliant?

The software itself does not determine GDPR compliance - your deployment and workflows do. Self-hosting gives you full control over where data is processed and stored, which simplifies international-transfer questions and record-of-processing obligations compared with using a US-based SaaS. You become the controller for the operational security of the instance, so the ICO's guidance on security measures applies directly. In practice self-hosting inside a UK or EU cloud region, with proper access controls, encryption at rest, and documented data-retention policies, is a defensible GDPR position for most mid-market use cases.

Should I use Docker Compose or Kubernetes?

Docker Compose on a single VM is the right answer for most self-hosted n8n deployments. It is simpler to reason about, easier to back up, and adequate for single-instance and small queue-mode setups. Move to Kubernetes only if your organisation already runs Kubernetes and has the operational muscle for it, or if you need to run multiple worker replicas with autoscaling. Running Kubernetes purely for n8n is over-engineering that will cost you more in operational time than it saves.

How do I handle n8n version upgrades without breaking workflows?

Pin your Docker image to a specific version tag rather than latest. Before upgrading production, spin up a staging instance with a copy of your production database and the target version, and run through your most critical workflows. Read the release notes for breaking changes - n8n occasionally deprecates node parameters or changes execution semantics in minor versions. Schedule a monthly upgrade window rather than upgrading reactively. Keep the previous version's container image available for quick rollback if a workflow breaks in production after the upgrade.

When should I move from self-hosted to n8n Cloud, or vice versa?

Move from Cloud to self-hosted when your monthly execution volume pushes you into higher pricing tiers than the infrastructure and engineering cost of self-hosting, when you need to integrate with private-network resources Cloud cannot reach, or when data residency requirements make Cloud awkward. Move from self-hosted to Cloud when the person who owned the instance has left and no one has picked up the work, when your execution volume has dropped below the crossover point, or when you need Enterprise features (SSO, audit logs, SLA) and the self-hosted Enterprise licence is more expensive than Cloud Enterprise.

Can I run community nodes on self-hosted n8n?

Yes, and this is one of the meaningful advantages over Cloud. Set N8N_COMMUNITY_PACKAGES_ENABLED=true and install community nodes through the UI or by adding them to the container image. Vet community nodes before installing - they run with the same permissions as the n8n process and can access all your credentials. Prefer nodes maintained by known contributors, check the source, and pin versions rather than tracking latest. For anything touching sensitive data, either audit the node code yourself or build the equivalent logic in a Code node.

Where to go from here

Self-hosting n8n is a reasonable default for mid-market teams with real automation volume, sensitive integrations, or a preference for owning their infrastructure. It is not a way to avoid engineering work - it is a way to trade per-execution pricing for operational responsibility. Get the architecture right the first time, apply the production defaults, test your backups, and name the person who owns the instance.

If you want a second pair of eyes on your deployment, or you are weighing self-hosted against Cloud for a specific workload, AI Advisory runs n8n in production for mid-market clients across the UK and can help you scope it properly.

Further reading

Sources referenced for context not directly cited in the body:

Ready to put this into production? book a discovery call.

• https://www.skool.com/content-academy/are-you-using-n8n-open-source-did-you-know-this
• https://blog.n8n.io/announcing-new-sustainable-use-license/
• https://n8n.io/legal/eula/
• https://community.n8n.io/t/clarification-on-sul-vs-commercial-license-for-client-automation-scenarios/214790?tl=en
• https://n8niostorageaccount.blob.core.windows.net/n8nio-strapi-blobs-stage/assets/n8n_Self_Hosted_Enterprise_Terms_and_Conditions_3ab8eb121f.pdf
• https://community.latenode.com/t/clarification-needed-on-n8n-licensing-rules-for-client-automation-services/30620
• https://github.com/n8n-io/n8n/blob/master/LICENSE.md