n8n self hosted means you run the n8n workflow engine on a server or cloud account your business controls, instead of on n8n's own Cloud service. Getting a basic n8n install running is the easy part. Running it well takes decisions most install guides skip: which database, whether you need queue mode, how backups and the encryption key are kept, who is alerted when a workflow fails, and how upgrades happen without breaking the invoices, leads or orders that flow through it.
The trade is simple to state. Self hosting gives you control over data location, network access and cost at volume. In exchange, someone on your side owns uptime, patching and recovery. If nobody will own that, n8n Cloud is usually the better choice, and this page says so where it applies.
Benian Technologies is an AI implementation partner that builds automations in accounts the client owns. When a client self hosts, we set n8n up inside their cloud account, document it and hand it over. We do not sell hosting or managed IT.
Where self hosted n8n goes wrong in a business
The default database is left in production
A fresh n8n install stores everything in SQLite on the same disk as the app. That is fine for a trial. Under real load, with many executions writing logs at once, it becomes slow, and a lost disk takes every workflow and credential with it.
The encryption key is not backed up
n8n encrypts stored credentials with a key. Restore a database backup without that exact key and every saved login and API token is unreadable. Teams find this out during the restore, not before.
Failures are silent
A workflow that stops syncing orders to the accounting system does not email anyone by default. The first alert is often a customer or the bookkeeper at month end.
Upgrades happen by accident
A container set to pull the latest image can jump several versions on a restart. A changed node or a breaking change then stops a live workflow with nobody watching.
n8n Cloud or n8n self hosted: how to decide
n8n Cloud is run by n8n. They handle the server, the database, upgrades and uptime, and the plans are priced by workflow executions. Self hosting means you run the same engine yourself, usually from n8n's official Docker image, and you pay for the server and the time to keep it healthy instead.
Self hosting tends to make sense in four situations: your data must stay in a specific cloud region or private network, workflows need to reach systems that are not on the public internet, your execution volume is high enough that per-execution pricing becomes the larger cost, or you already have someone who runs servers. It tends not to make sense when you run a handful of workflows, nobody on staff will own a server, or the main goal is to get the first automation live quickly.
Many firms start on Cloud, prove which workflows matter, then move to a self hosted instance once volume or data rules justify it. Workflows export as JSON, so the move is a migration, not a rebuild.
Is n8n open source? What the license allows
n8n describes itself as fair code, not open source in the strict sense. The source is public and you can self host it, but the main license is the Sustainable Use License rather than an OSI-approved license. Some features, generally those aimed at larger teams, sit under a separate paid enterprise license. Check which features you need before you plan around them.
In plain terms, the Sustainable Use License is written to allow use for your own internal business purposes, which covers most companies automating their own operations. It restricts things like selling n8n itself as a hosted service. If you plan to embed n8n in a product or run it for your customers, read the terms and ask n8n directly.
License terms change. Read the current license and n8n's own explanation of it before you commit, and treat this section as orientation, not legal advice.
A production n8n deployment: database, queue mode, workers and backups
A business-grade n8n deployment usually has four parts: PostgreSQL instead of SQLite, ideally a managed database in your cloud account; the n8n main process, which serves the editor and receives webhooks; for higher volume, queue mode, where executions go on a Redis queue and separate workers pick them up so one slow workflow does not hold up the rest; and a reverse proxy that handles HTTPS.
Server size depends on how many workflows run at once and how much data each carries. A small virtual machine handles a modest set of scheduled workflows. Large files, many parallel executions or big payloads need more, and that is where queue mode and workers earn their complexity.
Back up three things together: the Postgres database, the n8n encryption key and the environment settings. Add a scheduled export of workflows to storage you control, and restore to a test server at least once. A backup you have never restored is a hope, not a plan.
- Pin the n8n image to a specific version, never to latest.
- Set execution data pruning so the database does not grow without limit.
- Keep the encryption key in your cloud's secret manager.
Securing an n8n server: credentials, access, webhooks and updates
Every API key and login your workflows use is stored in n8n, so the editor deserves the same care as an admin panel for your finance system. Put it behind a VPN or an IP allow list where you can, and use single sign-on if your plan supports it, give each person their own account, and remove access the day someone leaves.
Webhooks are different. They have to be reachable by the systems that call them, such as a form tool or a payment processor. Route only the webhook paths publicly, check signatures or shared secrets where the sending service supports them, and keep the editor on a separate, restricted route.
Create credentials under accounts your business owns, not a contractor's personal email, with the narrowest scope each workflow needs. Community nodes run code on your server, so install only ones you have reviewed. Apply operating system and n8n security updates on a schedule.
Monitoring and failure alerts
n8n lets you attach an error workflow that runs whenever another workflow fails. Use it. A useful alert names the workflow, the failed step, the error and a link to the execution, and it goes to a channel a named person reads and owns. An alert nobody owns is noise.
A workflow can also stop running without failing, for example when a schedule is disabled or an upstream system stops sending webhooks. For workflows that carry money or customers, add a daily check that the expected runs happened. Watch the server too: disk, memory and whether n8n and the queue are up.
n8n upgrades without breaking live workflows
n8n releases often. Most updates are routine, but some change how a node behaves or require a migration. The safe pattern is the same each time: read the release notes and any breaking change notes for every version between yours and the target, back up the database and key, upgrade a staging copy first, run the workflows that matter most against test data, then upgrade production in a quiet window.
Do not fall far behind either. Skipping many versions makes each upgrade riskier, and old versions may no longer receive security fixes. A monthly or quarterly upgrade slot with a named owner and a rollback plan works for most firms.
What Benian sets up and what your team owns
When a client chooses n8n self hosted, Benian sets it up inside the client's own cloud account: Postgres, queue mode if volume calls for it, HTTPS, restricted editor access, backups with a tested restore, error workflows and alert routing. Credentials, deployment files and admin logins sit under the client's accounts. The handover runbook covers where everything runs and how to restart, restore and upgrade it.
After handover, someone has to own the server. That can be your IT person or provider, or Benian under a scoped support agreement for the workflows we built. We do not run general hosting, managed IT or round-the-clock infrastructure monitoring. If nobody on your side can take that role, we will usually recommend n8n Cloud instead, and build the same workflows there.
Cost depends on how many workflows you run, how many systems they touch, whether queue mode is needed, your security requirements and how much of the ongoing work you want to keep in house. Every engagement is scoped before it starts.