n8n Self-Hosted
IntermediateAutomationSelf-hosted n8n on your own server, with full control over the database, the host, and how it's exposed to the internet.
Published 27 September 2026
About n8n Self-Hosted
Self-hosting n8n with Docker gives you a production-grade automation platform on infrastructure you control, with no per-execution pricing and no workflow data leaving your server. Docker Compose runs n8n and its database on one instance, and the same setup works on a flat-rate VPS, a major cloud, or hardware you own. A container platform is the one exception: it deploys the official image through its own CLI and terminates TLS at its edge, so no reverse proxy is needed.
PostgreSQL is the production default, storing workflows, credentials, and execution history with real concurrency. SQLite, n8n's built-in store, trades that for zero database administration, which suits light workloads on a single process. Managed Neon offers the same PostgreSQL durability without running the database yourself. When one instance stops keeping up, the Redis add-on switches n8n into queue mode, with separate workers pulling executions from the queue.
Getting n8n reachable from the internet takes one more decision. Configure a reverse proxy yourself, or install a self-hosted PaaS that bundles one and gives you a deploy dashboard instead of a config file; pick one path, not both. On AWS or Google Cloud the provider's load balancer can take that job instead. Both paths are still self-hosting, since you own the server. To skip the decision entirely, the n8n Quick Deploy stack starts from a provider's one-click template.
Two settings matter on any path: WEBHOOK_URL must point at the public HTTPS address, or webhook nodes show internal URLs, and the encryption key that protects stored credentials has to be backed up with the database.
Key Features
- ✓The same Docker setup on a flat-rate VPS, a major cloud, a container platform, or your own hardware
- ✓PostgreSQL for production, SQLite for zero-admin simplicity, or managed Neon Postgres
- ✓A reverse proxy you configure, or a self-hosted PaaS that bundles one
- ✓Optional queue mode: add the Redis queue broker and run separate worker processes
- ✓Full control over n8n version, environment variables, and update cadence
- ✓All workflow data and credentials stay on infrastructure you own
When to Use n8n Self-Hosted
- →Teams whose execution volume has outgrown n8n Cloud's plan limits
- →Organizations with data residency requirements for automation data and credentials
- →Companies standardizing on self-hosted tooling across their stack
- →High-volume integrations where per-execution pricing becomes expensive
- →Teams that need custom n8n nodes or source-level modifications
Pros
- No per-execution pricing; the cost is the server
- Database, host, and exposure method are each swappable to match your scale
- PostgreSQL handles production workflow history, and queue mode adds workers when needed
- Complete control over configuration, upgrades, and data retention
Cons
- Server maintenance, updates, and backups are your responsibility
- More setup than an n8n Cloud account or the Quick Deploy stack
- High availability needs queue mode and more configuration beyond a single server
- The major clouds add billing and IAM complexity that a flat-rate VPS avoids
Database Options for n8n Self-Hosted
n8n Self-Hosted with PostgreSQL
The production default: PostgreSQL stores workflows, credentials, and execution history with real concurrency support. It's required for queue mode, so pair it with the Redis add-on when executions need separate workers.
n8n Self-Hosted with SQLite
n8n's built-in default storage: no separate database container, and backups are a copy of one file. Right for light workloads on a single process. SQLite can't take concurrent writes from several n8n processes, so queue mode and multi-instance scaling aren't available on it.
n8n Self-Hosted with Neon
A managed, serverless Postgres alternative if you'd rather not run the database container yourself: the same durability as self-hosted PostgreSQL, with Neon handling backups, scaling, and patching. Your workflows and credentials then live on Neon's infrastructure, and a Redis queue broker, if you add one, still runs on your server.
These are highlighted picks. To see all the tools, check the Databases category.
Hosting Options for n8n Self-Hosted
Deploy n8n Self-Hosted on Hetzner
n8n's own docs include a Hetzner guide, which calls a 2 vCPU / 2 GB server enough for most usage. A flat-rate root VPS here starts around €4-5/mo with 4 GB of memory, enough for n8n, PostgreSQL, and a couple of queue-mode workers on one box, with backups and updates left to you.
Deploy n8n Self-Hosted on DigitalOcean
n8n's docs include a DigitalOcean guide, where a basic shared-CPU Droplet is enough for most usage: about $12/mo for 2 GB. Managed PostgreSQL (from about $15/mo) can take execution history and credentials off the Droplet with automated backups.
Deploy n8n Self-Hosted on Hostinger
The budget VPS in the list: the entry KVM plan (about $6.50/mo on a two-year term) has 4 GB of memory, twice n8n's usual need. If you'd rather not configure Docker and a proxy yourself, the separate n8n Quick Deploy stack starts from Hostinger's own one-click n8n template instead.
Deploy n8n Self-Hosted on Amazon Web Services
Run n8n on an EC2 instance (a t3.small with 2 GB is typically enough to start) when your workflows call AWS services such as S3 or SES and should sit next to them. You'll set up a security group, an Elastic IP, and an EBS volume for the database, or let an Application Load Balancer with AWS Certificate Manager handle TLS instead of a proxy.
Deploy n8n Self-Hosted on Google Cloud Platform
Run n8n on a Compute Engine instance (an e2-small with 2 GB is typically enough to start) when your workflows call BigQuery or Cloud Storage and should sit next to them. You'll set up a firewall rule, a static external IP, and a persistent disk for the database, or let Cloud Load Balancing with Google-managed certificates handle TLS instead of a proxy.
Deploy n8n Self-Hosted on Fly.io
A container platform instead of a server you administer: deploy the official n8n image with flyctl and attach a persistent volume at /home/node/.n8n. TLS terminates at Fly's edge, so no reverse proxy is needed, and a shared-CPU machine with 2 GB costs about $11/mo, billed by the second.
Deploy n8n Self-Hosted on Raspberry Pi
Your own hardware, at the far end of the maintenance spectrum. n8n publishes ARM64 images, so the same Docker Compose setup runs on a Pi with no monthly bill beyond electricity, but uptime, updates, backups, and SD-card wear are yours. A home connection sits behind NAT, so pair it with a tunnel add-on: Cloudflare Tunnel for public webhook URLs, Tailscale for access from your own devices only.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
Reverse Proxy Options for n8n Self-Hosted
n8n Self-Hosted with Traefik
Routes to the n8n container from Docker labels and renews Let's Encrypt certificates on its own; n8n's own Docker Compose example uses it. Set WEBHOOK_URL to the public HTTPS address so webhook nodes show URLs that outside services can call.
n8n Self-Hosted with Caddy
Automatic HTTPS from a few lines of config, the simplest fit for one n8n container; n8n's current Hetzner guide uses it. Caddy passes the WebSocket connection the editor uses for live execution updates, so no extra directives are needed.
n8n Self-Hosted with NGINX
The most familiar proxy, with TLS through Certbot. Add the HTTP/1.1 upgrade headers so the editor's live updates connect, disable proxy buffering for long-running webhook responses, and set WEBHOOK_URL on the n8n side to the public address.
Self-Hosted PaaS Options for n8n Self-Hosted
n8n Self-Hosted with Coolify
Free and self-hosted, with one-click n8n templates, including versions with PostgreSQL and with queue-mode workers, deployed behind Coolify's bundled proxy with HTTPS. The middle ground between writing a proxy config yourself and the fully bundled Quick Deploy stack.
n8n Self-Hosted with Dokploy
Free and self-hosted, with n8n in its template catalog, deployed behind its bundled Traefik with HTTPS from the dashboard. Its scheduled database backups cover PostgreSQL; keep a copy of n8n's encryption key with them, or restored credentials can't be decrypted.
n8n Self-Hosted Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.
Tunnel Add-ons
Add a tunnel when you're self-hosting without a static IP or can't open inbound ports — a home server, a VPS behind restrictive network policies, or anywhere a reverse proxy alone can't reach the internet.
n8n Self-Hosted with Cloudflare Tunnel
Gives n8n a public HTTPS hostname through an outbound-only connection, with no inbound ports or static IP, so outside services can reach its webhooks from a Pi or home server. Protect the editor path with Cloudflare Access while leaving the /webhook/ paths public.
n8n Self-Hosted with ngrok
The quicker-start tunnel for receiving test webhooks from a SaaS app on an n8n instance running on your own machine. Its free-tier limits suit development rather than production webhook URLs that other services depend on.
n8n Self-Hosted with Tailscale
Private access instead of public exposure: Tailscale joins the server to an encrypted private network, so the n8n editor is reachable only from your own devices with nothing opened to the internet. Right for a personal instance; workflows that need public webhook URLs still want Cloudflare Tunnel alongside or instead.
Queue Broker Add-ons
Add a queue broker when one process stops keeping up: it lets a service hand work to separate workers and scale execution past a single instance.
n8n Self-Hosted with Redis
n8n's queue mode runs worker processes that pull executions from Redis, separating the main instance from the work, the standard scaling step once concurrent executions saturate one process. Each worker adds roughly 200-500 MB of memory. The stack runs fine without it, and it needs one of the PostgreSQL database options, since queue mode isn't available on SQLite.
Frequently Asked Questions about n8n Self-Hosted
Why self-host n8n instead of using n8n Cloud?
Execution limits and data location. n8n Cloud's Starter plan is $20/mo billed yearly for 2,500 executions a month, and Pro is $50/mo for 10,000. A self-hosted instance has no execution limit, keeps credentials and execution data on your server, and costs whatever the server does. The license allows it for your own business: n8n's Sustainable Use License covers internal business use, though reselling n8n as a service needs a commercial agreement. What you give up is managed operations: updates, backups, and uptime are yours.
How is this different from n8n Quick Deploy?
Quick Deploy starts from a pre-assembled template, a provider's one-click marketplace image or a container-platform template, that bundles the database, proxy, and TLS, so you make almost no decisions. This stack has you choose each piece, which buys free choice of database, host, and exposure method, plus queue mode for high throughput. Start on Quick Deploy to have n8n running in minutes; start here if you already know the shape you want or need something a template can't give you.
What size server does n8n need?
Less than most expect. n8n's docs put the process at around 100 MB idle, and its own Hetzner guide calls a 2 vCPU / 2 GB server enough for most usage levels; 2 GB also fits a small PostgreSQL on the same box. Memory, not CPU, is what workflows consume, and large payloads held in memory are what push it up. Each queue-mode worker adds roughly 200-500 MB. Disk grows with execution history, which n8n prunes after 14 days by default, so 40 GB is plenty.
PostgreSQL or SQLite for the n8n database?
SQLite is n8n's built-in default and fine for a solo operator running dozens of executions a day: one container, no database to manage, backups by file copy. Its hard limit is concurrency, since SQLite can't take writes from multiple n8n processes, so queue mode and multiple workers are off the table. Switch to PostgreSQL once concurrent executions matter. On either store, back up n8n's encryption key with the database: stored credentials are encrypted with it, and a restore without it leaves them unreadable.
How do I expose n8n running on a Raspberry Pi at home?
Through the tunnel add-ons, not port forwarding. A home connection sits behind NAT without a stable public IP, so the two clean paths are Cloudflare Tunnel, which connects outbound and gives your workflows public HTTPS webhook URLs on a domain you control, and Tailscale, which makes the editor reachable only from your own devices. Whether outside services must call your webhooks decides it: if they do, use Cloudflare Tunnel; if the instance is just for you, Tailscale is the simpler lockdown.
Stacks Related to n8n Self-Hosted
Strapi Self-Hosted
Infrastructure
Self-hosted Strapi: an open-source headless CMS with PostgreSQL, on a server you control.
n8n Quick Deploy
InfrastructureDeploy n8n in one click from a VPS marketplace template or a container-platform template, without assembling Docker, a proxy, or TLS yourself.
Airflow Self-Hosted
Infrastructure
Self-hosted Apache Airflow: the standard data-pipeline scheduler on your infrastructure.
GitLab Self-Hosted
Infrastructure
Self-hosted GitLab with Docker: your code, your CI, your infrastructure.
Scores
Popularity4/5
n8n sits among the most-starred automation projects on GitHub and is half of every n8n-versus-Zapier comparison; self-hosting it is one of the most-documented paths in the hobby.
Learning Curve3/5
Building workflows is visual, but production self-hosting adds Docker, a database, queue mode, and TLS routing: comfortable for anyone who has run a server, a real step up from n8n Cloud.
Flexibility5/5
The full node library plus custom-node code, with database, host, and exposure all swappable in this stack and queue mode scaling execution across workers.
Performance4/5
A single instance carries most automation loads; with PostgreSQL and Redis in queue mode it runs hundreds of concurrent executions across separate workers.
Portability5/5
Workflows export and import cleanly between instances, the Docker setup runs on any Linux host, and n8n Cloud remains a supported destination.
Tools in the n8n Self-Hosted Stack
n8n Self-Hosted Pricing
n8n's self-hosted edition, PostgreSQL, SQLite, Docker, and the optional Redis add-on are all free, so the recurring cost is the server: $5-20/mo on a VPS for a personal or small-team instance, about $11/mo for a 2 GB container-platform machine, or one-time hardware on a Raspberry Pi. Queue-mode setups with several workers want a step up. n8n Cloud starts at $20/mo billed yearly for 2,500 executions a month, a limit self-hosting never hits.
2 GB of RAM covers most n8n usage with PostgreSQL on the same server; each queue-mode worker adds roughly 200-500 MB.
PostgreSQL and SQLite are free, Neon's free tier covers the managed-Postgres option, and the optional Redis add-on costs nothing either.
Traefik, Caddy, NGINX, Coolify, and Dokploy all self-host free; only their optional managed clouds cost anything.
n8n Self-Hosted System Requirements
- CPU
- 1-2 vCPU; n8n itself is not CPU-intensive
- RAM
- 2 GB covers most usage, with PostgreSQL on the same box
- Disk
- 40 GB SSD; execution history grows first
- OS
- Any Linux with Docker
No official requirements published — tekyous guidance based on the bundle's services.
n8n's docs give an illustrative 320 MB to 2 GB memory range with roughly 100 MB idle, and its own Hetzner guide calls a 2 vCPU / 2 GB server enough for most usage levels. That guide runs SQLite; a small PostgreSQL still fits in 2 GB. Queue-mode workers add roughly 200-500 MB each, and the optional n8n Assistant sandbox needs 4 GB / 2 vCPU. Workflow data held in memory sets the real appetite.