Self-Hosting n8n in Production: Real Server Specs and Cost Numbers

Self-hosting n8n in production looks simple on paper compared to paying $20 to $50 per month for n8n Cloud, until you realize that "docker-compose up" is about 10% of the actual work. Most guides stop at initial deployment. The real questions about self hosting n8n production environments (how much RAM, what database, what breaks at 3 AM) go unanswered because the people writing those guides haven't run n8n under real workflow load for months at a time.

We have. Rain Automation runs 80 active workflows on a self-hosted n8n instance that has logged 10,038 executions with a 99.94% success rate, on a server that costs $0 per month in compute. Here's everything the other guides leave out.

What "Production-Ready" Actually Means for n8n

A production-ready n8n deployment requires four things most setup guides skip entirely: queue mode with a dedicated worker process, PostgreSQL instead of SQLite, filesystem-based binary data storage, and monitoring with calibrated alert thresholds. Without all four, you're running a dev setup that will break under real workflow volume.

Here's the thing. The official n8n deployment docs cover Docker, Kubernetes, and npm installation methods. They're well-maintained and accurate for getting n8n running. But they stop at "running." They don't cover what happens when you have 80 workflows firing on schedules, webhooks, and triggers throughout the day.

The gap between "works on my laptop" and "runs in production" comes down to four architectural decisions:

• Queue mode vs. main-only: In the default single-process mode, n8n handles both the UI/webhook server and workflow execution on the same thread. When a heavy workflow runs, the UI slows down. Queue mode separates these concerns: the main process handles webhooks and the editor UI, while a dedicated worker process (backed by Redis) executes workflows independently. This is mandatory once you're past a few dozen active workflows.
• PostgreSQL vs. SQLite: SQLite works fine for testing. It does not work fine when a queue-mode worker and the main process both need concurrent database access. We learned this the hard way (more on that in the database section below).
• Filesystem binary data vs. database-stored: n8n can store images, PDFs, and webhook payloads either inside the database or on the filesystem. Storing them in the database is the default, and it will silently bloat your DB until backups take forever and queries slow down.
• Monitoring vs. hoping: If you're running n8n as a business-critical tool, you need to know when it's unhealthy before your workflows stop working. Not after.

Disclosure: The n8n link above is an affiliate link. Rain Automation may earn a commission if you sign up through it. This does not affect our recommendations or the technical content of this post.

If you're evaluating whether to self-host or use a managed platform, our n8n vs Zapier vs Make comparison covers the cost and reliability tradeoffs across 10,000+ workflow runs.

The Server You Actually Need (With Real Numbers)

Rain Automation runs its entire n8n production stack on a single Oracle Cloud Ampere A1 instance: 4 ARM64 vCPUs, 24 GB RAM, 27 GB swap, Ubuntu 22.04 (kernel 6.8.0-1054-oracle). This is an Oracle Always Free-eligible shape, making the compute cost $0 per month. Rain Automation's instance is grandfathered at the original 4 OCPU/24 GB allocation; new free-tier signups currently get 2 OCPU/12 GB after Oracle reduced the Always Free Ampere A1 limits in June 2026.

Community threads on the n8n forum regularly ask whether n8n can run on a 1 CPU / 1 GB RAM VPS. The short answer: it can start, but it won't stay up under real load. The consensus from production hosting discussions is that 4 GB RAM and 2 vCPUs is where production n8n actually starts working. But that's only for n8n itself. You also need room for Redis, your database, and monitoring.

Here's the actual memory budget from our production Docker Compose stack:

Container	Image	Memory Limit	CPU Limit
n8n main (webhooks + editor)	n8nio/n8n:2.32.5	4 GB	2.0 vCPU
n8n worker (execution)	n8nio/n8n:2.32.5	4 GB	2.0 vCPU
Redis (Bull queue)	redis:7.4-alpine	512 MB	N/A
Prometheus (metrics)	prom/prometheus:v3.13.1	1 GB	N/A
Grafana (dashboards)	grafana/grafana:13.1.1	512 MB	N/A
Alertmanager (alerts)	prom/alertmanager:v0.33.1	256 MB	N/A
node-exporter (host metrics)	prom/node-exporter:v1.9.0	128 MB	N/A
blackbox-exporter (uptime probes)	prom/blackbox-exporter:v0.25.0	128 MB	N/A

