How to Size a VPS: CPU, RAM, Disk and Bandwidth

How to Size a VPS: CPU, RAM, Disk and Bandwidth

Picking a VPS plan is a balancing act. Over-provision and you pay every month for cores and memory that sit idle. Under-provision and your app stalls under load, swaps to disk, or gets cut off when it exhausts its bandwidth quota. This guide walks through how to size each resource — vCPU, RAM, disk, and bandwidth — based on your actual workload, and gives you the Linux commands to validate the choice instead of guessing.

If you are migrating from shared hosting or another provider, the most reliable approach is to measure first, then map those numbers onto a plan.

Start with the workload, not the plan

Before looking at any pricing page, write down what the server will actually run. The four most common shapes are:

• Web app + database on one box (WordPress, Laravel, Node): bursty CPU, moderate RAM, read-heavy disk.
• Database server: RAM-hungry (working set should fit in memory), disk IOPS matter most.
• Background/batch or build workers: sustained CPU, predictable RAM.
• Static/edge or proxy: low CPU/RAM, bandwidth is the real constraint.

Each shape stresses a different resource. Size for the one that saturates first — that is your bottleneck — and leave headroom on the rest.

CPU: vCPU is not a physical core

A vCPU is a thread of a shared physical core, scheduled by the hypervisor. For steady workloads it behaves like a dedicated core; for bursty ones, "shared" plans let you spike above baseline briefly, while "dedicated vCPU" plans guarantee full-time access.

Rules of thumb:

• A small WordPress or business site: 1–2 vCPU.
• A busy CMS, app server, or a database with moderate concurrency: 2–4 vCPU.
• CI builds, video transcoding, or sustained compute: choose dedicated vCPU, not shared.

Measure CPU pressure on an existing box:

# 1-minute, 5-minute, 15-minute load average vs core count
uptime
nproc          # number of vCPUs available

# per-core utilization, refreshed every 2s
mpstat -P ALL 2

If your 5-minute load average consistently exceeds your nproc count, or %idle in mpstat sits near zero, you are CPU-bound — add cores. If load stays well under core count, you are paying for idle vCPU.

RAM: size the working set, then leave headroom

RAM is usually the first wall you hit. The goal is to keep your application's hot data and the OS page cache in memory so the server rarely touches disk for reads.

Check real usage, not the scary "total used" number:

free -h
# Look at the "available" column, not "free".
# Linux uses spare RAM for buffers/cache and releases it on demand.

Two practical rules:

• Watch swap. If free -h shows swap actively in use under normal load, you are short on RAM and paying a huge latency penalty.
• Right-size your services. A misconfigured MySQL innodb_buffer_pool_size or too many PHP-FPM workers can exhaust RAM regardless of plan size. Tune the app before buying a bigger box.

Disk: capacity and speed are two separate decisions

Two questions: how much space, and how fast.

Capacity — sum the OS (~3–10 GB), your application, the database, logs, and uploads, then add room to grow. Reserve at least 20–30% free; databases and log rotation behave badly on a full disk.

df -h          # space used/free per filesystem
du -sh /var/* | sort -h   # find what is actually consuming space

Speed — prefer NVMe SSD, which Skyline Cloud VPS plans use by default. Spinning disks and even SATA SSDs become the bottleneck for databases. Check whether you are I/O-bound:

# %iowait high = CPU waiting on disk
iostat -x 2

# %util near 100% on your disk device = saturated I/O

If iowait is high while CPU %idle is also high, the disk — not the processor — is your limit, and faster storage (or more RAM for caching) helps more than more cores.

Bandwidth: quota and throughput

Two different numbers get called "bandwidth":

1. Monthly transfer quota (e.g. 2 TB/month) — total data in/out. Exceed it and you are throttled or billed for overage.
2. Port speed / throughput (e.g. 1 Gbps) — how fast a single transfer can move.

Estimate monthly transfer from real traffic: average page weight × page views × ~1.3 (for retries, assets, and API calls). A site serving 100,000 monthly views of ~2 MB pages needs roughly 260 GB/month outbound — comfortably inside a typical 1–2 TB allowance, but media or download-heavy sites can blow past it.

Check current usage on a running server:

# install with: apt install vnstat  (Debian/Ubuntu)
vnstat -m      # monthly totals, in and out

For users and traffic inside Saudi Arabia and the GCC, hosting in-Kingdom also reduces round-trip latency and keeps data subject to PDPL and NCA requirements — a sizing decision that is as much about location as raw capacity. See Skyline Cloud hosting and the VPS & cloud servers hub for in-Kingdom options.

Put it together: a sizing checklist

1. Identify the workload shape and its likely bottleneck resource.
2. Measure existing usage with mpstat, free -h, iostat -x, and vnstat.
3. Size the bottleneck resource with ~30% headroom; right-size the rest.
4. Prefer NVMe storage and dedicated vCPU for sustained compute.
5. Pick a plan you can scale up later — start lean and resize once metrics tell you to.

The biggest advantage of a cloud VPS is that sizing is not permanent. Begin with a conservative plan, watch the metrics above for a week or two, and resize when real data — not anxiety — says so. If you also run mail, keep it off the app server; dedicated business email hosting is cheaper and frees your VPS resources for the application.

Get started

Provision an NVMe-backed, in-Kingdom VPS with transparent pricing and local Arabic support, and resize anytime as you grow. Create your Skyline Cloud account and launch your server in minutes.