How to Choose the BEST VPS Explained
You picked a VPS. Now size it right: a spec-by-spec guide to CPU, RAM, storage, bandwidth, and the signs you chose too little or too much.
You picked a VPS. Now size it right: a spec-by-spec guide to CPU, RAM, storage, bandwidth, and the signs you chose too little or too much.
IaaS, PaaS, and SaaS in plain terms: what the provider runs, what you run, examples of each, and how to choose the model that fits your project.
A plain guide to cloud hosting: how your site runs across a pool of machines, how pooled resources and scaling work, and the honest pros and cons.
VPS, cloud, or dedicated? What each one is, what it costs in money and effort, and how to pick based on traffic, resilience, and budget.
Shared, VPS, or cloud? How to pick the right hosting for a small site, what to evaluate, and the red flags experienced users warn about.
Once you've decided a VPS is the right move, how to choose a VPS comes down to sizing four things to your workload: CPU, RAM, storage, and bandwidth. Start small and measure. A typical small site or app runs comfortably on 1 to 2 vCPUs, 2 to 4 GB of RAM, and SSD or NVMe storage, then you scale the one resource that runs out first. Most people overbuy. The right size is the one that handles your load with a little headroom, and nothing more.
This guide assumes you've already settled the type question. If you haven't, the pillar on which hosting type is best for small websites and the breakdown of VPS vs cloud hosting vs dedicated cover that, and what a VPS is covers the basics. Here we size the box you've chosen, spec by spec, with a rule of thumb for each and the signs you picked too little or too much.
Most small workloads need 1 to 2 vCPUs, and you add cores only when CPU is the thing that runs out. A vCPU (virtual CPU) is a share of a physical processor core assigned to your server. More cores help when work runs in parallel: many concurrent requests, background jobs, video encoding. They do little for a single slow task.
Two distinctions matter. Shared vCPUs draw from a pool other customers also use, which is cheaper and fine for bursty, average-load work like a typical website. Dedicated vCPUs reserve capacity for you, which costs more and earns its keep for steady high-CPU work like databases under constant query load.
The tell that you're sharing a busy host is CPU steal time, the percentage of time your virtual CPU waits for a physical core because the hypervisor is busy serving another VM. As one engineer on Hacker News put it, high steal time "is strong indication you are being ripped off CPU" (Hacker News). Check it with top or vmstat and read the column.
Managed or self-hosted? How to choose, compared on cost, maintenance, backups, and uptime, with the honest middle ground and a decision checklist.
stPlan for your working set plus headroom, not the bare minimum. RAM holds your running processes and caches. A small WordPress site with caching is fine on 1 to 2 GB, a growing app or a small database is happier at 4 GB, and anything running multiple services wants 8 GB or more. The number you want is enough to hold normal load with room to absorb a spike.
Headroom is the part people skip. An app that uses 90 percent of its RAM at rest has nothing left for a burst, and that's when it falls over. Independent sizing guides put the same practical floor on it: for a small WordPress site under roughly 20,000 to 30,000 pageviews a month with caching, 1 vCPU and 1 to 2 GB of RAM is usually enough, with 4 GB the common next tier as you grow (Launchcodex).
Swap is the safety valve, not the plan. Swap is disk space the system uses as overflow when RAM fills. A small swap file (often 1 to 2 GB, or up to the size of your RAM) stops a brief spike from killing a process, but a server that swaps constantly is slow, because disk is far slower than memory. Use swap as a cushion, then add RAM if you lean on it.
Pick storage on three axes: type, size, and IOPS. For type, prefer SSD over spinning disk, and prefer NVMe when your work is disk-heavy. NVMe (a faster way to connect flash storage than the older SATA interface) handles far more small random reads and writes, which is exactly what databases do. For size, count your data plus the OS plus room to grow, and leave 20 percent free.
The performance gap is large and worth knowing before you pay for it. Benchmarks put NVMe roughly an order of magnitude ahead of SATA SSD on IOPS (input/output operations per second, the count of small reads and writes a disk handles each second). At the queue depths databases work at, NVMe delivers on the order of hundreds of thousands of IOPS where SATA SSD tops out far lower (ServerMania). For a static site or a small app that mostly serves cached pages, SSD is plenty. For a database under load, NVMe is where the difference shows up.
Size is the easy part, with one rule: never run a disk near full. Filesystems slow down and some databases misbehave as they approach capacity. Total your application, OS image, logs, and backups, then add margin.
Match bandwidth to your transfer, and read the egress terms before you commit. Bandwidth is how much data your server moves, usually measured as a monthly transfer allowance plus a port speed (the link's maximum rate). Most VPS plans bundle generous transfer, often measured in terabytes, which covers ordinary sites easily. The cost that surprises people is egress: the per-gigabyte fee some providers charge for data leaving the server.
Two different billing models hide here. Flat-allowance plans give you a monthly transfer bucket and a slower or overage rate after, which is predictable. Metered plans charge per gigabyte of egress, sometimes with steep markups and no hard spending cap, so a traffic spike or a misconfigured backup can become a surprise bill. Neither is wrong, but they fail in different ways, and the metered model is the one that bites without warning. If you pick a metered plan, find the egress rate and whether you can set a spending limit.
Put the server near your users, because location sets your floor on latency. Latency is the round-trip delay between a user and your server, and physical distance is a hard part of it: data crosses the country in tens of milliseconds and an ocean in a hundred or more, and no plan upgrade removes that. If your audience is mostly in one region, host in that region.
Location also decides data residency, where your data physically lives. Some industries and customers require data to stay in a specific country, so check that before you pick a city. For most small projects the rule is simple: choose the region closest to the people who use the site, and think about multiple regions only when you have measurable traffic in more than one place.
Decide honestly whether you want to be the system administrator. An unmanaged VPS is cheaper and hands you everything: OS updates, security patching, firewall config, and troubleshooting at 2 a.m. when something breaks. Managed hosting does that work for you for a higher price. Neither is better in the abstract, it depends on your skills and how you want to spend your time.
This choice interacts with the OS. On unmanaged plans you typically pick a Linux distribution (Ubuntu and Debian are common, well-documented defaults), and you own keeping it patched. Pick the OS you or your team already know, because the time you save on familiar tooling outweighs small technical differences between distributions. Managed hosting, including what we offer at Carpathian, narrows that surface for you, which is worth paying for if you'd rather not run a server you're not comfortable running, and not worth it if you enjoy the control.
Keep an off-site copy you control, and don't treat the host's snapshot feature as your safety net. A snapshot is a point-in-time image of your server, fast to take and fast to restore, which makes it ideal for rolling back a bad deploy. It is not a backup, because it usually lives on the same provider as the server it protects. If the provider has a bad day or suspends your account, the snapshot goes with it.
This is the most repeated piece of advice in hosting horror stories, and it predates the cloud. "ALWAYS make backups," one administrator wrote on Hacker News. "If a provider goes deadpool on you all of the sudden, you should always have fresh backups in a remote site" (Hacker News). Use snapshots for quick rollbacks and keep an independent, off-site backup for the day the provider itself is the problem.
Because the specs on the page are a ceiling, not a guarantee, and a busy host won't deliver them. Hosts sell more capacity than they physically have, betting not everyone uses it at once. This is normal and universal: "Every provider oversubscribes," one administrator noted, because they "do not expect and cannot handle 100% utilization by their subscriber base" (Hacker News). The degree varies, and that variance is what you're buying.
So two VPS plans with identical specs can perform very differently. Catch it by measuring after you provision: watch CPU steal, run a quick disk benchmark, and check whether performance matches the brochure. If steal time is high or disk IOPS come in far below the tier's claim, you picked a crowded host, and the fix is a different provider, not a bigger plan.
Run these steps in order and you'll land on a size that fits.
The honest limitation worth keeping: you can't size perfectly up front, because you don't yet know your load, so the goal isn't a perfect first guess. The goal is a small, well-instrumented start you can adjust with one click. The best infrastructure tends to be the kind you stop thinking about: sized for what you run, easy to grow, and priced for what you use.