Choose shared hosting for a standard CMS site with no custom services; a VPS when you need root access and steady, modest load; cloud when demand is spiky or you want managed databases, load balancers and API-driven scaling; bare metal when load is sustained, large or sensitive to neighbors; and GPU servers only when the model or code actually runs on a GPU.
Assumptions, and when this guide does not apply
This guide is for a technical buyer or a small engineering team choosing where one application or a small group of services should run. It assumes:
- You can measure, or reasonably estimate, the workload: request rates, CPU and memory use, data size and monthly outbound traffic. If you cannot, run the workload for one to two weeks on a modest VPS first and read Sizing a VPS from real workload signals.
- The application is one you control. A packaged SaaS product you only log in to is not a hosting decision.
- Someone on your side, or a managed service, will own patching and backups. The type you choose changes who does that work, not whether it has to be done.
It does not settle these cases on its own:
- Regulated data (payment card data, health records, government workloads). The compliance scope, audit evidence and contract terms usually decide the platform before performance does. Start from Shared responsibility in hosting and your own compliance advisor.
- Large multi-region estates with dozens of teams. That is a landing-zone and governance problem, not a single type choice.
- Model training at scale. Multi-node training is dominated by interconnect and scheduling questions this guide only touches.
The decision tree: five questions in order
Ask the questions in this order. The first "yes" usually decides the type; later questions refine size and options. The order matters because a hard requirement (a GPU, root access) rules options out before cost does.
- Does the code need a GPU? If the workload uses CUDA or ROCm, serves a neural network model at useful speed, or renders or encodes video at volume, you need a GPU server. Everything else in this list runs on CPUs. Size GPU memory first with GPU memory for LLM inference; the GPU class follows from memory, not from marketing names.
- Is it a standard website on a supported stack with no custom daemons? A WordPress, Joomla or static site that needs PHP, a MySQL-compatible database and email, and no background workers, queues or root-level packages, fits shared hosting or managed hosting. If you need SSH plus your own packages, a long-running process, or a custom web server configuration, go to question 3.
- Is load steady and does it fit comfortably on one machine? If CPU and memory demand varies by less than about 3x between quiet and busy hours, and peak demand fits in a single mid-sized server with headroom, a VPS or an isolated virtual server gives you root access at a fixed monthly shape.
- Is demand spiky, or do you need managed building blocks? If peak is several times the quiet level for short windows, if you want to add and remove instances through an API, or if you want managed databases, object storage and load balancers rather than running them yourself, choose cloud hosting.
- Is load sustained, large, or sensitive to neighbors? If CPUs are busy most hours of the month, you need hundreds of gigabytes of RAM or many local NVMe drives, software is licensed per physical core, or you see CPU steal and noisy-neighbor latency you cannot accept, choose bare metal.
Want this as an interactive check? The server finder asks the same questions and shows which answer moved the result.
Signals that point to each type
Each row is a signal you can measure or confirm from documentation, what to look at, and where it points. Signals point toward a type; they rarely force one on their own. Two or three signals agreeing is a decision.
| Signal | How to measure it | Points toward |
|---|---|---|
| Needs root, custom packages or long-running processes | Your deploy steps: do they run apt/dnf, systemd units, Docker? | VPS, cloud or bare metal (not shared) |
| Peak-to-quiet ratio above about 3x | Hourly CPU or request rate over 14 days; divide the busiest hour by the quietest | Cloud (pay for peak only while it lasts) |
| CPU busy above 50-60% most hours | sar -u history; count hours above the threshold | Bare metal or a large fixed VPS |
| CPU steal regularly above a few percent | The st column in vmstat 5 or %steal in sar -u | Dedicated vCPUs, a larger VPS class, or bare metal |
| Working set above about 256 GB of RAM | Database buffer hit ratio and memory pressure (/proc/pressure/memory) | Bare metal (large memory configurations) |
| Storage latency is the bottleneck | iostat -x: r_await/w_await and queue size at peak | Local NVMe on bare metal or a storage-optimized VPS |
| High outbound traffic (many TB per month) | Interface counters (sar -n DEV) converted to TB per month | Plans with included transfer; avoid per-GB metering without a cap |
| Model inference or GPU compute | Framework requires CUDA/ROCm; model weights plus KV cache size | GPU server, sized by GPU memory |
| Small team, no one on call for the OS | Who patches the kernel next Tuesday? | Managed hosting, or cloud with managed services |
Thresholds above are planning rules of thumb, not hard limits. A 50% CPU average that is flat all month is a strong bare metal signal; the same average made of short bursts to 100% is a cloud signal.
How the five types differ where it matters
| Type | Control | Isolation | Scaling | Who patches the OS | Poor fit when |
|---|---|---|---|---|---|
| Shared | Control panel, no root | Account-level on a shared OS | Move up a plan | Provider | You need custom services or predictable CPU |
| VPS / virtual server | Full root | Hypervisor (own kernel) | Resize, usually with a reboot | You, unless managed | Load swings far above the size you pay for |
| Cloud | Root plus APIs and managed services | Hypervisor plus network policy | Add or remove instances in minutes via API | You for instances; provider for managed services | Steady heavy load or large metered egress |
| Bare metal | Full hardware, BIOS/IPMI options | Single tenant | Order more servers; plan ahead | You, unless managed | Spiky or small loads; no one to run HA |
| GPU server | Root, drivers, CUDA/ROCm stack | Whole GPUs, or partitions on some models | Add GPUs or nodes; supply can be the limit | You (drivers and runtime included) | The code does not use the GPU most of the time |
The NIST definition of cloud computing (SP 800-145) lists on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. If you will not use elasticity or measured service, you are paying for features you do not use, and a fixed VPS or bare metal shape is often simpler.
Cost shapes: what you pay for when the server is idle
Compare hosting types by cost shape before comparing unit prices. A fixed server charges for its full size every hour. Metered cloud charges for what runs, usually at a higher rate per unit. Egress and storage can be fixed, included up to an allowance, or metered per GB. Prices for any configuration are Price shown at quote; the arithmetic below works with any prices you plug in.
Worked example 1: a daily peak
Assumption: an application needs 4 vCPU most of the day and 16 vCPU for 2 hours each evening. A month is taken as 730 hours (8,760 hours / 12) and 30.4 days.
- Fixed server sized for peak: 16 vCPU x 730 h = 11,680 vCPU-hours paid.
- Elastic: base 4 vCPU x 730 h = 2,920, plus extra 12 vCPU x 2 h x 30.4 days = 730. Total 3,650 vCPU-hours.
- Ratio: 11,680 / 3,650 = 3.2. Elastic is cheaper as long as its rate per vCPU-hour is less than 3.2 times the fixed rate.
Worked example 2: a flat load
Assumption: an analytics worker uses 12 of 16 vCPU at almost every hour of the month.
- Fixed 16 vCPU: 11,680 vCPU-hours paid, 8,760 used. Utilization 75%.
- Elastic sized to 12 vCPU: 8,760 vCPU-hours paid. Ratio 11,680 / 8,760 = 1.33.
- Elastic only wins if its hourly rate is less than 1.33 times the fixed rate. On-demand cloud rates typically carry a larger premium than that, which is why flat, busy loads drift toward VPS or bare metal. Check with the 3-year TCO calculator.
Worked example 3: egress
Assumption: a media site averages 60 Mbit/s outbound across the month.
- 60 Mbit/s = 7.5 MB/s. A 30-day month has 2,592,000 seconds.
- 7.5 MB/s x 2,592,000 s = 19,440,000 MB = 19.4 TB per month.
- Metered cost = 19,440 GB x your per-GB rate. Included allowance cost = 0 until the allowance, then the overage rate. At this volume the transfer terms can matter more than the server price. Ask for them in writing.
| Type | Compute | Storage | Outbound traffic | Idle cost |
|---|---|---|---|---|
| Shared | Flat plan | Plan quota | Usually included, fair-use terms | Low, fixed |
| VPS | Flat monthly size | Attached to the size | Allowance, then overage | Full size, every hour |
| Cloud | Per hour or second | Per GB-month, plus I/O on some tiers | Often metered per GB | Only what stays running |
| Bare metal | Flat monthly, often with a term | Drives in the server | Allowance or committed port | Full server, every hour |
| GPU server | Per GPU-hour or monthly | Local NVMe plus shared storage | Allowance or metered | High; idle GPUs are the costliest idle resource |
Three worked scenarios
WooCommerce store, 20,000 orders a year
Needs PHP workers, a MySQL-compatible database, object cache and cron. Load roughly doubles during campaigns. Shared hosting will hit worker limits at checkout during campaigns; a 4 vCPU / 8 GB VPS with a page cache handles the base, and a resize before planned campaigns covers peaks. Choose a VPS, or managed hosting if no one patches the OS.
B2B SaaS API with weekday peaks
Weekday 09:00-18:00 traffic is about 6x the overnight level, and the team wants a managed PostgreSQL and a load balancer. The peak-to-quiet ratio and the managed-service need both point to cloud. Keep the database on a fixed size; scale only the stateless API tier.
Internal LLM assistant, 8B model
An 8B model at 16-bit precision needs about 16 GB for weights alone, before KV cache. A CPU server will answer, but slowly. A single GPU with 24-48 GB of memory fits a modest number of concurrent users; the GPU memory calculator shows how context length changes that.
Migration paths between types
Choosing a type is not permanent, but some moves are much cheaper than others. The expensive moves are the ones that remove a managed service you have come to depend on.
| Move | What changes | Main risk | Plan for |
|---|---|---|---|
| Shared to VPS | You now run the web server, PHP, database and mail | Mail and DNS records forgotten | Export files and database, lower DNS TTL 48 h ahead, move mail separately |
| VPS to cloud | Servers become images and templates; state moves to managed services | Hidden local state (uploads, sessions, cron on one box) | Move uploads to object storage, sessions to a shared cache, write the setup as code |
| Cloud to bare metal | Managed database, load balancer and autoscaling become your job | Losing failover you never had to think about | Run HA (replica plus failover) yourself, or keep the database managed |
| VPS to bare metal | Same OS model, larger and single-tenant | Hardware failure now takes the whole server down | RAID, a second server or a tested restore plan |
| Any to GPU | Driver, CUDA or ROCm version and framework build | Version mismatch between driver and framework | Pin driver, runtime and framework versions in the image |
Before any move, time the data transfer. The migration capacity tool converts data size and link speed into a cutover window, and Migration planning and cutover covers DNS, rollback and validation.
When a GPU is, and is not, the answer
A GPU server makes sense when the hot path of the application runs on the GPU: model inference, fine-tuning, embedding generation at volume, video encoding or scientific compute. It does not make sense for a web application that calls a hosted model API; that application is a normal CPU workload.
Size GPU servers by memory first. Model weights take roughly parameters x bytes per parameter (an 8B model at 2 bytes is about 16 GB), and the KV cache grows with context length and the number of concurrent requests. If weights plus cache do not fit in one GPU, you need either a larger GPU, lower precision, or several GPUs with tensor parallelism. Then check throughput economics with model-serving economics. GPU classes are quoted subject to supplier availability, with the exact model confirmed in writing.
Checklist before you request a quote
- Hourly CPU, memory, disk latency and outbound traffic for at least 7 days, including a busy period.
- Peak-to-quiet ratio calculated from those numbers.
- A list of what the application needs at OS level: root, packages, daemons, kernel modules, GPU drivers.
- Who patches the OS and who restores from backup, written down by name or role.
- Monthly outbound traffic in TB, and whether it is growing.
- Data size, growth per month and the RPO/RTO the business expects (see Backup and disaster recovery).
- Any licensing tied to physical cores or sockets.
- The managed services you would have to replace if you moved later.
- The result of the server finder, with the answers that drove it.
Common mistakes
- Sizing for peak around the clock. A server sized for a two-hour peak sits mostly idle the other 22 hours. Either accept that cost knowingly or put the peak on an elastic tier.
- Choosing cloud for a flat, busy load. Elasticity has no value if nothing scales down. Run the cost-shape ratio in worked example 2 before committing.
- Ignoring egress until the first invoice. Multiply average outbound Mbit/s by 0.324 to get TB per 30-day month (1 Mbit/s = 0.125 MB/s x 2,592,000 s = 324 GB).
- Treating shared hosting as a small VPS. Shared plans limit processes, workers and execution time. A checkout or import that needs more fails quietly.
- Buying bare metal without an HA plan. One physical server is one failure domain. Budget for a second server or a tested restore path.
- Picking a GPU by name rather than memory. The first question is whether weights plus KV cache fit; compute speed comes second.
- Reading CPU averages without steal. A VM that shows 60% CPU with 15% steal is short of CPU it was promised, not idle.
Frequently asked questions
Is a VPS the same as cloud hosting?
Both run on virtual machines, but a VPS is usually a fixed size billed monthly, while cloud adds API-driven scaling, per-hour metering and managed services. If you never scale or use managed services, the difference is mostly billing.
When does bare metal beat a large VPS?
When CPU is busy most hours, when you need very large memory or many local NVMe drives, when software is licensed per physical core, or when CPU steal and neighbor noise affect latency. Below that, a large VPS is simpler to resize.
Can I start on shared hosting and move later?
Yes. Shared to VPS is one of the cheapest moves: export files and the database, lower the DNS TTL ahead of time, and plan email separately because it is often bundled with the shared plan.
How long should I measure before choosing?
At least 7 days, and 14 if your traffic has a weekly cycle. Make sure the window includes a busy period such as a campaign, month-end or a release.
Do I need a GPU to run an AI feature?
Only if you host the model yourself. An application that calls an external model API is a normal CPU workload. Self-hosting needs GPU memory for weights plus KV cache; the GPU memory calculator gives the number.
What does BroadNet Cloud need from me for a quote?
The measured signals in the checklist above, or your best estimate of them. Every quote lists the supplier, region, inclusions and renewal terms in writing.
Sources
- SP 800-145: The NIST Definition of Cloud Computing, NIST
- SP 800-146: Cloud Computing Synopsis and Recommendations, NIST
- SP 800-125: Guide to Security for Full Virtualization Technologies, NIST
- vmstat(8) manual page (st: time stolen from a virtual machine), Linux man-pages project
- PSI: Pressure Stall Information, Linux kernel documentation
- iostat(1) manual page, Linux man-pages project