n8n Self-Hosted Limitations Nobody Tells You About (and the Fixes)

The n8n self-hosted limitations that matter are these: the default database is SQLite, one process runs everything with no concurrency cap, files are held in memory, execution history is pruned after 14 days, and the free Community Edition has no SSO, sharing, projects, Git version control or external storage. The first five have a free fix, usually one environment variable. The rest only go away with a paid license or n8n Cloud, and updates, backups and security patches become your job either way.

Every limit here is taken from n8n's own documentation, checked on 11 October 2026: the edition comparison, database, Docker Compose, concurrency, queue mode, binary data, execution data, update, backup and task runner pages, the 3.0 breaking-changes page, n8n's security advisories and the pricing page. It is a documentation-based list, not a benchmark, and the settings below were checked against the docs rather than executed. The newest stable release that day was 2.42.6.

Self-hosting is still the right call for plenty of people. The Community Edition has no license fee and no execution cap, and n8n says it includes "almost the complete feature set". The gap is what the install tutorials leave out. This page is that list, with a verdict on each item: fix it for free, pay to remove it, or accept that Cloud is the cheaper answer. If you have not decided where to run n8n yet, our n8n Cloud vs self-hosted guide makes that call first, and the n8n hub collects everything else we publish on the tool.

n8n self-hosted limitations: the checklist

The same ten, with what the docs say, the fix and the verdict:

n8n self hosted problems you can fix for free

Five of the ten are defaults, not restrictions. They catch people because the quick-start path leaves every one of them switched to the convenient setting.

1. SQLite is the default database

The one-line installer and the stock Docker image both start on SQLite, a single file inside the .n8n folder. n8n's Docker Compose guide calls it "fine for trying things out" and says to use Postgres for "a production instance that must handle more than a handful of users or workflows running around the clock". The catch is in the same guide: "Existing SQLite data doesn't carry over automatically." Move later and you rebuild or re-import. SQLite also keeps the disk space of pruned executions unless you vacuum the file. Fix: start on Postgres 16, 17 or 18. Our n8n Docker Compose setup guide has the full file.

2. One process, no concurrency cap

In regular mode a single n8n process serves the editor, receives webhooks and runs every execution. The concurrency page says n8n "doesn't limit how many production executions may run at the same time", and that too many can "thrash the event loop, causing performance degradation and unresponsiveness". In plain terms: a burst of webhooks can freeze the editor. Fix: set N8N_CONCURRENCY_PRODUCTION_LIMIT, and runs over the limit wait in a first-in, first-out queue. When that is not enough, queue mode adds Redis and worker processes, each running 10 jobs at once by default. Queue mode is included in the free edition, though n8n does not recommend running it on SQLite.

3. Files are held in memory

"When handling binary data, n8n keeps the data in memory by default. This can cause crashes when working with large files." That sentence from the binary data page explains most out-of-memory restarts on small servers. Fix: set N8N_DEFAULT_BINARY_DATA_MODE=filesystem. In queue mode use database instead, because filesystem storage is not supported there; database mode caps a single file at 512 MiB by default. n8n 3.0 removes the in-memory mode altogether.

4. Execution history disappears after 14 days

Pruning is on by default. n8n deletes finished executions older than 336 hours, and the oldest ones once the total passes 10,000. If a client asks what a workflow did three weeks ago, the answer is gone. Fix: raise EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT if you need a longer trail, and watch the disk, because the same page warns the database "can grow in size and run out of storage". On a small disk, do the opposite and save only failed runs.

5. Webhooks and sign-in need setup Cloud does for you

n8n builds webhook URLs from its protocol, host and port, so behind a reverse proxy they show the internal port 5678. Set N8N_WEBHOOK_URL and N8N_PROXY_HOPS=1; the older WEBHOOK_URL name is deprecated from 2.35.0. The other surprise is Google: the "Sign in with Google" button is managed OAuth2, which is Cloud-only. Self-hosted, you create your own app in the Google Cloud Console and paste in a client ID and secret. Free, but allow an hour the first time.

