Choosing the Right Frappe Cloud Server Plan
Frappe Cloud offers multiple plans for both application and database servers. Since workloads vary over time, it’s completely normal to adjust your server plan after deployment. The Analytics tab in the Frappe Cloud dashboard provides the metrics you need to determine when it’s time to scale CPU, memory, or storage.
Tip
Most deployments require some tuning after real users begin using the system. Monitor server analytics regularly and upgrade resources based on actual usage rather than estimated requirements.
Using Server Analytics
The Analytics section of your Frappe Cloud server dashboard provides insights into server performance. The most useful metrics when selecting or upgrading a server plan are CPU usage, Load Average, and Memory consumption.
CPU Usage
The CPU chart displays how processor time is being utilized by your server.
- Idle — CPU resources that are currently unused. Lower idle percentages usually indicate higher server activity.
- iowait — Time spent waiting for storage operations such as reading or writing files and database data.
- nice — CPU time used by low-priority background processes, including scheduled jobs and queued tasks.
Database Recommendation
A consistently high iowait value on a database server usually indicates insufficient memory. Increasing RAM allows MariaDB to cache more data in memory, reducing disk access and improving database performance.
Load Average
Load Average measures the number of processes waiting for CPU resources over different time intervals.
- Load Average 1 — Average system load over the last 1 minute.
- Load Average 5 — Average load over the last 5 minutes.
- Load Average 15 — Average load over the last 15 minutes.
Short spikes in the 1-minute average are usually normal. However, consistently high values in the 15-minute average may indicate sustained server pressure.
If the load average regularly exceeds the number of available CPU cores, consider optimizing your application or upgrading to a server plan with more CPU resources.
Bench Memory Usage
Each Bench consumes approximately 400 MB of memory at minimum capacity, including web workers and background workers.
As more sites are added to a Bench, Frappe Cloud automatically allocates additional resources where possible. Servers with limited memory should avoid hosting too many Bench Groups.
You can monitor available memory directly from the Analytics dashboard.
Web Workers (Gunicorn Workers)
Web workers process incoming HTTP requests to your sites.
- Small deployments generally perform well with two workers.
- Long-running requests can occupy workers and cause gateway timeout errors.
- Frappe Cloud automatically determines the number of workers based on your site plans and Bench configuration.
Background Workers
Background workers execute queued tasks such as scheduled jobs, reports, imports, and functions created using frappe.enqueue().
Most small and medium deployments require only a single background worker because queued jobs execute asynchronously.
Frequently Asked Questions
Why is database memory usage often above 90%?
MariaDB is configured to utilize available memory efficiently by caching database pages in RAM. High memory utilization is expected and usually indicates healthy database performance rather than a problem.
As a general guideline, database server memory should closely match the total size of your database whenever possible.
Why do background jobs fail with “Work-horse terminated unexpectedly”?
This error generally indicates that the application server does not have enough available memory to execute queued background jobs. Upgrading the application server memory typically resolves the issue.
Why separate application and database servers?
Application servers and database servers have different resource requirements.
- Application servers generally require more CPU resources to process user requests.
- Database servers benefit from larger memory allocations to cache data and improve query performance.
Separating these workloads allows each server to be optimized independently and scaled as requirements grow.
How should I estimate a server plan?
Initial server sizing is an estimate based on expected usage. After deployment, monitor CPU, memory, and load metrics through the Analytics dashboard and upgrade or downgrade resources as your workload evolves.
Best Practice
Instead of choosing the largest server immediately, start with a plan that matches your expected workload and use the Analytics dashboard to monitor performance. Scaling based on real usage helps optimize both performance and infrastructure costs.