- Guessing at RAM and CPU needs leads to either overpaying for idle capacity or getting throttled during a traffic spike.
- Here is a sizing method grounded in actual usage.
How Much RAM and CPU Does Your Nepali Business Website Actually Need on a Cloud Server?
Sizing a cloud server by guessing at "how big my business is" produces bad results in both directions. A more reliable method starts from what actually consumes RAM and CPU on a typical web workload, then checks real usage data rather than assuming.
What Actually Consumes RAM
Each PHP-FPM worker process holds a chunk of memory (typically 30-80MB depending on the application's memory footprint) for the duration it is handling a request; the number of concurrent workers your traffic requires, multiplied by per-worker memory, is your PHP memory floor. MySQL/MariaDB's buffer pool (for InnoDB) is usually the next largest consumer, and undersizing it forces the database to hit disk far more than necessary. Redis or Memcached, if used, adds its own memory footprint proportional to what is being cached.
A Starting-Point Sizing Table
| Site type | RAM | vCPU |
|---|---|---|
| Brochure site, low traffic | 1-2GB | 1-2 |
| WordPress with moderate traffic | 2-4GB | 2 |
| E-commerce store | 4-8GB | 2-4 |
| Custom Laravel/Node application | 4-8GB | 2-4 |
| Multiple sites on one instance | 8GB+ | 4+ |
Checking What You Are Actually Using
Before upgrading blind, run free -h to see actual RAM usage (specifically the "available" column, not just "used," since Linux uses free RAM for disk cache that gets released instantly on demand) and top or htop during peak traffic hours to see real CPU load, not just an idle-hours snapshot. A server sitting at 40% RAM usage and low CPU load most of the day is not necessarily undersized if that measurement never included your actual traffic peak.
Signs You Are Genuinely Undersized
- Swap usage appearing in
free -hunder normal traffic — RAM has run out and the OS is using disk as overflow, which is drastically slower. - PHP-FPM logs showing "server reached max_children" warnings, meaning requests are queueing because there is not enough RAM budgeted for more concurrent workers.
- Load average (from
uptime) consistently exceeding your vCPU count during business hours.
Talk to Us About Your Server Setup
WebsNP runs dedicated servers, cloud servers and VPS out of our Kathmandu and US infrastructure, priced honestly in NPR or USD with eSewa, Khalti, Fonepay, card and PayPal accepted. Full root access, real Nepal-based system administrators on call 24/7, and a straight answer about which tier actually fits your workload.
See Server PlansSizing for a Specific Nepali Business Example
A Kathmandu-based retail business running WooCommerce with roughly 200 products, moderate daily traffic, and a handful of staff managing orders through wp-admin typically fits comfortably on 4GB RAM and 2 vCPU under normal conditions, but genuinely benefits from sizing up to 8GB during the Dashain-Tihar festival sales window specifically, when both traffic and concurrent admin activity spike together. Providers offering easy, temporary resource scaling for a known seasonal window (rather than committing to a permanently larger, more expensive plan year-round) suit this exact pattern well.
Frequently Asked Questions
Is it better to oversize slightly or size exactly to current usage?
A reasonable buffer (30-50% above current peak usage) is sensible to absorb growth and traffic spikes without needing an immediate upgrade at the first sign of increased demand.
Does adding more vCPU always help if the site feels slow?
Only if CPU is actually the bottleneck — check load average and CPU usage first; a slow site with low CPU usage usually has a database, I/O or application-code problem that more CPU cores will not fix.
Can I resize RAM and CPU later without rebuilding the server?
On most cloud platforms, yes — a resize typically requires a reboot but not a full rebuild, making it reasonable to start modest and scale up as real usage data justifies it.
