Most comparisons stop at a feature table. This one goes after the part that actually decides the outcome: the operational work self-hosting creates, and what the licence does and does not let you do. If you are new to the tool, start with What is n8n?
In short
- Both support production. n8n's documentation says so explicitly; this is not a toy-versus-real choice.
- Cloud plans: a 14-day free trial with Pro features, then Starter, Pro and Enterprise.
- Self-hosted editions: Community (free), Registered Community (free, after registering your email), Business and Enterprise (paid license key).
- The Community edition is close to complete, but excludes specific governance features, listed below.
- The licence is fair-code, not open source. Three clear limitations, and a separate licence for enterprise files.
- The real cost of self-hosting is attention, not infrastructure.
What each option actually is
n8n Cloud is the managed service: n8n handles hosting, updates and scaling, and no installation is required. The documented plans are a Free trial (14 days with Pro features), Starter for individuals and small projects, Pro for power users and small teams needing higher limits and admin accounts, and Enterprise for organisations needing advanced security, scaling and dedicated support (n8n Docs).
Self-hosting means you run n8n on your own infrastructure, on-premises or in a private cloud. n8n documents several installation routes: a one-line setup script, Docker Compose (recommended for production deployments with databases and additional services), cloud providers including AWS, Azure, Google Cloud, DigitalOcean, Hetzner, Heroku and OpenShift, and npm — which n8n notes is deprecated from version 3.0 and best suited to local development (n8n Docs).
Crucially, all self-hosted installations run the same core product. Without a license key you get the free Community edition; adding a Business or Enterprise key unlocks those editions.
The decision table, as n8n frames it
n8n's own guidance maps situations to recommendations (Choose how to use n8n). Condensed:
| Your situation | n8n's recommendation |
|---|---|
| Want to start right away | Cloud |
| No technical expertise on the team | Cloud |
| Don't want to manage infrastructure | Cloud |
| Need full control over deployment | Self-hosted |
| Have customised use cases | Self-hosted |
| Have infrastructure and technical resources | Self-hosted |
| Want to run n8n for free | Self-hosted, Community edition |
| Need production-ready deployment | Either — both support production |
| Need enterprise features such as SSO | Either — paid plans exist for both |
Note what is not on that list: workflow volume, number of nodes, or how "serious" your use case is. The decision is about who operates the thing.
What the Community edition leaves out
This is where most self-hosting plans get revised. n8n documents the Community edition as including almost the complete feature set, excluding (Compare editions):
- Custom variables
- Environments
- External secrets
- External storage for binary data
- Log streaming (logging itself is included)
- Multi-main mode (queue mode itself is included)
- Projects
- SSO via SAML and LDAP
- Sharing of workflows and credentials — only the instance owner and the user who created them can access them
- Version control using Git
Read that list as a single theme: the Community edition is built for one operator, not for a team with governance. The missing pieces are how several people share, review, promote and audit work. A solo builder may never notice. A five-person team hits it in month two.
Registering your Community instance by email is free and unlocks folders, debug-in-editor and custom execution data. If you self-host, register — there is no cost and no reason not to.
Exact features per plan change, and n8n states the pricing page is the source of truth. Check it before committing.
The licence, in plain language
n8n's licences are based on the fair-code model, not standard open source. The Sustainable Use License covers the source in n8n's main GitHub repository except for branches other than master and files containing .ee. in the filename, which fall under the separate n8n Enterprise License (n8n Docs).
It grants the free right to use, modify, create derivative works and redistribute, with three limitations:
- Use or modify the software only for your own internal business purposes, or for non-commercial or personal use.
- Distribute it or provide it to others only free of charge and for non-commercial purposes.
- Do not alter, remove or obscure licensing, copyright or other notices.
n8n's FAQ then translates "internal business purposes" into something operators can act on: all use is allowed unless you are selling a product, service or module whose value derives entirely or substantially from n8n functionality. Examples it gives as not allowed: white-labelling n8n and offering it to customers for money, or hosting n8n and charging people to access it. Examples it gives as allowed: using n8n to sync data you control as a company, building an n8n node for your product, providing consulting services such as building workflows, and setting up or maintaining n8n on an internal company server.
There is also a specific answer on using n8n as a back end for a feature in your own app: usually yes, as long as the back-end process does not use users' own credentials to access their data. n8n's worked examples make the line concrete — collecting a user's own HubSpot credentials to sync their data is not allowed; embedding a chatbot that runs on your company's credentials, where end users only type questions, is.
What this means for the three people most likely to be reading this: running your own company's operations on n8n is squarely allowed. Building and maintaining workflows for clients as a service is explicitly allowed. Reselling hosted access, or embedding n8n so your customers' own credentials flow through it, needs a separate commercial agreement. This is a summary, not legal advice — read the licence and talk to n8n if you are near the line.
The part the feature table hides: operating it
A server costs a few dollars a month. That is not the expense. Here is what you are signing up for.
Installation and configuration. n8n recommends Docker for most self-hosting needs. Docker Compose is the documented route for production deployments with databases and additional services.
Backups you have actually restored. Your workflow definitions, credentials and execution history live in a database. An untested backup is a hope, not a plan.
The encryption key. n8n generates an encryption key on first startup, and you can supply your own. In queue mode, the main instance's encryption key must be shared with every worker so they can access credentials stored in the database (Enable queue mode). Lose that key and you lose access to every credential. Leak it and you have leaked all of them.
Updates. n8n advises updating frequently — at least once a month — to avoid jumping multiple versions at once, checking release notes for breaking changes, and using Environments to test an update on a test instance first (Update n8n). Note the trap: Environments is one of the features not in the Community edition, so the recommended safe-update path needs a paid plan or a second instance you maintain by hand.
Security. n8n documents a security surface that you own on a self-hosted instance: setting up SSL, configuring SSO, running security audits, disabling the public API, blocking specific nodes, enabling SSRF protection, rotating encryption keys and redacting execution data. None of these are exotic. All of them are now your job.
Scaling. If you outgrow a single process, n8n documents queue mode as the most scalable setup: a main instance receives triggers and webhooks and generates executions, passes the execution ID to Redis, and worker instances pick up the work, run it, write results to the database and report back. You scale by adding or removing workers. It also notes queue mode does not support filesystem binary data storage — you use S3 external storage instead, which is itself a Community-edition exclusion.
The MitHub go-live test
Before running revenue workflows on a self-hosted instance, answer five questions. Any "nobody" means use Cloud.
- Who updates it? A named person, with a recurring calendar entry.
- Who gets paged? When leads stop arriving on a Saturday, whose phone rings?
- Where is the encryption key backed up, and who else can reach it?
- When did you last restore a backup? Not take one. Restore one.
- What is the rollback plan if an update breaks a production workflow?
This is the same principle as MitHub's natural law that knowledge must not live in one person's head. An automation layer nobody can maintain except its builder is not an asset — it is a dependency with a single point of failure.
A reasonable default path
- Start on Cloud. Build your first three workflows. Learn what you actually need.
- Measure. After a month you will know your execution volume, your data-residency constraints and whether anyone will really own a server.
- Migrate only for a reason you can say out loud. "Our data cannot leave this jurisdiction." "We need custom infrastructure the managed service does not support." "At our volume the maths changed."
- If you self-host, register the Community edition, attach an error workflow that alerts a real person, and put updates on a calendar before you go live.
"It is free" is not a reason. It is a price, and price is the smallest part of this decision.
Next
Once hosting is settled, the work that matters is what you build. Start with the catalogue in n8n for GTM teams, get the CRM side right in CRM automation with n8n, and make failures visible with n8n error handling for production workflows. For the mindset behind all of it, systems thinking for AI automation is the one to read twice, and the Faculty of Revenue Reverse Engineering is where the whole path starts.