Total committed limits: ~9.2 GB across 7 containers. The 24 GB host runs at approximately 12 GB used, leaving about 10 GB available. That headroom matters because n8n's Node.js heap will creep upward throughout the day (a documented pattern in GitHub issue #26622), and you want the OS to have room to absorb spikes without hitting swap.

And yes, ARM64 works. n8n publishes multi-architecture Docker images, so the Ampere A1's ARM64 processors run the same container images as x86. No special builds required.

In my experience running this stack for several months, the 4 GB per-container limit for n8n is the sweet spot. Going lower (2 GB) causes OOM kills during workflows that process large payloads. Going higher wastes memory that other containers could use. If you're building your own n8n CRM integration workflows, expect memory usage to spike when processing batches of lead records.

Your Database Choice Will Define Your Scaling Ceiling

n8n defaults to SQLite for storage, and that default will cost you. Our SQLite database ballooned to 4.7 GB before we migrated to PostgreSQL in May 2026. After the migration (and switching binary data to filesystem mode), the Postgres database sits at 184 MB: a 26x size reduction.

SQLite also cannot handle concurrent access from queue-mode workers, making PostgreSQL mandatory for any production deployment.

This is the story nobody in the SERP tells because they haven't lived through it.

When we first deployed n8n, we used the default SQLite backend. It worked fine for the first few months. Then the database file started growing. And growing. By May 2026, database.sqlite was 4.7 GB.

The root cause: n8n was storing binary workflow payloads (images, PDFs, webhook bodies) directly inside the SQLite database. Every workflow that processed an attachment, received a webhook with a JSON body, or generated an image was writing that payload into SQLite rows. The data was transient (execution data gets pruned), but the SQLite file doesn't shrink when rows are deleted. It just keeps the allocated space.

So we migrated. On May 23, 2026, we moved n8n from SQLite to PostgreSQL 17.4 and simultaneously switched binary data mode to filesystem storage. The result:

• Before: SQLite at 4.7 GB, slow queries on the execution history page, backup archives over 1 GB compressed
• After: PostgreSQL at 184 MB, fast queries, backup archives at 25 MB compressed

The migration itself was straightforward using n8n's built-in export/import tools. The harder part was configuring binary data mode correctly. You set N8N_DEFAULT_BINARY_DATA_MODE=filesystem in your environment, and n8n writes binary payloads to a local directory instead of the database. Those files get pruned alongside execution data, and they don't bloat your database backups.

Our current pruning configuration keeps executions for a maximum of 720 hours (30 days) or 10,000 records, whichever limit hits first. As of July 29, 2026, the database holds 10,038 execution records across 80 active workflows. Of those, 10,032 completed successfully and 6 failed, giving us a 99.94% success rate. The oldest execution in the current database dates to July 11, 2026.

If you're comparing automation platforms, this kind of database sizing data matters. Our n8n vs Make comparison covers the broader feature and cost differences.

The Full Docker Compose Stack (Not Just n8n)

A production n8n deployment needs seven containers minimum: n8n main, n8n worker, Redis for queue management, and four monitoring containers (Prometheus, Grafana, Alertmanager, and node-exporter). Pin every image tag to a specific version. Using "latest" caused silent breaking changes in our stack before we enforced pinning.

Here are the exact pinned versions running in Rain Automation's production stack as of July 2026:

• n8n: n8nio/n8n:2.32.5 (both main and worker containers)
• Redis: redis:7.4-alpine
• Prometheus: prom/prometheus:v3.13.1
• Grafana: grafana/grafana:13.1.1
• Alertmanager: prom/alertmanager:v0.33.1
• node-exporter: prom/node-exporter:v1.9.0
• blackbox-exporter: prom/blackbox-exporter:v0.25.0

Why pin versions? Because we learned the hard way. Before pinning, Docker would pull whatever "latest" pointed to on restart. Twice, an n8n minor version bump changed node behavior in ways that broke existing workflows. One time, a Prometheus update changed its config format. Pinning means you upgrade deliberately, test, and then update the tag. Not accidentally at 3 AM when a container restarts.

