Most automation platforms charge by the task. Run 50,000 operations a month on a mid-tier SaaS plan and your bill climbs in lockstep with your success. n8n took a different route: publish the source, let anyone self-host it, and sell the convenience of a managed version separately. The self-hosted build is the n8n Community Edition, and for a surprising number of teams it’s the entire product.
The fine print is worth reading before you move your critical workflows onto it, though. Here’s what you actually get, where the edges are, and how to run it so you’re not restoring from a backup at 2am.
What the Community Edition Really Is
n8n ships under the Sustainable Use License, which makes it source-available rather than open source in the strict OSI sense. You can read every line, fork it, and run it however you want inside your own organisation. What you can’t do is take that code and resell n8n as a service to other people. That distinction matters a lot if you’re building a commercial product on top of it.
Installation is genuinely quick. One Docker command gets you a working editor on port 5678; npm users can run npx n8n and be dragging nodes around within a minute or two. The editor itself is the same one paying customers use, so there’s no stripped-down canvas or missing node types to work around.
What You Get Without Paying Anything
- Unlimited workflows and executions, with no per-operation metering
- 400+ pre-built integrations, plus an HTTP Request node that reaches anything with an API
- Code nodes for JavaScript and Python when the visual builder runs out of road
- Webhook, form, schedule, and manual triggers
- Sub-workflows, error workflows, retries, and waiting nodes
- Community nodes installed from npm
- A CLI for exporting, importing, and scripting backups
The unlimited executions point is the one that changes behaviour. When every run costs money, you design defensively: batch everything, poll as rarely as possible, skip the nice-to-have automations. With a self-hosted instance, a workflow that fires every 60 seconds and does nothing most of the time costs you a rounding error. That freedom is what people actually mean when they say they moved to n8n and never looked back.
Setting It Up So It Survives Contact With Reality
SQLite is fine for a weekend experiment. For anything with real traffic, point n8n at Postgres from day one, because migrating a live database later is a miserable afternoon.
Three things bite people who skip the documentation. First, set N8N_ENCRYPTION_KEY yourself and store it somewhere safe, since it decrypts every saved credential on the instance. Lose it and your integrations become a pile of unreadable strings. Second, put the editor behind a reverse proxy with TLS and keep port 5678 off the public internet, because the default install isn’t hardened for exposure. Third, schedule n8n export:workflow –backup or commit exported JSON to git. Version control on the workflow files is the cheapest disaster insurance you’ll ever buy.
The Limits You’ll Run Into Eventually
One user, no single sign-on
Community Edition runs as a single owner account. There’s no SAML, no LDAP, no granular roles, and no way to give a contractor read-only access to one project. If five colleagues need different levels of access, that conversation ends at the Enterprise tier.
No workflow history or environments
Editing a live workflow means editing production. There’s no saved revision to roll back to when someone deletes the wrong node, and no built-in way to promote a workflow from staging to production. You can get close with git plus the CLI, but you’re building that pipeline yourself.
Support is the community
The forum and Discord are genuinely helpful, and the official docs are better than most. What you don’t get is an SLA. If your revenue depends on an automation running at 9am on a Monday, that’s a risk you’re accepting.
You are the operations team
Uptime is yours. Containers restart after host reboots, disks fill with execution logs, and Redis occasionally decides it’s had enough. None of it is hard, but somebody has to own it.
Community Nodes: Useful and Occasionally Terrifying
Community nodes come from the npm registry and install either through the GUI or by dropping packages into ~/.n8n/nodes. There are excellent ones for niche SaaS tools, and there are abandoned ones last updated three years ago. A community node runs with the same privileges as n8n itself, so treat installation as a supply-chain decision rather than a casual click.
Pin your versions in a private registry, skim the source of anything new, and check whether the maintainer responds to issues. Ten minutes of diligence beats discovering a rogue postinstall script six months later.
Scaling Past a Single Container
When one container stops keeping up, n8n switches into queue mode: Redis for the job queue, a main instance handling the editor and triggers, and separate worker containers chewing through executions. All instances need the same encryption key and the same database.
Two housekeeping settings matter more than the architecture. Enable execution pruning with EXECUTIONS_DATA_PRUNE and a sensible EXECUTIONS_DATA_MAX_AGE, or your Postgres instance will quietly swell into hundreds of gigabytes of history nobody reads. And raise worker concurrency gradually while watching memory, since a heavy Code node looping over a large array will happily eat a gigabyte on its own.
Automations People Actually Build First
New instances tend to follow a predictable path. The first workflow is usually a form submission landing in a spreadsheet with a Slack ping. Then come the CRM syncs, the invoice chasers, the nightly report that used to take an analyst ninety minutes. After that, it gets personal: monitoring a flight and messaging you only when the delay passes forty-five minutes, a schedule trigger hitting a status API, an IF node, and a notification. If you’d rather not maintain that particular API integration yourself, Flighty handles live flight tracking on the airport side, which is a fair reminder that not every problem needs a workflow.
Licensing Traps Worth Knowing About
Internal business use is free and always will be under the current license. Running n8n for clients as part of an agency retainer sits in murky territory. Rebranding it and selling it as your own automation platform is clearly off the table without a commercial agreement. If your business model involves hosting automation for other people, read the license text before you build the invoice, not after.
When Paying Starts to Make Sense
Cloud plans remove the server admin entirely, and Enterprise adds the SSO, role-based access, environment promotion, external secrets, and log streaming that regulated teams ask about in security reviews.
A rough rule: a solo operator or a small team comfortable with Docker should stay on the Community Edition for years. The moment you have compliance requirements, multiple teams editing shared workflows, or nobody who wants to be on call for a Redis container, the subscription is cheaper than the alternative.
Getting More Out of the Free Tier
A few habits pay off immediately. Start from the official template library instead of a blank canvas, since most common patterns already exist. Build one good error workflow and attach it globally, so failures land in a channel you actually watch. Use sub-workflows for repeated logic rather than copy-pasting the same eight nodes into twelve places. Set the instance timezone deliberately, because schedule triggers firing in UTC while you think in local time is a classic silent bug.
Pin your Docker image tag instead of running latest, and keep a second throwaway instance for testing upgrades. Then lean on the /healthz endpoint with an uptime monitor, so you learn about a dead container from an alert rather than from a colleague asking why the invoices didn’t go out. None of this costs a cent, and collectively it’s the difference between a hobby instance and infrastructure you can trust.