ERPNext server sizing: CPU, RAM and disk

ERPNext server sizing starts with users, data and peak work

Sizing ERPNext follows four things: concurrent users, data volume, scheduled and background jobs, and database load. The Frappe documentation and the frappe_docker repository split these into separate services (web workers, background workers, the scheduler, Redis, Socket.io and MariaDB), so each one needs its own estimate rather than a single server figure. Before buying hardware or cloud capacity, write down how many people will work in the system at the same time, which jobs run on schedules, and which reports run at month end.

A careful sizing exercise matters most at a new go-live with a large opening data load, in multi-company setups where one database serves several legal entities, where heavy reporting runs against large transaction tables, and where stock ledgers have grown over years of movements. Ask your team or partner to confirm the peak concurrent user count, the row counts for the largest DocTypes such as Stock Ledger Entry and General Ledger, and the timing of batch jobs. Those inputs drive the decisions in the rest of this page.

This page gives a method and a checklist, not fixed hardware numbers. No validated sizing figures were supplied for this page, so any CPU, RAM or IOPS target must come from a load test against your own data and workflows, or from written guidance from Frappe or your implementation partner. Treat measured peak load on a representative copy of your data as the only trustworthy basis for the numbers you commit to.

Sizing options by deployment shape

This table compares four ways to run ERPNext, from one server to a provider-managed Frappe Cloud plan, showing what your team sizes, what the provider sizes, and the signs that the current shape no longer fits. Read each row against your own data volume, user count and close calendar to decide when to move up a shape.

Deployment shape	Who sizes what	Sizing driver	When the shape stops fitting
Single server (bench or Easy Install)	Your team sizes CPU, RAM, disk and IOPS for web, workers, scheduler, Redis and MariaDB on one machine	Concurrent users, report size, background job volume and database working set	Database competes with workers for RAM and disk, or month-end runs slow interactive use
Split setup with separate database server	Your team sizes two or more machines and the network between them, including the database server's buffer pool and storage	Database working set, disk IOPS for writes, and backup window	Database storage needs outgrow one volume, or you need a replica for reporting or recovery
Kubernetes with external MariaDB and Redis	Your team sizes node pools, pod requests and limits, workers, and the managed or self-run database and Redis	Worker queue depth, storage class throughput for shared files, and database connections	Scaling workers no longer relieves latency, so the database or shared storage becomes the constraint
Frappe Cloud shared or dedicated servers	Frappe sets up and runs the servers within the plan you choose, and you choose the tier and site limits	Plan tier, number of sites, and whether you need dedicated resources	Your workload needs server-level settings or resources beyond the chosen tier, so confirm limits in writing

Which resource limits ERPNext first: CPU, RAM, disk and IOPS

ERPNext sizing rarely fails on one resource at a time. Web requests, background workers, file storage and database I/O compete for the same server, so the first bottleneck depends on which workload your users and jobs generate most. Knowing the symptom each resource produces makes it easier to measure the right thing before buying hardware.

CPU for web requests and reports

CPU is consumed by Gunicorn web workers handling page loads, list views, and API calls, and by long report generation and bulk document saves. The first symptom is usually slow page responses that grow during month-end runs, while the database itself looks idle. Before adding cores, measure CPU saturation per process during peak hours and identify which reports or scripts drive the spike, since one heavy report can starve interactive users.

RAM for workers, cache and the database

Memory is shared between the Redis cache and queue, the background worker processes, and the MariaDB InnoDB buffer pool, which holds hot tables and indexes. When memory runs short, the first symptom is often swapping, which makes both page loads and queue jobs slow in unpredictable ways. Measure resident memory per worker type, Redis memory use, and how much of the database working set stays cached before you decide how to split the budget.

Disk capacity for uploads, backups and logs

Capacity grows from attached files, the site backups created by bench, database dumps, and application and web server logs. Teams usually notice a full volume as failed uploads, failed backups, or a database that stops accepting writes. Measure growth per site per month, confirm where backups are written, and check whether logs rotate. Keep headroom for a restore, because restoring a backup needs free space beyond the current data.

IOPS for database reads and writes

IOPS is driven by the database engine reading index pages that miss the buffer pool, writing transaction logs on every commit, and flushing dirty pages during checkpoints. Ledger-heavy posting, stock reposting, and scheduler jobs that touch many rows raise write load sharply. The first symptom is often latency spikes during batch jobs rather than a steady slowdown. Measure storage latency and queue depth on the database volume during those jobs, and confirm with your storage provider what the disk class actually delivers.

Steps for ERPNext server sizing before you buy hardware

This sequence turns today's user count, data volume and workload pattern into measured CPU, memory and disk figures, so the hardware order rests on a staging test rather than a guess.

