Shared Hosting vs VPS vs Dedicated Infrastructure

Hosting conversations often collapse into brand names and monthly prices. The useful distinction is who owns the failure: the neighbour on your CPU, the hypervisor, or the metal. Shared hosting, a virtual private server (VPS), and dedicated infrastructure are three operating models. Picking the wrong one is less about “not scaling” and more about discovering at 11pm that you cannot restart PHP, cannot install a firewall, or cannot get a human to move a disk image.

This article compares those models for business websites and applications. For the narrower choice between a single VPS and a managed cloud platform, see choosing between a VPS and cloud hosting. Palmate’s cloud and DevOps work sits on the VPS and dedicated side once you have outgrown a panel.

Shared hosting: someone else’s machine, many tenants

Shared hosting puts many sites on one operating system. You get a control panel, FTP or git deploy, PHP or a limited runtime, and email. You do not get a kernel you can tune, a firewall you fully control, or isolation from noisy neighbours beyond what the provider implemented.

That is a feature when your need is a brochure site, a blog, or a modest WooCommerce catalogue with plugins the host already supports. The provider patches the OS, rotates backups (sometimes), and answers “why is Apache down?” You pay for convenience and accept constraints: cron frequency, process limits, no Docker, no custom daemons, and a support queue when something is actually wrong.

Shared hosting fails businesses when:

• You need a long-running worker, a queue, or a version of Node/Python the panel does not offer.
• Traffic or a plugin spikes CPU and your site is the one throttled — or you throttle someone else.
• Compliance or a customer questionnaire asks who else shares the database server and you cannot answer.
• You want staging that matches production. Panel “staging” is often a subdirectory with different paths.

If the product is still a marketing site with a form, shared hosting can be the correct, boring choice. Web development still has to respect those limits: no assuming you can install Redis on the box.

VPS: a virtual machine you operate

A VPS is a virtual machine with a dedicated slice of CPU, memory, and disk (the honesty of “dedicated” varies by oversubscription). You get root. You choose the OS. You install Nginx, Docker, Postgres, or nothing.

That control is why teams leave shared hosting. It is also why VPS incidents are usually self-inflicted: an unattended apt upgrade, a full disk, an open database port, or a deploy that was scp and hope.

A VPS is a good default when:

• You run a containerised app or a reverse proxy you understand.
• You need SSH, custom packages, or a worker process.
• One or two environments (staging + production) fit on one or two modest machines.
• You can name who applies patches and who tests restores.

A VPS is a poor default when nobody in the company has time to secure a Linux production server, or when you need multi-region failover and pretend a single droplet is “the cloud.”

Uptime on a VPS is a combination of the hypervisor, the network, your application, and your runbooks. Provider “99.9%” network SLAs do not include you filling the disk. Translate percentages into minutes with the uptime calculator before you promise a customer a number you cannot instrument. The companion article 99.9% vs 99.99% uptime is about what those nines cost in operations, not in marketing copy.

Dedicated infrastructure: metal, racks, and contracts

Dedicated usually means a physical server (or a small rack) assigned to you. Sometimes it means a colocation cage with hardware you own. Isolation from noisy neighbours is real. You can size NICs, RAID, and GPUs in ways a cheap VPS will not match.

You also inherit firmware, remote consoles, spare disks, and lead times. A failed drive is your incident unless you paid for a managed dedicated product. Cooling, power, and “the building had a fire panel test” become relevant.

Dedicated is justified when:

• Licensing, data residency, or a customer contract forbids multi-tenant hypervisors.
• Sustained CPU, disk IOPS, or network is cheaper on metal than on equivalent VPS SKUs.
• You already have staff who rack, image, and replace hardware — or a host that does it under a named SLA.

It is not justified because a sales deck said “enterprise.” A poorly run dedicated box is worse than a well-run VPS: same SSH mistakes, slower to replace.

Comparison at a glance

	Shared hosting	VPS	Dedicated
Isolation	Weak to moderate	Stronger (VM boundary)	Strongest (physical)
Root / custom stack	Usually no	Yes	Yes
Who patches the OS	Provider	You (or your partner)	You or managed provider
Typical fit	Sites, simple CMS	Apps, Docker, APIs	High I/O, residency, hardware control
Failure you cannot fix	Neighbours, panel limits	Hypervisor, your config	Hardware, facility, your config
Cost shape	Low, bundled	Predictable VM invoice	Higher base, slower to resize

“Cloud” in vendor language often means VPS-like VMs plus extra services (load balancers, managed databases, object storage). Those extras are why the VPS vs cloud article exists: you may stay on one VM and still use object storage for backups.

Cost is not the monthly invoice

Shared hosting looks cheap until you spend a week fighting a process limit. A VPS looks cheap until you count engineering hours for TLS, backups, and monitoring. Dedicated looks expensive until you compare it with a large memory-optimised VM that you resize every quarter.

Count:

• People time — who is on call, who documents DNS, who restores the database.
• Coupling — email on the same shared host as the website is a classic outage multiplier.
• Growth — vertical resize on a VPS is a reboot; on dedicated it may be a migration.
• Blast radius — one VPS can still hold production and staging if you were careless.

Use the website cost estimator for build cost; hosting is a separate line. The website launch checklist will remind you that DNS, TLS, and backups are not “the host’s problem” once you chose a VPS.

How to decide without a committee

Ask what must be true in twelve months:

1. Do we need a process the panel cannot run? If yes, leave shared hosting.
2. Do we have (or will we hire) someone to operate Linux? If no, buy managed hosting or a platform, not a naked VPS.
3. Is the bottleneck hardware or software? If software, dedicated will not save you.
4. What is the downtime budget? If you cannot afford a single-VM failure, you need redundancy and a tested failover — not a more expensive single machine. Check the uptime math first.

Many Palmate projects land on a VPS with Docker Compose, a reverse proxy, off-site backups, and a staging twin. That pattern is described in the containerised VPS sample. It is not a claim that every business needs metal, and it is not a claim that shared hosting is obsolete.

A note on “unlimited”

Unlimited bandwidth, unlimited sites, and unlimited inodes are marketing. Disk fills. CPU is shared. Email reputation is shared on cheap hosts. Read the acceptable use policy. If your business depends on sending mail, separate transactional email from the web host early.

Takeaway

Shared hosting sells operations. A VPS sells control. Dedicated sells isolation and hardware. Choose the model whose failure modes you can explain to the person who will get the phone call. When you need that environment designed and documented rather than live-edited, cloud hosting and DevOps is the Palmate path; when the public site is the product, pair it with web development so the app and the host are specified together.