VPS Resource Calculator

First, Not the Package Name, but the Workload's Nature

When choosing a VPS, the package name easily deceives you. "Basic", "standard", "premium", "general purpose"… They look nice. But none of those names alone tells you how much RAM the site will consume, when it will choke the CPU, or which day the disk will fill up.

A static site and a WooCommerce store don't need the same server even if they get the same visitors. In one, ready-made files are served; in the other, there are carts, payments, stock, user sessions, database queries, an admin panel, and sometimes background queue jobs. That's exactly where the difference lies.

This calculation model reads a VPS through four main resources: vCPU, RAM, disk, and monthly traffic. But it doesn't take them as bare numbers; it evaluates them together with application type, environment level, cache/CDN usage, services running on the same VPS, logs, local backups, and growth margin.

There's no single "official VPS formula." In fact, large cloud providers' documentation also approaches it this way: CPU, memory, network, and storage are considered together; machine families are separated by workload. General-purpose machines behave differently, compute-optimized machines differently, memory-optimized machines differently. The same logic applies on the VPS side, just at a smaller scale.

flowchart LR
  A["Application type"] --> E["Resource estimate"]
  B["Traffic and cache"] --> E
  C["Database, worker, admin panel, Docker"] --> E
  D["Disk, logs, backups, growth buffer"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disk"]
  E --> I["Monthly traffic"]

The sentence I dislike most in these kinds of calculations is: "2 vCPU is enough." Enough for what? For a static site, WooCommerce, Odoo, a Node API, or a mixed setup running MySQL, Redis, mail, and Docker on the same box?

Also, the difference between shared CPU and reserved/dedicated CPU is often overlooked. On small VPS plans, the CPU is often shared. That might not be a problem for light websites. But on systems that regularly run workers, get traffic spikes, generate reports, or frequently load the database, the same number of vCPUs can feel weaker than expected.

Therefore, the output here should be read not as a "definitive plan" but as a safe starting estimate. It provides a good first picture for resource selection. In production, the final word is again spoken by metrics: CPU usage, RAM consumption, disk fullness, network traffic, slow queries, error logs, worker queue.

Paper is one thing, the server is another.

Where do we start?

The first distinction in the calculation comes from the application type. Because the baseline load for each application class is not the same.

A static site sits on the lightest side. Baseline CPU is assumed to be 1 vCPU, baseline RAM 1 GB; the CPU factor is also kept low, like 0.2. That makes sense. Because on a well-cached static site, the server mostly serves ready-made files, and the application layer runs very little.

For WordPress / blog, the starting point rises: baseline CPU 1.5 vCPU, baseline RAM 2 GB, CPU factor 1. WordPress has a PHP and database foundation. With themes, plugins, image processing, admin operations, search, comments, etc., it doesn't behave like a static site. Still, it can be considerably relieved with proper caching.

WooCommerce / e-commerce is another class. In this model, baseline CPU is taken as 2.5 vCPU, baseline RAM 4 GB, CPU factor 2. In my opinion, this distinction is essential for e-commerce. Because WooCommerce, on top of plain WordPress, adds cart, payment, order, stock, and membership layers. Also, some pages are not fully cacheable. The product page can come from cache, but things change on the cart and checkout side.

For Laravel / PHP applications and Node.js / API, baseline CPU is 2 vCPU, baseline RAM 3 GB, CPU factor 1.2. Here, the real need depends heavily on the code. A simple API can run very lightly; an application that talks to external services, constantly processes data, and uses queues can be much heavier in the same class.

For small SaaS, baseline CPU is 3 vCPU, baseline RAM 4 GB, CPU factor 1.8. User sessions, background jobs, notifications, reports, and database traffic usually come together. The visitor count may look small, but there are many in-app operations. If you look at it like a website, you'll choose the wrong package.

Odoo / ERP-like systems are on the heavy side: baseline CPU 4 vCPU, baseline RAM 8 GB, CPU factor 3. In Odoo setups, worker and memory planning is already considered separately. Reporting, user sessions, modules, database operations, and long-running tasks distinguish this class from a normal blog site.

For game servers, baseline CPU is 3 vCPU, baseline RAM 4 GB, CPU factor 2.5; on the bot / worker side, baseline CPU is taken as 2 vCPU, baseline RAM 2 GB, CPU factor 1.5. Especially in worker-type workloads, the visitor count can be misleading. Even if nobody visits the site, data is being processed in the background.

The environment selection sits on top of the baseline value like a coefficient. Test / hobby environment is considered 0.75, small production 1, production 1.25, high-availability readiness 1.6. High-availability readiness doesn't mean "a single VPS is now HA"; it just means leaving a larger resource cushion. Real HA requires a separate architecture.

Growth margin also comes into play at the end. Default is 30%. I think it's reasonable. It's a good range to meet 3-6 month growth expectations. You can enter 300%, but if such growth isn't really expected, the calculation turns into a fear calculation.

Traffic calculation: the monthly average is a bit deceiving

Monthly visitor count is the first data to look at, but it's insufficient for the final decision. Two sites with 100k visitors may not generate the same load. One shows 1.5 pages per visitor, page size is 1 MB, and the CDN works well. The other shows 4 pages per visitor, page size is 3 MB, and has more dynamic areas. Same visitors, completely different server load.

The traffic calculation takes the visitor count, pages / session value, and average page size together. Then the cache effect is subtracted, growth margin is added, and the result is converted to GB. The final value is rounded to 50 GB steps; even in very small scenarios, a minimum of 50 GB traffic is shown.

The assumptions used on the cache side are as follows: no cache means 0 savings, basic cache 35%, page + object cache 60%, CDN + strong cache 75%. These are not official guaranteed values. When NGINX cache or CDN is used, the origin server load is expected to decrease; but the actual savings depend on the cache hit ratio, page structure, and dynamic areas.

Especially in WooCommerce, be careful about this. Just because there's a CDN, the cart and checkout pages don't suddenly become free. Cache is more limited in places like personalized content, sessions, admin operations, payment flow, and stock control. Cache is a good brake; it doesn't replace the engine.

There's also the peak hour multiplier. Monthly traffic isn't evenly distributed. Campaign days, newsletter sends, social media shares, sudden spikes on news sites... While the average value looks calm, the server might sweat for an hour. In this calculation, Peak RPS is approximately found by dividing monthly visitors × pages / session × peak hour multiplier by the number of seconds in 30 days. 30 days is 2,592,000 seconds.

The traffic impact on CPU is even more interesting. The visitor count is scaled to 50,000, multiplied by the workload CPU factor, the peak hour multiplier is added, and half of the cache effect is subtracted from the CPU side. In other words, cache significantly reduces traffic, but the CPU impact is reduced more cautiously. I think that's the right approach; because not every request comes from cache.

In a static cached site test, with 100k monthly visitors, 1.5 pages / session, 1 MB page size, peak hour multiplier 2, CDN + strong cache, and 20% growth margin, the result stays at 1 vCPU, 2 GB RAM, 40 GB disk, 50 GB monthly traffic. There's traffic, but the load is light.

There's no such comfort in the e-commerce example. With 200k monthly visitors, 4 pages / session, 3 MB average page size, peak hour multiplier 5, page + object cache, and 50% growth margin, monthly traffic reaches 1450 GB. The CPU recommendation is 32 vCPU. At first glance, it may seem high; but when you stack the numbers, the picture gets tougher: more visitors, more pages, larger pages, heavier workload, higher peak.

Page size is a separate trouble. Saying "the site is light" isn't enough; you need to measure it. Large images, fonts, third-party scripts, ad codes, analytics tags, and unnecessary JS files inflate traffic. The fact that it loads quickly in the browser doesn't mean the data transfer is small.

Who else works on the same box?

On small VPSes, the real fight often happens here. The web server doesn't stand alone. MySQL is also in the same place, Redis too, the panel too, maybe the mail service too. Add Docker containers and worker processes, and 2 GB RAM runs out of breath.

If the database is on the same VPS, additional RAM load enters the model. The database size is divided by 20; the result is capped at a minimum of 1 GB and a maximum of 8 GB. For example, even for a 5 GB database, 1 GB of RAM is allocated. For a 30 GB database, about 1.5 GB of extra load is created. On the CPU side, 0.5 vCPU is added for the database.

These values are not a database tuning calculation. If indexes are bad, queries are long, or there are table locks, 0.5 vCPU won't be enough. But it's better than treating the database as "zero cost" for initial planning.

If Redis / object cache is on the same VPS, 0.5 GB is added to RAM. Redis works in memory; if you forget this, you'll see strange slowdowns on a small server. It's set up to improve cache performance, yes, but it also needs RAM itself.

There are three levels of control panel: none, lightweight panel, and full panel like cPanel / Plesk. A lightweight panel adds 0.3 GB to RAM and 0.15 vCPU to CPU. A full panel adds 1 GB to RAM and 0.3 vCPU to CPU. Installing cPanel or Plesk-like systems on a 1 GB RAM VPS and then expecting performance from the application is not a good idea. The panel provides convenience; you pay for it with resources.

The number of workers / queues is directly impactful. For each worker, 0.5 GB RAM and 0.5 vCPU are added. That may seem a bit high, but it makes sense if background jobs are serious. Image processing, generating reports, pulling data from external APIs, emptying the mail queue, post-payment tasks... If a worker isn't idle, it consumes resources.

If the email service runs on the same VPS, 0.5 GB RAM and 0.3 vCPU are added. Besides the resource side, a mail service is also operationally burdensome. DNS, SPF, DKIM, DMARC, spam, queue, deliverability. This calculation only sees the resource share; it doesn't calculate the headache.

For Docker / container usage, 0.5 GB RAM and 0.2 vCPU are added. Docker brings order, but it's not free. If Docker's memory limit, swap behavior, and CPU shares aren't configured correctly, one container can squeeze the whole machine. "We used containers, we're relieved" isn't always the right sentence.

The essence of the CPU calculation is this: take the larger of the baseline CPU and the traffic CPU requirement, add service CPU loads, apply the environment coefficient and growth margin. For RAM, baseline RAM and service RAM are summed, then environment and growth margin are added. Then the result is rounded to practical package steps: CPU 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; RAM 1, 2, 4, 8, 16, 32, 64, 128 GB.

There's no fractional world. If the need is 5.3 GB RAM, you look at 8 GB. If it comes out to 3.1 vCPU, 4 vCPU makes sense. Making millimeter-accurate calculations in a production environment pushes you toward the wall at the slightest fluctuation.

On disk, the real load is sometimes the invisible things

People assume the disk need is small because the code folder is small. This is a calculation mistake we see a lot. App 3 GB, media 10 GB; they say "20 GB disk is enough." Then come logs, database, local backup, system files, container images, temp files.

The disk calculation is done with application files, media / upload, database size, daily log, log retention days, and local backup copy. If the database is not on the same VPS, it doesn't enter the disk calculation. If it's on the same VPS, it does.

First, a disk subtotal is formed: application files + media files + database if on the same VPS + daily log × retention days. Then the number of local backup copies is factored in. One local backup roughly doubles the data set. On top of that, a 15 GB system share is added, a 20% safety margin is applied, and the growth margin is also added. The result is rounded to 10 GB steps and a minimum of 20 GB is recommended.

Don't let the 15 GB system share look small. The operating system, packages, update remnants, temp files, service logs, Docker images, database temp files all take space from there. In production, disk isn't just your upload folder.

Logs are also sneaky. 0.5 GB of logs per day and 14 days of retention equals 7 GB. 2 GB per day and 30 days retention equals 60 GB. It grows silently. Disk passes 80%, then 90%, then during a deploy, that famous error: no space left on device.

Local backup also requires attention. Keeping backups on the same disk isn't complete assurance in a disaster scenario; if the disk goes, the backup goes too. But for a quick rollback, a local copy can work. The model includes this in the resource calculation. Decisions like remote backup, object storage, or a separate backup server should be planned separately.

In a WordPress production test, with 5 GB application files, 10 GB media, 5 GB database, 0.5 GB daily logs, 14 days retention, 1 local backup, and 30% growth margin, a 90 GB disk is recommended. At first glance, that's a lot. But when logs, backup, system share, and safety margin are added, it's not too much, it's rather cautious.

On the e-commerce side, things grow: 10 GB application files, 80 GB media, 30 GB database, 2 GB daily logs, 30 days retention, 1 local backup, and 50% growth margin. The resulting disk is 480 GB. If product images, order data, logs, and backup are all on the same box, this result isn't surprising.

Cutting too much on disk is a bad habit. If CPU is insufficient, you see slowdowns. If RAM is insufficient, swapping starts. If disk fills up, services sometimes break much harder: the database can't write, logs aren't created, the session file can't be opened, deploys remain half-finished. Worse, the error doesn't always explain itself cleanly.

When converting the result to a package

There are four main values in the output: CPU, RAM, disk, and monthly traffic. Don't lump them together. Each one represents a different limit.

CPU is instantaneous processing power. A PHP request, Node.js API response, database query, worker task, post-payment processing... These touch the CPU. When traffic increases, CPU may increase; cache can reduce it, but not completely eliminate it.

RAM is the space for running services. MySQL, Redis, PHP-FPM, Node.js processes, panel, Docker containers, mail service, workers. When RAM runs low, the system may fall back to swap. It acts like it's working, but it gets heavier. This difference is quickly felt especially in dynamic applications.

Disk is persistent storage. Application files, media, database, logs, backups, and system files rely on it. In disk calculations, you should think not of today's size, but of the accumulation a few months later.

Monthly traffic is data transfer. CDN, cache, and page optimization reduce it. The provider's traffic policy should also be checked separately: is there a quota, an overage fee, or throttling? The calculation gives the GB need; it doesn't give the provider's commercial terms.

In this model, raw values are rounded to practical package steps. If there's a raw need for 3.4 vCPU, 4 vCPU is recommended. If there's a 9 GB RAM need, it can go up to the 16 GB level. Disk is also rounded to 10 GB steps. This rounding sometimes makes the result look larger than it is, but VPS packages aren't sold with fractions anyway.

And there's this: 4 vCPU might not behave like the same 4 vCPU from every provider. CPU generation, shared/dedicated structure, virtualization layer, disk type, network quality, neighbor machines—all make a difference. Providers like DigitalOcean don't emphasize the shared vs reserved CPU distinction in their plan selection docs for nothing.

So this calculation should be thought of as a technical check before hitting the purchase button. If you have an existing system, compare it with real metrics side by side: CPU graph, RAM usage, disk fullness, network egress, slow queries, 5xx errors, queue waiting time. If you're setting up a new system, try a few scenarios.

What happens without cache? How much does traffic drop when you choose CDN? Does RAM breathe when the database is moved off the same VPS? Where does CPU go when the worker count rises from 0 to 4? How much does a local backup copy inflate the disk?

Package selection sometimes emerges from the answers to these questions, not from a single result line.

If it were me, I'd look at three values again, especially: the peak hour multiplier, whether the database is on the same VPS, and the local backup copy. Because in real life, these are what throw the calculation off the most. Traffic piles into one hour, MySQL eats more RAM than expected on the same box, and backups fill the disk. Then everyone gets angry at the CPU package.

Sometimes it's not the CPU's fault.