Shared hosting, VPS or bare metal: a decision table
Five questions decide the tier, and none of them is "how big do I feel". Do you need root, is your load steady or spiky, what does an hour of downtime actually cost you, who performs the sysadmin work, and do you need authority over the physical machine? Answer those honestly and the tier picks itself. For most estates of small sites the answer stays on the entry tier for years.
The five questions
- Root. Not "would root be nice". Name the specific thing you cannot do without it: a PHP extension nobody offers, a daemon that must run continuously, a custom firewall table, a non-standard port. If you cannot name it, you do not need it yet.
- Load shape. Steady low traffic behaves nothing like a flat baseline with sharp campaign spikes. Shape matters more than the monthly total, because a shared platform smooths steady work well and punishes bursts.
- Cost of one bad hour. Put a number on it. A portfolio of content sites might lose almost nothing. A checkout losing orders per minute is a different instrument entirely.
- Who does the work. Every step up transfers responsibility for patching, backups, service restarts and log reading onto whoever holds the root password. If that person is you at midnight, count the hours as part of the price.
- Machine-level authority. Kernel version, disk layout, no neighbours at all, hardware you can specify. Compliance and licensing sometimes demand this; taste never does.
The decision table
| Question | Stay on shared | Move to VPS | Go bare metal |
|---|---|---|---|
| Root access | No named requirement | One or more named requirements | Kernel or disk-layout control required |
| Load shape | Steady, modest, predictable | Spiky, or a steady climb that keeps hitting limits | Sustained heavy load that never drops |
| Cost of an hour down | Low; you can wait for support | Meaningful; you want to fix it yourself | High enough to fund redundancy and standby |
| Sysadmin capacity | None, and you want none | Competent operator, or a managed arrangement | Real operations cover, not one person's evenings |
| Machine-level authority | Not needed | Isolation from neighbours is enough | Dedicated hardware is a written requirement |
| Typical fit | Small-site estates, brochure and content sites | Apps, stores, staging plus production, custom stacks | Heavy databases, large indexes, licensing or audit constraints |
Reading a mixed verdict
Rows rarely agree, so use two rules. First, root is a gate, not a preference: one genuine named requirement moves you up on its own, however small the site. Second, everything else is a majority vote. Three or four rows pointing at the same column is a real signal; one row pointing up while four point down means you have an application problem, a caching problem or a code problem, and buying a bigger machine will simply host that problem at a higher cost.
The expensive mistake
Moving up for prestige rather than constraint is the most common overspend in hosting, and it bills monthly forever. The tell is that nobody can complete this sentence: "we moved because X was impossible on the previous tier". A second tell is a fresh VPS sitting at low utilisation while its owner learns package management on production. The upgrade also silently reassigns work: on the entry tier somebody else patches the stack, and above it that job is yours.
Before you commit
- Write the one sentence naming what is impossible on your current tier. No sentence, no move.
- Check that the ceiling you hit is a real resource limit and not an uncached page or a missing database index.
- Name the person who will apply security updates, and the day of the week they will do it.
- Confirm that backups and restores exist at the new tier before migrating anything, because that responsibility usually moves with the root password.
- For bare metal, write the requirement that only dedicated hardware satisfies. If it is comfort rather than constraint, stop here.
Under-buying is a one-evening migration. Over-buying is a recurring charge plus an operations job you did not plan to hold. When the table is genuinely balanced, take the lower tier and let a measured limit, not an ambition, push you up. Sizing within a tier is a separate exercise, covered under sizing and selection.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.