"Just self-host it, it is free" is the most common advice about n8n and the most incomplete. It is free the way a puppy is free.
I run n8n for my own work and for clients, so I have an opinion about when self-hosting is a smart move and when it is a mistake wearing a cost-saving costume.
Why people self-host
- Cost that does not scale with volume. Hosted automation tools usually charge per task or execution, so success makes the bill grow. A server costs the same whether it runs a thousand workflows or a million. I compared the pricing models in n8n vs Make vs Zapier.
- Control of your data. Everything stays on infrastructure you choose, in the region you choose. For clients with sensitive data, that can be decisive.
- No ceiling. You can install extra packages and run code freely, without hitting a plan limit.
What it actually takes
Running software for other people to depend on is a job. The setup is an afternoon. The upkeep is indefinite.
- A server. A small virtual private server is enough to start. You choose the provider and the region.
- Docker. The standard way to run n8n is as a container, which keeps the setup repeatable.
- A proper database. The default SQLite is fine for experiments. For anything a business depends on, use PostgreSQL.
- HTTPS and a domain. Webhooks need a stable, secure public address, usually through a reverse proxy such as Caddy or Nginx.
- Updates. New versions arrive regularly, including security fixes. Someone has to apply them, ideally after testing.
- Backups. Automated, off the server, and tested by actually restoring one.
- Monitoring. If the server dies at 2am, something should tell a human.
A production checklist
| Item | Why it matters |
|---|---|
| PostgreSQL, not SQLite | More robust under load, easier to back up and restore |
| Encryption key set and stored safely | Without it, saved credentials cannot be decrypted after a restore |
| Webhook URL configured correctly | Behind a proxy, n8n must know its own public address or webhooks break |
| HTTPS everywhere | Credentials and customer data travel over this connection |
| Firewall and restricted access | Do not leave the editor open to the whole internet |
| Automated, off-server backups | A backup on the same machine dies with the machine |
| Update routine | Falling far behind turns a small upgrade into a risky one |
| Failure alerts | Silent failure is worse than loud failure |
| Execution data pruning | Stored run history grows quietly until the disk fills |
The one people lose. n8n encrypts stored credentials with a key. If you restore a database onto a fresh server without that same key, every credential becomes unreadable and you re-enter them all by hand. Record the key somewhere safe, separate from the server, on day one.
The licence question
n8n is "fair-code": the source is available and you can self-host it for your own use, but it is not licensed the way a typical open-source project is. The terms limit some commercial uses, particularly offering n8n itself as a service to others.
This matters most if you build automation for clients. Read the current licence text rather than relying on anyone's summary, including mine, and ask n8n directly if your arrangement is unclear. Licences change, so check at the time you decide.
Who should not self-host
- Teams with nobody willing to own the server. If the answer to "who gets the alert at 2am?" is "nobody", use the hosted plan.
- Low volume users. A handful of workflows will not recover the cost of your attention.
- Anyone who needs it running this week and has never managed a server. The learning curve is real.
- Regulated businesses without security support. The responsibility for patching and access control becomes yours.
How to decide
- Estimate your monthly run volume honestly. Count every step, not every workflow.
- Price the hosted plan at that volume, and the server plus your time.
- Ask who owns it. Name a person. A system everyone owns is one nobody maintains.
- Check the licence against how you plan to use it.
- Start hosted if unsure. Exporting workflows and moving to your own server later is straightforward. Moving the other way after an outage is not fun.
Self-hosting is a good choice for the right team: high volume, data-sensitive, with someone competent and willing to look after it. For everyone else, paying for the hosted version is not a failure of ambition. It is buying back the time you would have spent being a system administrator.