ERPNext Self-Hosting Requirements: Sizing, Real Costs, and When Frappe Cloud Wins

At a glance

ERPNext hardware is cheap and easy to size, but the real self-hosting decision is about operations, not servers. This guide gives sourced sizing tiers by user count, an honest VPS vs Frappe Cloud cost comparison that prices in labor, and a clear-eyed look at the recurring ops burden. It closes with when self-hosting wins and when managed Frappe Cloud is the lower total cost.

What Are the Minimum Server Requirements for ERPNext?

For production, start at 2 vCPU and 4 GB RAM with 40 GB SSD — enough for roughly 10–15 active users. ERPNext technically runs on 2 GB RAM, but that's for testing only. Ubuntu LTS, MariaDB, Redis, and Python per the official install guide; add 1–2 GB swap regardless of RAM.

The 2 GB floor comes from community guidance on the Frappe forum, and it's genuinely a floor: at 2 GB you're one large report or stock reposting job away from the OOM killer taking down your site. Swap is cheap insurance either way. For anything holding real company books, 4 GB is where production starts.

Sizing Table: Users → CPU / RAM / Storage

Here's our implementation guidance, anchored to sourced community data points and extended from what we see in deployments:

Test/eval tier (1–5 active users): 1–2 vCPU, 2–4 GB RAM, 25 GB storage, indicative VPS cost $6–12/mo.

Small production tier (5–15 active users): 2 vCPU, 4 GB RAM, 40–60 GB SSD, indicative VPS cost $20–30/mo.

Growing team tier (15–50 active users): 4 vCPU, 8–16 GB RAM, 80–160 GB SSD, indicative VPS cost $40–80/mo.

Heavy / multi-company tier (50–150 active users): 8+ vCPU, 16–32 GB RAM, 240 GB+ NVMe, indicative VPS cost $100–250/mo.

Two honesty notes on the table. The lower tiers are well-anchored: a documented real-world deployment ran ERPNext v12 on a 1 vCPU / 2 GB DigitalOcean droplet with six concurrent users and no noticeable slowness, and hosting-provider guidance converges on 4 GB minimum for 5–15 users with CPU/RAM steps above that. The upper tiers are our partner extrapolation from those anchors plus implementation experience — treat them as planning guidance, not official Frappe numbers. VPS prices are indicative of current Hetzner/DigitalOcean ranges and drift over time.

What actually drives sizing

It's not named users — it's concurrent users, and even more than that, it's what they're doing. The things that move the needle: heavy background jobs (stock reposting after backdated entries, large report generation), attachment volume (scanned invoices and drawings eat disk, not CPU), and the number of sites running on one bench. A 40-person company where ten people use ERPNext at a time sizes smaller than a 20-person company running constant stock transactions across three companies on one bench. Monthly batch workloads — statement imports and reconciliation runs in the v16 banking workflow, say — barely register next to those background jobs.

Workers and tuning, briefly

The defaults are sane; the three dials that matter when you grow are gunicorn workers (rule of thumb: roughly 2×cores+1), MariaDB's innodb_buffer_pool_size (give it a healthy share of RAM so the working set lives in memory), and Redis (rarely the bottleneck at SMB scale). Don't pre-tune — measure, then tune.

How far does one server go?

Far. Community and hosting-provider guidance is consistent: scale vertically for a long time — up to the ~64 vCPU / 128 GB class of machine — before even thinking about horizontal architecture. Most SMBs never leave one server, and that's the correct outcome, not a limitation.

One sizing habit worth stealing from our implementations: start one tier smaller than you think you need, with a provider that resizes in minutes. Cloud VPSes scale up with a reboot; the $40 you might waste on premature capacity buys nothing, while the measurement you get from running real workloads for a month tells you exactly which tier you belong in. The exception is storage — size that generously up front, because attachments only grow and disk resizes are the one migration that's actually annoying.

How Many Users Can ERPNext Handle?

Far more than most SMBs need. Community deployments report smooth performance with modest hardware — e.g., six concurrent users on a 1 vCPU/2 GB droplet — and vertical scaling carries ERPNext to hundreds of users on a single large server. For a 10–200 person US company, capacity is not the constraint.