# n8n service environment (compose.yaml)
- DB_TYPE=postgresdb                        # 1. Postgres, plus the DB_POSTGRESDB_* settings
- N8N_CONCURRENCY_PRODUCTION_LIMIT=20       # 2. queue production runs beyond 20 at once
- N8N_DEFAULT_BINARY_DATA_MODE=filesystem   # 3. files on disk (use "database" in queue mode)
- EXECUTIONS_DATA_MAX_AGE=168               # 4. keep 7 days of history instead of 14
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000     # 4. and up to 50,000 runs instead of 10,000
- N8N_WEBHOOK_URL=https://n8n.example.com/  # 5. public URL behind the reverse proxy
- N8N_PROXY_HOPS=1                          # 5. one proxy in front of n8n

Those lines are the documented variable names with the example values from n8n's docs. Treat the numbers as starting points, not recommendations for your workload.

n8n self-hosting downsides you can only pay your way out of

The next four are not defaults. They are features the free edition does not contain, and no environment variable turns them on.

The one that changes the decision for teams is sharing. The edition comparison is blunt: "Only the instance owner and the user who creates them can access workflows and credentials." Three people maintaining the same client workflows each see only their own. Checked October 2026, the Business license that adds sharing, SSO, Git and environments is €667 a month billed annually, on top of your server. Cloud Starter and Pro include shared projects for a fraction of that, which is why small teams that could self-host often do not. Our n8n team plans guide has the tier detail.

Two of the gaps have honest workarounds. For version control, the n8n CLI exports one JSON file per workflow that you can commit yourself; our n8n version control guide shows the routine. For storage, database mode replaces S3 until single files pass its size cap. SSO and multi-main have no workaround: use two-factor authentication, and accept that one main instance means minutes of downtime when it restarts.

The limits that are simply your job now

• Updates. n8n's advice is "Try to update at least once a month" after checking the release notes. The pace is quick: four stable 2.42 patches shipped between 5 and 9 October 2026. Major versions break things on purpose. The 3.0 page ends support for npm installs, removes older nodes such as Function, Item Lists and Cron, renames the binary data folder, switches unverified community nodes off by default and cuts the Code node task timeout from 300 seconds to 60. On 11 October 2026 the newest stable release on GitHub was still 2.42.6, so there is time to run Settings > Migration Report first; our n8n 3.0 upgrade guide covers the rest.
• Backups. Nothing backs up a self-hosted instance unless you schedule it. A complete backup is the .n8n folder plus the Postgres database. The CLI export commands alone miss users, execution history, variables and instance settings.
• Security patches. n8n publishes advisories on GitHub in batches. The batch of 30 September 2026 held 14, ten of them rated high, including a SQL injection in the Microsoft SQL node (GHSA-5qpp-pqww-h7fp) fixed in 2.42.1 and 2.41.4. On Cloud, n8n handles updates. On your server, you are exposed until you pull the fixed version.
• Code isolation. The task runner page says runners are "the only isolation layer between user-provided code and n8n" and to use external mode in production. That is an extra container per n8n process, which the quick-start setups do not include.
• Noticing failures. No one emails you when a workflow dies at 3 a.m. Set an error workflow on day one; our n8n error handling guide has an import-ready alert.

Fix it, pay for it, or move to Cloud?

For a solo builder who is comfortable on a Linux server, every limit that matters is on the free list, and an afternoon of setup removes them. What that server costs is in our self-hosted n8n pricing breakdown. For a team, the paid list is the real comparison, and it usually favours Cloud until volume is high.

One more test is worth running. If you are self-hosting because the workflows are turning into something customers pay for, the limits above are a hint that a workflow tool is carrying a product. The AI SaaS Builder program has no n8n lessons; it covers building that product as an app, with Supabase for data and sign-in, the Claude API for the AI step, deployment on Vercel and Stripe for billing.

n8n self-hosted limitations: FAQ