Quick answer: Self-hosting n8n means running the automation software on your own server instead of paying for n8n Cloud. You get unlimited workflow executions for the cost of a small server, full control over your data, and no per-run pricing. The trade-off is that you own updates, backups, and uptime yourself, so it suits technical users best.
Why Self-Host at All
n8n Cloud charges per workflow execution, which is fine at low volume and painful at high volume. A business running tens of thousands of executions a month can pay more for the cloud plan than for a whole server. Self-hosting removes the meter: the software itself is free under n8n’s fair-code license, and you pay only for the server it runs on — often a few dollars a month for a small virtual private server.
The second reason is control. With self-hosting, your data never leaves infrastructure you control. For businesses handling client data, health-adjacent information, or anything under strict privacy rules, that control is not a luxury; it is a requirement.
The third reason is flexibility. A self-hosted instance can run custom nodes, community packages, and integrations that a managed plan may restrict, and you can keep it running exactly the version you tested.
What You Need Before You Start
- A server. A small virtual private server with at least 1 GB of RAM is enough to learn on; 2 GB or more is comfortable for real workloads. Providers such as Hetzner, DigitalOcean, and Linode all work.
- A domain name or subdomain. Something like automations.yourbusiness.com, pointed at your server, so webhooks and the editor have a stable address.
- Basic command-line comfort. You will run a handful of terminal commands and edit one configuration file. You do not need to be a system administrator, but you should not be afraid of a terminal.
- A backup plan. Your workflows and credentials live in a database on that server. If the server dies without a backup, your automations die with it.
Setup Path: Docker (Recommended)
The standard way to self-host n8n is Docker, which packages n8n and its dependencies into one container.
Step 1: Prepare the Server
Point your subdomain at the server’s IP address and make sure ports 80 and 443 are open. Install Docker on the server following Docker’s official guide for your operating system.
Step 2: Run n8n
n8n publishes an official Docker image. A basic run mounts a data folder so workflows survive restarts, sets the host address to your subdomain, and enables secure cookies. The exact command is in n8n’s official self-hosting documentation — follow it rather than copying commands from blog posts, because flags change between versions.
Step 3: Put It Behind HTTPS
Never run the n8n editor over plain HTTP in production: it holds credentials to your other apps. Use a reverse proxy (such as Caddy, which handles certificates automatically, or Nginx with Let’s Encrypt) so the editor and webhooks are served over HTTPS.
Step 4: Create Your Account and First Workflow
Open your subdomain, create the owner account, and build one simple workflow — for example, a webhook that writes to a spreadsheet. Confirm it runs, then set up the backup described below before building anything important.
Pros and Cons, Stated Plainly
Pros
- Cost at scale. No per-execution pricing; a small server covers a large volume.
- Data control. Workflows, credentials, and execution data stay on your infrastructure.
- Flexibility. Custom nodes, community packages, and version control over upgrades.
- No vendor lock-in on pricing. Your costs do not jump because your automation usage grew.
Cons
- You are the operations team. Updates, security patches, backups, and downtime are your job.
- Setup takes time. Expect an afternoon for a first install done properly, versus minutes for a cloud signup.
- Scaling is manual. If volume grows beyond one server, you configure queuing and workers yourself.
- Support is community-based. There is no managed support team watching your instance.
Backups: The Step Everyone Skips
Back up two things: the n8n data folder (workflows, credentials, settings) and a written export of your workflows. Schedule automatic snapshots of the server if your provider offers them, and test restoring once — a backup you have never restored is a hope, not a plan. Export workflows to version control as well, so a bad edit can be rolled back in minutes.
n8n Cloud vs Self-Hosted: Which Should You Pick?
Choose n8n Cloud when you want automation without operations: no server, automatic updates, and support. Choose self-hosted when execution volume makes cloud pricing painful, when data must stay on your infrastructure, or when you need custom nodes and full control. Many teams start on Cloud, prove the value of automation, and move to self-hosted when volume justifies it — n8n lets you export workflows between the two, so the move is not a rebuild.
Security Checklist for a Self-Hosted Instance
- Editor served over HTTPS only, with a strong owner password.
- Server firewall open only on ports 80 and 443 (plus SSH from your IP).
- Automatic security updates enabled on the server operating system.
- Backups scheduled and restore tested.
- Webhook URLs treated as secrets, since anyone with the URL can trigger the workflow.
- n8n updated on a schedule, after checking release notes for breaking changes.
Is self-hosted n8n really free?
The software is free under its fair-code license, but the server is not: you pay your hosting provider for the virtual server, typically a few dollars a month for small workloads. There is no per-execution charge on top of that.
Do I need to know Docker to self-host n8n?
Basic Docker familiarity helps a lot, since the recommended install uses it. You need to run a few commands and understand volumes and restarts. If the terminal is completely new to you, n8n Cloud is the better starting point.
Can I move workflows from n8n Cloud to self-hosted later?
Yes. n8n workflows export as JSON and import cleanly into another instance, including a self-hosted one. Credentials need to be reconnected after import, since secrets are not carried in the export.
What happens if my server goes down?
Scheduled workflows pause and webhooks fail until the server returns. For business-critical automation, use your provider’s monitoring alerts and automatic snapshots, and keep a documented recovery procedure so anyone on the team can restart the instance.
Is self-hosting safe for client data?
It can be safer than cloud, because data never leaves your infrastructure — but only if you follow the security checklist above. An unpatched, HTTP-only server is worse than a managed cloud instance. Control is only an advantage when it is exercised.