Shared, Reseller, VPS, Dedicated, and Colocation Hosting

People usually compare hosting plans by CPU, RAM, disk, and bandwidth. Those matter, but the difference I care about most is who's responsible for what. Every step from shared hosting down to colocation hands more of the stack to the customer, and a lot of support headaches come from nobody being clear about where that line is.

The responsibility ladder

Shared hostingThe provider runs almost everything.

Reseller hostingThe provider runs the platform; the reseller handles their own customers and packages.

Managed VPSThe provider runs virtualization plus an agreed slice of the OS and apps.

Unmanaged VPSThe provider runs virtualization; everything inside the VM is the customer's.

Dedicated serverThe provider handles the facility and hardware; the OS depends on the contract.

ColocationThe provider gives you space, power, cooling, and network. The hardware is yours.

Side by side

Model	Isolation	Provider handles	Customer handles	Good for
Shared	Per account	Server, control panel, web and mail stack, backups, patching	Their site, content, and account security	Small sites, people who don't want to run a server
Reseller	Several accounts under the reseller	Same as shared	Packages, their customers' support, billing, account settings	Designers, agencies, small IT shops
Managed VPS	VM or container	Hypervisor plus whatever management was agreed	Owning the app, and approving changes	Needs isolation but doesn't have an ops team
Unmanaged VPS	VM or container	Host, storage, network, virtualization	Guest OS, firewall, updates, services, and backups unless they buy them	People comfortable running Linux or Windows themselves
Dedicated	Physical server	Facility, network, power, hardware replacement	OS and apps, unless management is included	Steady performance, licensing, lots of storage, special hardware
Colocation	Your own hardware in their rack	Space, power, cooling, physical security, network handoff	Hardware, spares, OS, apps, lifecycle, and remote-hands requests	Wanting to own hardware without running a building

Shared hosting

Shared hosting is controlled multi-tenancy. Lots of accounts share one OS, web server, database server, and mail system. It works when accounts are properly isolated, noisy neighbors are kept in check, and the routine stuff is automated. When it doesn't work, everyone on the box feels it.

What you have to keep a handle on

Per-account limits: CPU, memory, processes, I/O, and entry processes
PHP versions and which apps need which
Mail reputation and outbound rate limits
File ownership and keeping accounts out of each other's stuff
Backup schedules and how customers restore
Malware, ancient CMS installs, and stolen passwords

The classic example: one hacked WordPress site starts sending spam, and now every customer sharing that outbound IP has a mail reputation problem. That's why shared hosting needs abuse controls at the application level, even though you didn't write any of the applications.

Reseller hosting

Reseller hosting puts a business layer on top of shared hosting. The reseller makes accounts and packages, but the platform underneath is still yours. Get these answered up front, in writing:

Does the reseller do first-line support for their customers?
Who deals with abuse complaints and legal requests?
Can the reseller oversell disk or bandwidth?
Who owns backups and restores?
What happens to all their customers' accounts if the reseller stops paying?

That last one is uncomfortable, but you really want to have decided it before it happens.

VPS

A VPS gives you a much stronger boundary. But "managed" and "unmanaged" are sales words, not technical ones. Two providers can both sell a "managed VPS" and mean completely different things. If you sell managed, spell it out:

Task	Included?	How fast	Notes
OS security updates	Say so explicitly	Routine or emergency	Include whether and when you'll reboot.
Control panel admin	Say so explicitly	Business hours or 24/7	Which panels you actually support.
Debugging their app	Usually limited	Best effort	You can prove the platform is healthy without fixing their custom code.
Watching backups	Different from storing backups	Daily	A backup product isn't done if nobody acts on failures.
Cleaning up a compromise	Often billable	Emergency	Say whether any forensics are included.

Dedicated servers

With dedicated, there's no hypervisor shared with anyone else, but now you're dealing with the hardware's whole life. You need to know what parts you have on the shelf, what can be swapped quickly, and what means migrating to a new box.

Questions beyond "which CPU?"

Are the boot drives mirrored?
Is the RAID controller's battery or cache module being monitored?
Is out-of-band management (iDRAC, iLO, IPMI) included, and is it isolated?
How fast can you replace RAM, drives, power supplies, or a motherboard?
Is this a standard build or a one-off?
What's the plan when the hardware gets too old?

Colocation

With colo, your responsibility drops down to the building. That sounds simpler, but now power density, cabling, access control, remote hands, and exactly where the network handoff is are the product.

Make the line visible

Provider responsibility                    Customer responsibility
-----------------------                    -----------------------
Rack / cabinet                             Server and storage hardware
Power circuits and metering                Power supplies and cords after handoff
Cooling and facility environment           Airflow inside the equipment
Cross-connect / switch port                Customer router, firewall, or NIC
Physical access control                    Equipment config and data
Optional remote hands                      Written instructions and spare parts

A colo customer should know whether their network handoff is an access VLAN, a tagged trunk, a routed subnet, or a point-to-point circuit. They should also know what remote hands will actually do: swap a drive? Hook up a crash cart? Move a cable? Or just look at the lights and tell you what color they are?

Picking the right one for someone

Start with their skills. Don't sell an unmanaged VPS to someone who can't run an OS just because it's cheap. You'll end up supporting it anyway.
Figure out how much isolation they need. Compliance, performance, software requirements, or mail reputation might mean their own VM or server.
Understand how they grow. Steady growth and spiky traffic might belong on different platforms.
Match what they expect for recovery. Someone who expects to be back up in minutes needs more than a nightly backup.
Price in the support. The cheapest infrastructure can easily become the most expensive product to support.

Product mistakes I'd avoid

"Unlimited"

Everything has limits. Use fair-use policies and real numbers instead of promising something you can't actually deliver.

Vague "managed"

"Managed" without a task list means every customer expects something different.

Backups as magic

Say how often, how long they're kept, what's excluded, how restores work, and whether the customer should keep their own copy too. (They should.)

One-off hardware

Custom builds can make money, but each one needs its own spare parts and replacement plan.