One of n8n’s biggest differences from Zapier and Make is that it doesn’t require their cloud at all. Because it’s fair-code licensed, a business can run n8n entirely on its own servers. That changes both the cost model and the security conversation, but it also adds real operational responsibility that shouldn’t be underestimated.
This post covers what self-hosting gives you, what it asks of you in return, what a sensible production setup looks like, and how to decide whether it is the right choice for your workflows.
What Self-Hosting Actually Buys You
Data never leaves infrastructure you control. For workflows touching customer PII, financial data, or internal systems with strict access requirements, that removes an entire category of vendor-risk and compliance questions. It also removes per-task or per-operation billing: cost becomes infrastructure spend, which is usually far cheaper at high execution volumes than a metered SaaS plan.
There are quieter benefits too:
- Network access to internal systems. A self-hosted instance can sit on the same private network as your databases and internal tools, so workflows can reach them without exposing those systems to the internet.
- Control over upgrades. You decide when to move to a new n8n version, and can test it first instead of having it change underneath a running workflow.
- Control over where data is stored. You choose the region and provider, which can matter for businesses with data residency requirements.
What It Costs You Instead
Someone has to provision the server, keep n8n and its dependencies patched, manage backups of workflow data and credentials, and handle uptime. n8n publishes an official Docker image and a documented deployment path, which makes the initial setup straightforward on something like DigitalOcean or AWS. But “straightforward to deploy” and “maintained long-term” are different commitments. A self-hosted instance that nobody owns operationally becomes a liability the first time it goes down mid-workflow.
The ongoing responsibilities usually include:
- Applying n8n updates and operating system security patches on a regular schedule.
- Backing up the database and testing that the backups actually restore.
- Protecting the encryption key n8n uses for stored credentials. If that key is lost, the stored credentials cannot be decrypted, even from a good backup.
- Watching disk space, memory, and CPU, especially as execution history grows.
- Responding when the instance is down, including outside office hours if workflows run around the clock.
A Reasonable Self-Hosted Setup
A typical production setup separates the n8n application from its database (PostgreSQL rather than the default SQLite for anything beyond light use), puts it behind a reverse proxy with TLS, and runs webhook-triggered workflows behind authentication rather than open endpoints. Queue mode, which separates workflow triggering from execution across multiple workers, matters once volume or execution time grows. A single-instance setup will bottleneck under load that queue mode handles cleanly.
A practical checklist
- Run n8n in Docker using the official image, with versions pinned rather than always pulling the latest.
- Use PostgreSQL as the database, ideally a managed instance or at least one with automated backups.
- Put a reverse proxy in front with TLS, so all traffic is encrypted.
- Restrict access to the editor with strong authentication, and limit who has admin rights.
- Secure webhooks with authentication headers or tokens so they are not open endpoints.
- Store the encryption key safely and separately from the server itself.
- Set execution data pruning so execution history does not grow until the disk fills.
- Add uptime monitoring and alerts for the instance and for failed workflow executions.
- Enable queue mode with Redis and separate workers when volume or long-running executions require it.
- Write down the restore procedure and test it at least once.
When queue mode becomes necessary
In a single-instance setup, the same process receives triggers and runs workflows. If a few long executions are running, new triggers wait. Queue mode splits those jobs: the main instance receives triggers and places executions on a queue, and worker processes pick them up. You can add workers as load grows. It adds moving parts (Redis and multiple processes), so it is worth enabling when you actually need it, not on day one by default.
Security Basics For A Self-Hosted Instance
An n8n instance holds credentials for many of your other systems, which makes it a valuable target. Treat it with the same care as any system that holds keys to your business:
- Least privilege for credentials. Give each stored credential only the permissions its workflows need, not full admin access to the connected system.
- Limit network exposure. Keep the database and Redis on a private network, and expose only what must be reachable through the reverse proxy.
- Review who has access. Remove accounts when people leave, and keep the number of admins small.
- Keep secrets out of workflows. Use n8n’s credential store or environment variables rather than pasting keys directly into nodes.
- Log and review. Keep server and access logs long enough to investigate an incident if one happens.
None of this is unusual for production infrastructure. The point is that self-hosting makes it your job rather than a vendor’s, so it needs to be planned and owned.
Common Mistakes
- Staying on SQLite after the instance becomes business-critical.
- Exposing the editor or webhooks to the internet without authentication.
- Backing up the database but not the encryption key, or never testing a restore.
- Leaving execution history to grow without limits.
- Upgrading directly in production without checking release notes for breaking changes.
- No named owner for the instance, so nobody notices when it stops.
When Cloud Still Makes More Sense
If the workflows are low-volume, don’t touch sensitive data, and nobody on the team wants to own server maintenance, n8n’s managed cloud offering (or Zapier/Make entirely) is a reasonable trade of a monthly fee for zero operational overhead. Self-hosting is a decision to make deliberately, not a default.
A simple way to decide is to ask three questions. Does the data need to stay on infrastructure you control? Is execution volume high enough that metered pricing becomes expensive? Is there someone who will own the server long-term? If the answers are mostly no, managed cloud is likely the better choice. If they are mostly yes, self-hosting is worth the effort.
How We Scope This
When CodeixLab sets up a self-hosted n8n instance for a client, the infrastructure work (provisioning, database choice, backup strategy, monitoring, queue mode if needed) gets scoped alongside the workflows themselves, not as an afterthought. That’s the same discipline we apply to any DevOps and cloud engagement.
The workflows themselves are designed as part of our AI automation and integration work, so the infrastructure is sized for what the workflows actually need. We also agree up front who owns the instance after handover, whether that is the client’s team or an ongoing support arrangement with us.
Frequently asked questions
Is self-hosted n8n free?
The software can be self-hosted under its fair-code license, but you still pay for the server, database, backups, and the time someone spends maintaining it. Check n8n’s current license terms for your specific use case.
Can I start on SQLite and move to PostgreSQL later?
You can, but migrating later is extra work. If the instance is likely to become important, starting with PostgreSQL is usually simpler.
Do I need queue mode from the start?
Usually not. Start with a single instance and move to queue mode when volume or long-running executions start causing delays.
Who should own a self-hosted instance?
Someone with clear responsibility for updates, backups, and uptime. If you do not have that person in-house, talk to us about setup and ongoing support.