If you're comparing against a NetSuite quote, notice what's missing from this entire discussion: per-user licensing. On ERPNext the marginal cost of user #51 is zero license dollars and a rounding error of RAM. That changes who gets a login — shop floor, warehouse, part-timers — which changes how much of your operation actually lives in the ERP. (The full cost comparison is in our NetSuite comparison.)

The Real Cost Table: Self-Hosted VPS vs Frappe Cloud

The VPS line items — including the one everyone omits

• Server: $20–80/mo for the realistic production tiers
• Backup storage (off-site, e.g. S3/B2): ~$5/mo
• Monitoring/alerts: free–$20/mo
• Your (or your admin's) time: realistically 2–6 hours/month steady-state, more in upgrade months. This is the line item every "host ERPNext for $24/month" post omits, and it's the biggest number on the list.

Frappe Cloud's published pricing

As of publication, Frappe Cloud's pricing starts shared site plans at $5/mo (USD), tiered up through roughly $10/$25/$38/$50 by compute/CPU-time, with private benches from $25/mo per site and dedicated servers above that (shared hosting details; Frappe's own ERPNext hosting page starts at $5/mo). These are Frappe's prices, not ours — they can change, so check the pricing page rather than trusting any blog post's snapshot, including this one.

The honest math

At US sysadmin rates — $75–150/hour even for fractional or contracted help — 3 hours a month of ERP operations is $225–450/month of labor on top of your $24 VPS. Against that, a Frappe Cloud plan at $25–50/month that includes push-button updates, managed backups, and platform monitoring is usually the cheaper total cost for a firm with no existing ops staff. That's the sentence self-hosting enthusiasts skip, so we won't: hardware is cheap; operations are the cost.

Self-hosting wins the math when at least one of these is true: you have existing sysadmin capacity with idle hours (the labor is already paid for), you have data-residency or VPN/network constraints that rule out shared platforms, you run heavy custom apps that need server-level control, or you operate many sites that amortize one admin across all of them.

The Ops Burden, Honestly

If you self-host, this is the recurring job you're signing up for:

• Updates. Minor stable-branch updates monthly; major version upgrades once or twice a year. Community best practice for major upgrades is staging first — and often a fresh server with a restore rather than an in-place leap. Security releases don't wait for your schedule; see our security hardening checklist for why upgrade discipline is the control that actually matters.
• Backups. bench backup --with-files (reference) on an automated schedule, copied off-server, with periodic restore tests. A backup you've never restored is a hope, not a backup.
• Everything else. TLS certificate renewal, disk housekeeping, log rotation, failed-login review, uptime alerts — and incident response when the disk fills at 2 a.m. during month-end close. None of it is hard; all of it is someone's job, every month, forever.
• Docker vs bare-metal bench. frappe_docker is the officially maintained container path and genuinely simplifies upgrades and reproducibility — at the price of a Docker learning curve. Either way, note what Docker doesn't change: the ops burden is operational (updates, backups, monitoring), not installation-time. Containerizing the install doesn't containerize the responsibility.

When Frappe Cloud Wins (and When It Doesn't)

Frappe Cloud wins when: you have no ops staff and don't want to hire for it; you want push-button updates and managed backups; your customers send compliance questionnaires and you'd rather inherit platform answers than write your own; and your honest all-in hosting budget is under $100/month.

Self-hosting wins when: you have strict data-residency requirements; you need deep server-level customization or unusual apps; you operate in an air-gapped or VPN-only environment; or you already have a DevOps team with capacity to spare.

Our position is the same one we laid out in the full hosting decision post, of which this is the sizing companion: we implement on both, and the hosting choice is an ops question, not a loyalty test. What we'll argue against is the third option nobody chooses on purpose — the unmanaged self-hosted instance that nobody patches. That's not a hosting strategy; it's a deferred incident.

Bottom line

Sizing ERPNext is the easy part: start at 2 vCPU / 4 GB for production, scale vertically as you grow, and one server carries you further than almost any SMB needs. Costing it honestly means pricing the labor, not just the VPS — and at US rates, the labor is the decision. If you'd rather skip the sizing debate entirely: our fixed-price implementations from $4,000 include the hosting architecture decision — sized to your users, your constraints, and your actual ops capacity, on Frappe Cloud or your own servers. See pricing → Or grab our ERPNext Sizing & TCO worksheet (users → tier → VPS vs Frappe Cloud vs managed, on one page) via a free ERP audit.