Inventory users, roles and peak working patterns
Start by listing every active user, grouped by ERPNext role, and the modules each role uses daily, such as selling, buying, stock, manufacturing and accounting. Ask the business owners when peaks happen, for example month-end close, shift starts or batch order runs, and whether those peaks overlap. Record how many people work in the system at the same time at peak, not just the total headcount. The output is a short table of concurrent users per role and per peak window. Check: if the team cannot name the peak windows, stop here and get them confirmed by the operations leads before moving on, because every later measurement depends on them.
Estimate record and attachment volume
Pull record counts from the current system for the core transactional and master data, including items, customers, suppliers, ledger entries, stock ledger entries, sales and purchase documents, and work orders where manufacturing applies. Add the size of attached files, scanned invoices and print archives separately, because they drive disk growth differently from database rows. Project growth from the last twelve months of activity and note which tables grow fastest. The output is a volume table with current counts, monthly growth and attachment totals. Check: if a figure comes from an estimate rather than a query on the live data, mark it as an estimate so the staging test can confirm or correct it.
Plan the data import in batches
Split the historical data load into batches, following the ERPNext Data Import documentation, which advises importing only a few thousand records at a time. Order the batches so masters such as items, customers and suppliers load before transactions that reference them. Time each batch in the staging environment and record how load time and database activity change as the dataset grows. The output is a batch plan with record counts and the observed load behavior for each batch. Check: if a batch causes sustained high database wait times or the import slows sharply as records accumulate, reduce batch size and rerun before continuing, since the import profile is an early sign of how the production database will behave.
Run a staging load test on the chosen version
Build a staging environment that matches the intended production topology, including a separate database server if that is the plan, and install the exact ERPNext and Frappe version you intend to run. Load the migrated or representative data, then drive realistic concurrent use with scripted scenarios for the roles identified in step one, including reports and month-end style runs. Use the same versions for every test so results are comparable. The output is a load test report with throughput, response times and error counts per scenario. Check: if the test produces errors or response times that breach the team's own acceptance targets, do not buy hardware yet. Investigate the bottleneck first, since a version or configuration change may solve it more cheaply than added capacity.
Measure CPU, memory, disk latency and database waits
During the peak scenarios, capture CPU utilization on the application and database hosts, memory use including how much memory the database keeps for its InnoDB buffer pool, disk latency and IOPS, and database wait events and slow queries. Compare buffer pool hit behavior against working set size, because frequent reads from disk under load usually point to memory or storage limits rather than CPU. Keep measurements for the full peak window, not a single sample. The output is a resource profile per host tied to each peak scenario. Check: if the database host is CPU-bound while disk and memory are idle, the fix is likely query or index work, not more storage. If disk latency or buffer pool misses dominate, the next step should size storage and memory first.
Choose vertical scaling or a replica
Decide whether the measured bottleneck is best addressed by a larger single server or by adding a read replica or a separate worker host. Vertical scaling suits a single database that is short on memory, CPU or IOPS at peak, while a replica suits heavy reporting that competes with transactional work. Confirm with the ERPNext and Frappe documentation and your database team how replication and failover are configured for the chosen version, since those details change the cost of each option. The output is a scaling decision with its reasoning, written against the measured profile. Check: if the team cannot explain which measured constraint each option removes, return to step five before buying anything.
Set headroom and a review date
Convert the measured peak load and the projected growth from step two into a target capacity with headroom that the business agrees to, covering disk growth over the period the budget owner plans for. Record the assumptions behind the figures, including user growth, attachment growth and the ERPNext version in use, so the reasoning can be checked later. Set a review date tied to the business events that change load, such as a new company, a new module or a version upgrade. Ask your hardware or cloud provider and your DeployOpen contact to confirm lead times and any licensing that affects the chosen sizes. The output is a signed-off capacity record with a review date. Check: if the headroom figure cannot be traced back to a measured value and a stated assumption, it is not ready for purchase.

When the database server needs its own sizing

The MariaDB server is usually the component that decides when ERPNext should move its database onto a host of its own. A single machine can run the web workers, background queues, scheduler, Redis and the database for a small company, but as data grows the database becomes the place where memory and disk pressure show up first. The InnoDB buffer pool is the main lever here. It caches table and index pages in memory, so whether it is adequate depends on the working set, meaning the portion of data and indexes that active users and reports touch regularly, rather than the total size of the database on disk.

Disk latency tends to appear in the user experience before anyone looks at a metrics dashboard. When the buffer pool cannot hold the working set, reads go to disk more often, and the symptoms are slow list views, reports that take longer each month and document saves that pause while the database commits. Check these against your own data: time a representative month-end report and a bulk save, then compare the slow query log and disk wait figures during those runs. Confirm the exact buffer pool size, the MariaDB version and every parameter value against the ERPNext and frappe_docker release you have chosen, and validate them with your own benchmarks, since defaults and supported combinations change between releases.

