VPS Capability Map: What It Does Well, What It Cannot Do, and When to Upgrade
Four scenario classes a VPS handles well, four capability borders it does not, three truths about shared resources, five acceptance commands, and three criter
# Draw the capability circle before you buy
A VPS is most people's first server, but "cheap" does not mean "fits everything". Mapping the capability circle before purchase beats complaining about overselling after it. Every claim below ships with its decision criterion.
## What a VPS handles well: four scenario classes
| Scenario | Typical load | Why a VPS suffices |
|---|---|---|
| Web hosting | corporate site, blog, small shop | Nginx/static stacks are light; peaks absorbed by headroom |
| Dev & test | CI runners, staging, learning | minutes to provision, monthly billing, throwaway environments |
| Small databases | single-node MySQL/PostgreSQL, modest data | fine while hot data fits RAM; bind it to 127.0.0.1 |
| Self-hosted tools | Git, wiki, tunnels, monitoring probes | flat load curves; 1–2 cores run forever |
Real price anchors: 1C1G at **$5.34/mo** (AX-V001), 2C4G at **$13.80** — a coffee budget per month to validate an idea. That is the VPS form factor's biggest value.
## What it is not for: four capability borders
- **Heavy database primaries.** Disk IO and memory bandwidth pass through a shared virtualization layer; write-heavy concurrency jitters. Once data volume or QPS climbs, move to dedicated (criteria below).
- **Mass mail sending.** Port 25 is restricted on most VPS fleets (industry-wide anti-spam default), and shared-block reputation is collective. Ask support about port and IP-reputation policy before building on email.
- **Hard compliance / physical isolation.** When an audit demands "physically dedicated", a virtualization boundary does not count in audit language. Go dedicated directly.
- **Sustained full-load compute.** Transcoding, scraping, compile farms running 7×24 hit fair-use policies and neighbour contention; priced by full-load hours, dedicated is cheaper.
## Three truths about resource borders
- **CPU is a shared floor.** The cores in `lscpu` are a commitment; real throughput depends on host oversubscription. Run sysbench once at acceptance and again at your business peak — never judge by core count alone.
- **Bandwidth is a scope question.** Cheap tiers are mostly shared bandwidth; "unmetered" usually carries a FUP. Read whether your port is dedicated or shared, and whether overage throttles or bills.
- **IP reputation is history you inherit.** A fresh IP may carry the previous tenant's blacklist entries. Check the major blocklists at acceptance; request a swap immediately if dirty.
## Acceptance hour: five verification commands
```bash
# 1) actual cores and model (match the config sheet)
lscpu | grep -E "Model name|^CPU\(s\)"
# 2) real RAM and disk capacity
free -h && df -h /
# 3) disk class: rotational vs solid (rota=1 means HDD)
cat /sys/block/vda/queue/rotational 2>/dev/null || lsblk -d -o name,rota
# 4) CPU baseline score (archive it; later drift shows contention)
sysbench cpu --cpu-max-prime=10000 run 2>/dev/null | grep "events per second" || echo "install sysbench first"
# 5) egress IP self-check (take it to blocklists and geo lookups)
curl -s ifconfig.me && echo " <- egress IP"
```
## When to upgrade: three criteria
Start a migration assessment on any one of: ① **resource ceiling** — CPU >80% sustained or RAM pinned, unchanged after caching and slow-query work; ② **IO jitter** — database p95 latency swings with neighbour load and users feel it; ③ **compliance knocks** — a client or regulator asks for physical isolation. Critical-point math and the dedicated path live in the selection hub; same-tier real prices in the live catalogue.
## OS choice and migration, in three practical rules
- **Linux by default:** no GUI or licence overhead, more usable resources per tier. Pick the distribution your team knows best (Ubuntu/Debian have the deepest documentation; Alma/Rocky track enterprise RHEL). Never pick an exotic distro for novelty.
- **Windows only on hard requirement:** legacy .NET Framework apps, specific commercial software, RDS habits — and confirm the licence surcharge in the config sheet before ordering.
- **Migrate by image, not by hand.** Export qcow2/vmdk when possible; otherwise write a dependency manifest and rebuild. Manual rsync migrations lose crontabs, systemd units and kernel parameters — the top three accident sources. Run the five acceptance commands before and after; the numbers must agree.
## The real TCO of a VPS
The monthly fee is only the first line. The full equation: **TCO = monthly fee + backup/snapshot extras + your ops hours × hourly rate + expected incident loss**. A $5.34 tier eating five troubleshooting hours a month costs far more than a $13.80 2C4G tier with automatic snapshots — "buy one tier up" is often the cheapest saving. Rule of thumb: two consecutive months above 60% utilisation → tier up instead of optimizing further; below 20% → tier down and refund the difference. Monitoring needs no complex system: one crontab sampling `free/df/top` into a log, read weekly. After three months you will know your load curve better than any buying guide does.