The worker container runs with --concurrency=5, which means it can process up to 5 workflow executions simultaneously. For I/O-heavy workflows (API calls, email sends, database queries), concurrency of 5 keeps throughput high without overwhelming the host. CPU-heavy workflows (image processing, large data transforms) might need lower concurrency or a beefier server.

n8n's queue mode documentation covers the basics of worker configuration. What it doesn't cover is how to size concurrency for your workload. Start at 5, monitor your queue backlog metric, and adjust from there.

For anyone building automated lead enrichment workflows or multi-step CRM pipelines, queue mode is what keeps the UI responsive while heavy workflows process in the background.

What Breaks in Production (And How to Know Before It's Too Late)

Production n8n fails in predictable ways: Node.js heap memory creeps until OOM, event loop lag spikes during heavy workflows, queue backlogs grow when workers can't keep up, and unmonitored process restarts silently drop in-flight executions. Prometheus with calibrated alert thresholds catches all of these before they become outages.

This is the section that no other self-hosting guide publishes, because it requires actually running n8n in production long enough to observe failure patterns and calibrate thresholds against real behavior.

Here are Rain Automation's 9 production Prometheus alert rules with the exact thresholds we've calibrated:

Alert Rule	Threshold	Fires After	What It Catches
n8nDown	Target unreachable	1 minute	Complete process crash or network failure
HighHeapUsage	>1.6 GB of 2 GB max heap	5 minutes	Memory creep trending toward OOM kill
EventLoopLagHigh	p99 >500ms	5 minutes	Heavy workflow blocking the event loop
HighCPU	>80% sustained	5 minutes	CPU-bound workflow or runaway process
FileDescriptorsHigh	>80% of OS limit	5 minutes	Too many open connections or file handles
ProcessRestarted	>2 restarts in 15 minutes	Immediate	Crash loop (OOM, config error, or bad workflow)
QueueBacklog	>50 waiting jobs	5 minutes	Workers can't keep up with incoming executions
QueueJobsFailing	>0.1 failures/second	5 minutes	Systematic workflow errors (bad credentials, API changes)
PrometheusTargetDown	Scrape target missing	3 minutes	Monitoring itself is broken

Prometheus scrapes n8n metrics every 15 seconds and retains 90 days of data with a 5 GB storage cap. Alerts route through Alertmanager to email.

The HighHeapUsage threshold deserves explanation. n8n's Node.js process has a maximum heap size of 2,048 MB (configurable via NODE_OPTIONS=--max-old-space-size=2048). But you don't want to alert at 2 GB, because by then the process is already in trouble. We alert at 1.6 GB (80% of max) sustained for 5 minutes. That gives us time to investigate before the garbage collector starts thrashing.

I had a scenario last year where a workflow processing large webhook payloads caused heap usage to climb from 800 MB to 1.8 GB over about 6 hours. Without the HighHeapUsage alert, we wouldn't have caught it until the process crashed and restarted, dropping whatever execution was in flight at that moment. With the alert, we identified the problematic workflow, added pagination to its payload processing, and heap usage dropped back to normal.

The n8n memory errors documentation covers the general concept but doesn't give you specific thresholds. That's because thresholds depend on your workload. Ours work for 80 workflows doing a mix of CRM automation, email workflows, and webhook processing. For anyone building email sends into a self-hosted n8n stack, how we configure SMTP for those email workflows in production covers the relay setup and provider choices behind these numbers.

A Backup Strategy That Won't Fail You at 2 AM

Rain Automation's n8n backup runs daily at 2:00 AM ET via cron: the n8n config directory and encryption key are archived, integrity-verified with tar, and replicated to Backblaze B2 with 14-day offsite retention. A separate pg_dumpall at 2:15 AM ET backs up the PostgreSQL database. Current compressed backup size: 25 MB.

Nine consecutive daily backups confirmed on disk as of July 29, 2026.

Most n8n backup guides say "just copy the .n8n directory." That's incomplete. Here's what our backup actually includes and excludes:

Included in backup:

• .n8n/ config directory (workflow definitions, credentials encrypted at rest, settings)
• ~/n8n/.env (contains the encryption key, without which credential data is useless)

Explicitly excluded:

• database.sqlite (legacy file, no longer in use after Postgres migration)
• binaryData/ (transient workflow attachments, regenerated by re-running workflows)
• n8nEventLog*.log (diagnostic logs, not needed for recovery)

The backup script runs tar -czf to create a compressed archive, then immediately runs tar -tzf on the resulting file to verify integrity. If the integrity check fails, the corrupt archive is deleted and an alert fires. This matters because a silently corrupt backup is worse than no backup at all.

Local retention is 7 days. Offsite replication to Backblaze B2 keeps 14 days. The database backup runs separately via pg_dumpall at 2:15 AM ET (15 minutes after the config backup, to avoid I/O contention).

At 25 MB compressed, the backup is small enough that storage costs are negligible. B2 pricing is $0.006 per GB per month for storage, so 14 days of 25 MB backups costs less than a penny per month.

If you're running automated deal pipeline workflows or any business-critical automation, test your restore process before you need it. We do a restore test quarterly.

What Does Self-Hosting n8n Actually Cost?

Rain Automation's actual monthly infrastructure cost for self-hosted n8n in production: $0 compute (Oracle Cloud Always Free tier), approximately $0.50 for Backblaze B2 backup storage, and $0 for monitoring (self-hosted Prometheus and Grafana). Total: under $5 per month including all ancillary costs. Articles from competing SaaS vendors citing $1,150 to $2,000 per month for self-hosting are padding their estimates with $500 to $1,000 in "DevOps maintenance" at consulting rates.

Let's break this down honestly.

Infrastructure costs (what you pay a cloud provider):

Line Item	Rain Automation's Cost	Notes
Compute (server)	$0/month	Oracle Cloud Always Free: 4 OCPU, 24 GB RAM Ampere A1 (grandfathered; new accounts get 2 OCPU/12 GB as of June 2026)
Object storage (backups)	~$0.50/month	Backblaze B2 at $0.006/GB/month
Monitoring	$0/month	Self-hosted Prometheus + Grafana
Domain/SSL	$0/month	Let's Encrypt (free), domain already owned
Total infrastructure	~$0.50/month

Now, if you can't get Oracle's Always Free tier (availability varies by region), a comparable Ampere A1 instance (4 vCPU, 24 GB RAM) runs about $40 to $80 per month on other cloud providers. Even at $80 per month, that's a fraction of what competitor articles claim.

The "DevOps cost" myth:

An article from Latenode (a competing automation platform) estimates self-hosting costs at "$1,150 to $2,000 per month." Their breakdown includes $500 to $1,000 per month for "DevOps maintenance and monitoring" calculated at consulting rates. This is like saying cooking dinner costs $200 because a private chef charges $200.

Here's what n8n maintenance actually involves once your stack is set up:

• Weekly: Check Grafana dashboards (5 minutes), review any alert history (5 minutes)
• Monthly: Evaluate n8n version updates, test in a staging environment, update pinned image tags (1 to 2 hours)
• Quarterly: Test backup restore procedure (30 minutes), review and adjust alert thresholds (30 minutes)

That's roughly 3 to 4 hours per month of actual maintenance. If you value your time at $100 per hour, that's $300 to $400, not $1,000. And most of that time is optional optimization, not keeping-the-lights-on work.

For context on how these costs compare to other automation platforms, our n8n vs Zapier vs Make cost comparison breaks down the per-execution economics at various workflow volumes.

Self-Hosted vs n8n Cloud vs Make.com: Decision Framework

Self-hosted n8n wins on cost at scale and data control. n8n Cloud wins when you want zero infrastructure management. Make.com wins for simple, low-volume workflows where you don't want to think about servers at all.

The right choice depends on your execution volume, technical comfort, and data sovereignty requirements.

Dimension	Self-Hosted n8n	n8n Cloud	Make.com
Cost at 10,000 executions/month	$0 to $80 (server only)	$20 to $50/month	$50 to $200/month (operation-based pricing)
Setup time	4 to 8 hours (first time)	10 minutes	5 minutes
Ongoing maintenance	3 to 4 hours/month	Zero	Zero
Data location	Your server, your jurisdiction	n8n's cloud (EU/US)	Make's cloud
Workflow complexity ceiling	Unlimited (custom nodes, code nodes)	Same as self-hosted	Limited by platform constraints
Monitoring/observability	Full Prometheus/Grafana	Basic dashboard	Basic dashboard
Backup control	Full (you define schedule, retention, offsite)	Managed by n8n	Managed by Make
Queue mode / workers	Full control over concurrency	Managed scaling	N/A (different architecture)

Choose self-hosted if:

• You run more than 1,000 executions per month and want to minimize per-execution costs
• Data sovereignty matters (healthcare, finance, government contracts)
• You need custom monitoring and alerting
• You're comfortable with Docker and basic Linux administration

Choose n8n Cloud if:

• You want n8n's workflow builder without managing infrastructure
• Your execution volume is under 5,000 per month
• You don't have someone on the team who can SSH into a server

Choose Make.com if:

• Your workflows are simple (under 10 steps)
• You prefer visual-only building without any code
• Volume is low enough that per-operation pricing stays reasonable

Disclosure: Links to n8n above are affiliate links. Rain Automation may earn a commission if you sign up. This does not affect our analysis.

If you want a deeper comparison between n8n and Make specifically, including reliability data, see our n8n vs Make for small business automation breakdown.

How to Automate Your Own Business Workflows

Once your self-hosted n8n instance is running, the real value is in what you build on it. Rain Automation uses n8n as the backbone for CRM automation, lead enrichment pipelines, and deal pipeline stage alerts.

If you're looking at building similar workflows for your business, whether that's automating your sales pipeline or connecting your CRM to email and messaging platforms, the infrastructure described in this post is what makes those automations reliable enough to trust with real business processes.

We build and maintain automation systems like this for clients across industries. If you want help setting up a production n8n stack, building custom workflows, or designing a CRM that fits your actual process, we'd be glad to talk.

Get in Touch to discuss your automation needs.

Frequently Asked Questions

How much RAM does n8n need for production?

For a production n8n deployment in queue mode, plan for 4 GB per n8n container (main and worker), plus memory for Redis (512 MB), your database, and monitoring tools. Rain Automation's full stack commits 9.2 GB across 7 containers on a 24 GB host. A bare minimum for production is 8 GB, but 16 GB or more gives you the headroom to avoid OOM crashes during peak usage.

Is n8n self-hosting free?

The n8n Community Edition is free to self-host with no license fees. Your costs are the server infrastructure. Rain Automation runs its production instance on Oracle Cloud's Always Free tier at $0 per month compute cost. If you use a paid cloud provider, expect $40 to $80 per month for a server with enough resources for production workloads.

What database does n8n use in production?

n8n defaults to SQLite but should use PostgreSQL for any production deployment. SQLite cannot handle concurrent access from queue-mode workers and will bloat if binary data is stored in the database. Rain Automation migrated from a 4.7 GB SQLite database to PostgreSQL at 184 MB by switching binary data to filesystem mode.

How do I set up n8n queue mode with Redis?

Queue mode requires three components: the n8n main process (handles webhooks and the editor), a Redis instance (manages the Bull job queue), and one or more n8n worker processes. Set EXECUTIONS_MODE=queue in your environment, point QUEUE_BULL_REDIS_HOST to your Redis instance, and start the worker with the worker command and a concurrency flag. See n8n's queue mode docs for the full configuration.

What are the server requirements for n8n in 2026?

As of July 2026, a production n8n deployment needs at minimum 4 GB RAM, 2 vCPUs, and 20 GB disk space. For queue mode with monitoring (the recommended production setup), plan for 16 to 24 GB RAM, 4 vCPUs, and 50 GB disk. ARM64 processors (like Oracle's Ampere A1 or AWS Graviton) work with n8n's multi-architecture Docker images at no performance penalty.

How do I back up a self-hosted n8n instance?

Back up the .n8n/ config directory (contains encrypted credentials and workflow definitions) and your encryption key (usually in your .env file). If you use PostgreSQL, run pg_dumpall separately. Exclude the binaryData/ directory and legacy SQLite files. Verify backup integrity with tar -tzf after each archive. Replicate to offsite storage for disaster recovery.

This post contains affiliate links to n8n. Rain Automation may receive compensation for referrals. All technical data, server specifications, and cost figures in this post are from Rain Automation's actual production deployment as measured on July 29, 2026.