Once the business relies on the system, the database should not compete with web and worker processes for the same CPU and memory. Gunicorn workers, queue workers and the scheduler can each spike during imports, scheduled jobs or report runs, and those spikes evict database pages from memory and steal CPU from query execution. Moving MariaDB to its own host, with memory sized for the buffer pool and its own disk, gives you a clear point to scale. Plan that split before the slow reports arrive, and record which host each service runs on so the team can tell whether a slowdown comes from the application tier or the data tier.

Scale vertically or add a replica, by bottleneck

When web requests or background jobs queue up while the database and disk look healthy, the application tier is the constraint. Adding more CPU cores or more worker processes on the same host is usually the simplest fix, because the work is stateless and does not need data to be copied anywhere. Horizontal scaling of web and worker processes is a different question from adding a database replica, and it depends on how your deployment runs them.

Confirm the saturation point: Check whether CPU is pegged on gunicorn or worker processes, or whether requests wait on the database.
Scale the application tier first: A larger instance or more worker capacity often clears the queue with no change to data placement.
Separate long jobs: Moving heavy scheduled jobs to their own worker queue protects interactive users without adding a server.
Watch the scheduler: Long-running background jobs can block others, so resizing alone may not fix the symptom.
Trade-offs: More application nodes add deployment and session handling work, and they do not help if the database is the real limit.

Before you resize, confirm with your platform team which process counts and queue settings your release and deployment method use.

Security and operations that change with server size

Once the database moves to its own host and the data grows, the security and operations work changes with it. The cards below cover the controls that tend to be missed when sizing decisions are made, and what to confirm before the design is signed off.

Restrict database network access

When MariaDB runs on its own host, only the ERPNext application servers and the workers should reach port 3306. Bind the database to a private interface, allow the application subnets in the firewall, and disable remote root login. Confirm which hosts run bench workers and the scheduler, because each one needs a database path and each one must be listed in the access rules before the move.

Size backups to restore time

Backup storage should be sized for the full database, the public and private file directories, and the retention period you choose, not only for the current database size. Restore time matters as much as capacity, so run a timed restore onto a staging host at the sizing you expect. Ask your partner or internal team how long a full site restore takes at current volume and whether the figure has been measured.

Watch log and file growth

Attached files, generated reports, exported documents and application logs grow independently of transaction volume. Track the size of the sites directory, the log directory and the database binary logs on a schedule, and set alert thresholds well below full disk. Growth on the file side often surprises teams that only watch the database, so confirm each path has an owner and a cleanup rule.

Patch within the supported version line

Larger servers often run longer between maintenance windows, which makes patch discipline harder. Keep ERPNext and Frappe on a version that is still supported, and check the supported versions page before each sizing review. Plan minor release uptake into a staging environment first, and confirm who approves production changes and how long a rollback takes on the current hardware.

Keep staging close to production

A staging environment can only prove a sizing decision if it has comparable CPU, memory, disk type and data volume. Use an anonymized or masked copy of production data, and run the same worker counts and scheduled jobs. Confirm with your team which production load patterns, such as month-end reports or bulk imports, must be reproduced before staging results are trusted.

Control host and secret access

Database credentials, site configuration files and encryption keys sit alongside the sizing choices you make. Limit SSH access to named administrators, store secrets outside the repository, and record who can read the site configuration. When you add a replica or a second application server, the same access model must extend to the new hosts. Confirm where secrets are kept and how they are rotated.

FAQ on ERPNext server sizing, cost and effort

What drives the cost of ERPNext server sizing work and hosting?

The cost depends on how many environments need sizing, how much measurement data exists, and how many hosts and services the design covers. A sizing exercise is paid work by the people who review your user counts, data volumes and current exports, and then write a sizing recommendation. Hosting is a separate, recurring cost paid to your cloud provider or data center for the servers, storage and backups. For reference, the ERPNext pricing page lists Frappe Cloud servers from 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers, and self-hosting the software itself is free. Those figures are vendor list prices, not a benchmark for your workload. DeployOpen issues a quote from a written scope, so ask for the environments, hosts and review points to be listed explicitly.

How long does an ERPNext sizing exercise take?

The duration depends on how much usable data you can provide and how many environments are in scope. A single production database with clear user counts and a known peak period moves faster than a multi-company setup where usage patterns differ by site. The biggest time sink is usually collecting accurate figures from the business, such as month-end peaks and batch imports, not the technical analysis itself. Ask for the timeline in the written scope, along with the dependencies it assumes, such as access to monitoring data and a test environment for load checks.

What must our team provide before sizing starts?

Plan to provide the inputs that set the workload, not just the number of licenses. Typically this includes:

Active user counts by role, and concurrent usage at the busiest hours
Current database size, growth rate and the largest tables
The peak calendar, such as month-end close, payroll runs and stock counts
Exports from the current system, including bulk imports you expect to run
Planned integrations, background jobs and report schedules

