Someone told you that you should self-host n8n. It is “free”, they said, and “you own everything”. You looked it up and found a wall of terms: Docker, VPS, reverse proxy, environment variables. You closed the tab. You still do not know whether this is a good idea for your business, or a way to end up with a server nobody understands and a workflow nobody can fix.
This article explains, in plain terms, what it means to self-host n8n, what it takes to run it well, what it costs, and when the paid cloud version is simply the better decision. You will finish knowing whether it is right for you and what a proper setup looks like, so you can judge whether whoever builds it did it properly.
Our short view: self-hosting is right for a business that runs a lot of automation, handles sensitive data, or wants AI steps at the centre of its operations, provided one person (an employee or a developer on a light retainer) is responsible for the server. It is wrong for a business with three simple workflows and nobody technical within reach.
What self-hosting actually is
n8n is an automation platform: software that watches for something to happen in one system and then does a chain of things in other systems. It comes in two forms. n8n cloud is the company’s hosted version: you pay a subscription, log in to their website, and they run it for you. Self-hosting means you install the same software on a server you rent, and it runs there under your control with no per-workflow charge.
The ordinary-business analogy is a serviced office versus a leased unit. In the serviced office the landlord handles the locks, the cleaning, and the fire alarm; you pay more and follow their rules. In the leased unit you pay less and control everything, and someone on your side has to call the electrician. Self-hosting is the leased unit.
A server, for this purpose, is a rented computer in a data centre, usually a virtual private server (VPS): a slice of a larger machine rented monthly from a provider like Hetzner, DigitalOcean, or a cloud vendor. n8n runs on it inside a container (using software called Docker), a standard package that keeps the application and its settings bundled so it can be moved, updated, and restored cleanly.
1. Decide with a real count, not a feeling
Count what you will actually run: how many workflows, how often each fires. n8n cloud charges per execution (one run of one workflow, regardless of step count) in tiers. A business running a few hundred executions a month is well inside the cheapest tier, and self-hosting saves nothing worth the effort. A business running tens of thousands, or planning AI steps on every inbound email or lead, is where self-hosting stops being about pride and starts being about money.
Then weigh data and ownership. If medical, legal, or financial details flow through your workflows, running them on your own server in a region you choose is a meaningful control; see AI Data Privacy for Business, What Happens to Customer Data. And a self-hosted n8n cannot be switched off, repriced, or gated behind a new plan by a vendor. The workflows are plain files on your server, which is the main argument in Build vs Buy AI Tools for Your Business, the Decision Rules.
2. Rent a small server and do not oversize it
For most small businesses a VPS with two virtual processors and around four gigabytes of memory is plenty, and that class rents for somewhere between ten and twenty dollars a month from the major providers. n8n itself is light; what consumes resources is concurrent runs and the size of data passing through, and neither is large for a typical business.
Pick a provider with a data centre in the country you want your data to sit in, automatic backups as a checkbox, and simple resizing. Do not start large “just in case”; resizing takes minutes. Do turn backups on from day one. The server needs a domain name pointed at it (something like automation.yourbusiness.com), which your existing domain can carry as a subdomain for free.
3. Put it behind a reverse proxy with SSL from the start
SSL (the padlock in the browser, the reason an address starts with https) encrypts traffic between a browser and the server. n8n exposes a web interface and receives webhooks (messages from other systems telling it something happened), and both must travel encrypted, or passwords and customer data cross the internet in plain text.
The standard setup puts a reverse proxy in front of n8n: a small program (Caddy or Nginx) that receives all web traffic, handles the SSL certificate, and passes requests to n8n. Caddy obtains and renews certificates automatically from Let’s Encrypt (free) and needs almost no configuration, which is why we reach for it on small servers. If whoever builds your server skips this, that is a red flag.
4. Use a real database and prune the execution history
Out of the box, n8n stores workflows, credentials, and execution history in a single file (SQLite). For a business, our view is to use Postgres, a proper database server, running alongside n8n in its own container. It handles concurrent runs better, backs up more dependably, and is what n8n’s own documentation recommends beyond experimentation.
One setting matters more than the database choice: execution data retention. n8n keeps the full record of every run, including all the data that passed through, until told otherwise. Set it to prune successful runs after a few days to a couple of weeks and keep failed runs longer. Otherwise the database grows without limit, fills the disk, and holds six months of customer data nobody thinks about.
5. Back up three things and test restoring them
A backup you have never restored is a hope. Three things need backing up: the database (workflows, credentials, history), the encryption key n8n uses to protect stored credentials (a single string set at installation; lose it and every saved login is unrecoverable), and the configuration files that define how the containers run.
The minimum is a nightly database dump copied off the server to storage you control, with the encryption key and configuration in a password manager. The provider’s snapshots are a useful second layer but should not be the only one, because they live with the same provider as the server. Once a quarter, restore to a fresh temporary server and confirm a workflow runs. It takes an hour, and businesses that skip it discover on the worst day that the backup was empty.
6. Update on a schedule and never on a Friday
n8n ships new versions frequently, bringing fixes, integrations, and security patches, and a server left un-updated for a year is a security risk waiting to happen. Because n8n runs in a container, updating is normally a matter of pulling the new version and restarting.
The habit is the schedule. Pick a monthly window, read the release notes for anything marked breaking, take a backup, update, and open the two or three most important workflows to check they still run. Do it mid-week and mid-morning so there is a working day to fix anything. Turn on automatic security updates for the server’s operating system too; most providers offer it.
7. Lock the door: accounts, access, and secrets
n8n has user accounts with roles. Give each person their own login and never share one. The person who built it should not be the only owner, because people leave. Keep the server’s own login (SSH) restricted to key-based access with password login disabled, and limit who holds the key.
Credentials for the systems n8n connects to are stored encrypted inside it. Create dedicated integration accounts or API keys for n8n rather than using a person’s personal login, with the narrowest permissions each workflow needs, so nothing breaks when an employee leaves. The same least-privilege thinking applies to any AI agent you later connect, the subject of AI Agent Permissions: Least Privilege for Business AI.
8. Wire up alerting and write the runbook before the first real workflow
A self-hosted server has nobody watching it unless you arrange it. Two alerts are needed. At the workflow level, n8n lets you designate an error workflow that runs whenever any other workflow fails; it should message a person with the workflow name and the error. At the server level, a simple uptime monitor (several free services check an address every few minutes) texts or emails when the server stops responding. Without both, a self-hosted n8n fails in silence. The full pattern is in Automation Error Handling for Businesses Tired of Silent Failures.
Alongside that, export workflows as JSON files (a standard text format) after every meaningful change and commit them to a code repository the business owns, and keep a one-page runbook: where the server is, how to log in, where backups go, how to restart and update n8n, and who to call. The runbook is what turns “only Sam knows how it works” into an asset the business owns.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: an independent insurance agency with 18 staff and a large book of small-business clients, handling policy documents, claims correspondence, and payment details every day. Over eighteen months they built a dozen workflows on a cloud platform: intake forms to the agency management system, renewal reminders, document requests, and a daily summary for the principals. They now want AI steps that read incoming claims emails and file them against the right client, which would fire hundreds of times a day.
What is wrong: the projected volume moves them several tiers up on the cloud plan. Two carriers have started asking in security questionnaires where client data is processed. And the person who built everything is leaving in two months.
What an agency like this would build:
- A small VPS in a US data centre with daily snapshots on, running n8n and Postgres in containers behind Caddy with automatic SSL.
- Execution retention set to seven days for successful runs and ninety for failures.
- Nightly database dumps to a storage bucket the agency owns, the encryption key and configuration in the agency’s password manager, and one test restore before go-live.
- The twelve workflows migrated one at a time, exported to a private repository after each, with the cloud versions left running in parallel for a week each.
- An error workflow that messages the operations lead, an uptime monitor, and a one-page runbook with named backup contacts.
- The claims-email AI step added last, with the model’s output checked for a valid client match before filing and every uncertain case routed to a person.
What changes: the platform cost drops to a server bill plus a modest retainer, the security questionnaire has a clean answer, and when the builder leaves, the runbook and the repository mean the business keeps its automation instead of losing it.
What it costs to run
The server: somewhere between ten and twenty dollars a month for a small VPS, a little more with snapshots. Off-server backup storage: a few dollars a month at most. The subdomain and SSL: free. n8n itself: free to self-host for ordinary business use; check the licence page if you plan to resell automation to others.
The real cost is maintenance time: two to four hours a month for updates, backup checks, and looking at failures, from an employee or a developer on a small retainer. Add AI usage if you have AI steps, priced per token by the model provider (a token is roughly a word fragment; short classification steps cost fractions of a cent each). Compare the total against n8n cloud at your projected volume and the decision is usually clear within minutes.
The mistakes we see most
No backups, or backups never tested. The server dies and the backup turns out to be empty.
The encryption key lost. Every stored credential becomes unreadable and every integration has to be reconnected by hand.
No SSL, or n8n exposed directly on the internet without a proxy. Credentials and customer data travel in the clear.
Execution history kept forever. The disk fills, the server slows, and months of customer data sit in a database nobody thinks about.
When to bring in help
If you have someone technical on staff who is comfortable with a command line, they can set up a good self-hosted n8n in an afternoon from n8n’s own documentation, and the habits above are the difference between a hobby install and a business one. Make them write the runbook.
If you do not have that person, the choice is between n8n cloud (simple, credible, more expensive at volume) and paying a developer to build and maintain a self-hosted setup. A build-and-hand-over with a small monthly retainer for updates and monitoring is a normal arrangement and usually pays for itself past the lower cloud tiers. The wrong decision is not cloud or self-host; it is a self-hosted server nobody is responsible for. What to look for in that developer is covered in How to Hire an AI Consultant Without Getting Burned.
Levelbrook sets up and maintains self-hosted n8n for businesses, on a fixed price from a written scope, with the server, the domain, the backups, and the repository all in accounts you own. If you want to know whether it makes sense for your numbers, the form below is the place to ask.