Also confirm who signs off on the target availability and recovery expectations, since these change the hardware and storage design.

Can our internal team size ERPNext without outside help?

Yes, if you have an engineer who understands Linux, MariaDB tuning, disk latency and ERPNext background workers. The official documentation and the frappe_docker project describe the services involved, but interpreting them for your load takes measurement and experience. Internal teams usually struggle with realistic load testing and with separating a slow report from a storage bottleneck. A useful middle path is to have your team collect the metrics and have an outside reviewer check the recommendation before you buy hardware.

How often should we review ERPNext sizing?

Review sizing at least when user counts change materially, when a new company or integration goes live, before a major version upgrade, and after your data volume crosses a level you planned for. Also review it when ERPNext releases a new minor version that changes background job behavior. Schedule a regular check, such as quarterly, and treat the database growth trend as the main trigger. Whether the review is run in-house or under a retainer, the same metrics should be recorded each time so that changes are easy to compare.

What should a sizing recommendation include?

A useful recommendation names the server roles, CPU and memory for each, the InnoDB buffer pool sizing rationale, disk capacity with headroom and the IOPS target, and the point at which you scale up or add a replica. It should also state the assumptions behind each number, such as the user count and peak period used. Ask for the measurement method and the list of metrics collected, so you can repeat the exercise later. Any figure should trace to observed data or a documented vendor requirement, not to a generic rule.

Does a sizing review cover compliance or security?

Sizing itself does not assess security or compliance, but the decisions interact with them. Encrypted disks, backup storage, log retention and replica placement all add cost and change where data sits. If your organization must meet a framework, have the sizing scope reference the controls that affect storage and backups, and confirm which assessments are handled by independent auditors. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.

What to confirm with Frappe and in your environment

Before you commit to a server size, confirm which ERPNext and Frappe Framework version line you will run and how long it will receive fixes. The supported versions list on the Frappe supported versions page shows that version 14 reached end of life on January 31, 2026, that version 15 is planned to be supported until the end of 2027, and that version 16 is planned until the end of 2029. A size chosen for a line that ends within your planning horizon forces an upgrade and a second round of load testing, so check the dates against your own budget cycle. The ERPNext releases page shows frequent minor releases on both supported lines, so plan a recurring window to apply them and retest performance after each one.

If you want warranty coverage from Frappe, confirm that your deployment is on a listed version and that you hold a Frappe Cloud support plan that matches it. Confirm this with Frappe before you buy hardware, because the plan requirement affects who you call when a slow query or memory spike needs vendor attention. Also confirm whether you need Server Scripts. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. If your customizations depend on server-side Python, your sizing must cover self-hosted or dedicated capacity, because the shared option will not run them.

Finally, check the limits of your hardware or cloud provider. Ask whether the instance family gives you guaranteed IOPS and throughput for the database volume, whether burst credits apply, and what the provider charges for snapshots and cross-zone traffic. Then validate the numbers in a staging environment that holds a copy of production data, runs your real reports and scheduled jobs, and records peak CPU, memory, disk latency and database buffer usage. A benchmark against your own data and workload is the only evidence that a size will hold, so treat the vendor's guidance as a starting point and the staging results as the decision.

How DeployOpen scopes and delivers ERPNext sizing

DeployOpen treats ERPNext sizing as a written engineering decision, not a guess. We start from your transaction volumes, user counts, custom apps and reporting load, then plan CPU, RAM, disk and IOPS inside the infrastructure you control.

How we scope

Engagements are fixed-scope, with sizing inputs, assumptions and deliverables agreed in writing before work starts.
We collect user counts, document volumes, background job load, reporting patterns and growth expectations for the sizing baseline.
The written scope states which servers, database layout, storage classes and load tests are included and which are excluded.

How we build

We size the application servers, a separate database server, Redis and workers against the agreed workload profile.
We set the MariaDB buffer pool, connection limits and disk layout, then validate IOPS and free-space headroom on the target hardware.
We run load tests that replay realistic month-end and reporting activity, and record CPU, memory, disk latency and queue depth results.

How we hand over

You receive a sizing document with the chosen instance profiles, storage volumes, configuration values and the reasoning behind each one.
The handover includes scaling thresholds that show when to add vertical capacity, a read replica, or more background workers.
Monitoring dashboards and alert thresholds are documented so your team can confirm the sizing against live metrics.

How we support

Ongoing support, upgrades and capacity reviews are available as a retainer, scoped separately from the initial sizing work.
We re-check sizing after major ERPNext upgrades, new companion apps or significant growth in data volume or users.
Your team keeps ownership of the infrastructure, and we confirm vendor-specific limits and hardware requirements with you before changes.

ERPNext server sizing: CPU, RAM, disk and IOPS