Dedicated hosting for MSPs: when whole machines pay off

Who this is for. MSP owners and technical directors weighing dedicated servers against shared virtualisation for client workloads, and anyone deciding whether to self-host the management tooling that runs the business. The two questions are linked: the tooling is the one workload that every other tenant depends on.

What “dedicated” does and does not mean

A dedicated server is a physical machine allocated to one customer. Dedicated hosting usually means someone else owns and racks that machine and you rent it, as opposed to colocation, where you own the hardware and rent space, power and connectivity. The word says nothing about who runs the operating system. Before comparing options, write down the responsibility line: who patches firmware, who swaps a failed disk, who runs the hypervisor, who monitors the hardware, who is paged at 03:00.

Dedicated is also a layer you often combine with others. A common MSP pattern is a handful of dedicated hosts running a hypervisor, on which you build your own multi-tenant platform. Another is dedicated hardware only for the tenants whose requirements demand it. In both, “dedicated” describes the hardware boundary, and everything in multi-tenant isolation still applies on top of it.

When whole machines earn their cost

Dedicated capacity is rarely the cheapest way to run a small workload. It earns its place in a few situations:

Compliance scope. A tenant whose contract or regulator expects no shared hardware, or whose auditors find the shared-hypervisor argument harder to evidence than a physical boundary.
Neighbour-sensitive workloads. Databases or latency-critical applications whose performance you cannot protect with caps on a shared pool.
Licensing. Some software is licensed by physical host or by processor core, so where the workload runs changes the licence count. Microsoft software hosted for customers by a service provider is normally licensed through a provider licensing programme with its own reporting; the terms, minimums and definitions change between versions, so verify current terms in writing before you size anything around them.
Specialised hardware. GPUs, high-speed local flash or specific network adapters that a shared platform does not offer.
Steady, predictable load. A workload that is flat and busy all day gets little benefit from the statistical sharing that makes virtualisation cheap.
Your management plane. Discussed below, and the strongest case of all.

If none of these apply, a shared platform with enforced limits is the better default, and you can keep the option to move a tenant to dedicated capacity later. Design for that move by keeping tenant workloads portable (see migration).

Who does what: drawing the responsibility line

Suppliers use the same words for quite different arrangements, so compare them by tasks rather than by label. For each task below, write down whether the supplier, you, or nobody currently owns it.

Task	Rented dedicated server	Colocation of your own hardware	Provider-managed dedicated host
Replace failed disks, memory or power supplies	Supplier, within their stated process	You, or paid remote hands	Supplier
Firmware and BMC patching	Often you; confirm	You	Supplier, with a maintenance window
Hypervisor and operating system patching	You	You	Depends on the contract
Hardware monitoring and alerts	Mixed; confirm what you receive	You	Supplier, with alerts passed to you
Spares and replacement lead time	Supplier’s stock	Yours to hold	Supplier
Network and power redundancy	Supplier’s design	Facility’s design plus yours	Supplier

The cells show common arrangements, not guarantees; the contract decides. The row that most often surprises MSPs is firmware: if nobody owns it, it does not get done, and unpatched baseboard controllers and storage firmware are exactly the kind of gap that accumulates unnoticed. Ask for the replacement process in writing, including how long a failed component typically takes to be replaced and what happens to your workloads meanwhile.

Self-hosted versus vendor-hosted tooling

Your RMM, PSA (ticketing and billing), documentation system and backup console are the nerve centre of an MSP. For each one you can use the vendor’s hosted service, or run it yourself. This is a risk and operations decision, not a cost one:

Factor	Vendor-hosted	Self-hosted
Who patches and secures the application	Vendor	You
Who is responsible when it is attacked	Shared, per the vendor’s terms	You, entirely
Control over data location and retention	Limited to the vendor’s options	Complete
Availability and recovery	Vendor’s design; read the actual terms	Yours to design, test and pay for
Customisation and integration	Within vendor limits	Wide
Your own staff load	Lower	Higher, including after-hours

Neither wins in general. Self-hosting gives control and takes responsibility with it. If you do self-host, treat the tooling as the most sensitive systems you own, because an attacker with the RMM can run code on every client machine. Incidents in which attackers abused or exploited management software to reach many downstream customers at once are well documented, and they are the model of failure to design against.

Placing the management plane

Whether you run it on dedicated hardware or on a virtualisation cluster, apply these rules:

Separate the management plane from tenant workloads. No tenant virtual machines on the hosts that run your RMM or backup console, and no tenant network path to them.
Separate identity. Administrative accounts for the management plane should not be the same accounts, or part of the same directory, that tenant environments authenticate against.
Minimise exposure. Agents have to reach the server, but administrators and agents do not have to reach the same interface. Where the product allows it, publish only the agent-facing endpoint to the internet, put it behind a reverse proxy or equivalent, and keep the administrative interface reachable only from restricted networks. Check your vendor’s documentation for which ports and paths each function uses.
Require strong multi-factor authentication for every operator, and use named accounts rather than shared logins.
Back it up differently. Back up the application database and configuration, not only the virtual machine, to a location that the management plane’s own credentials cannot delete.
Give it its own recovery plan with a tighter objective than any tenant. It is how you recover everyone else, and while it is down you are slower at every other incident.

Circular dependencies: the dependency you only discover during an outage

Management planes love to depend on themselves. A few well-known loops:

The domain controllers are virtual machines on a cluster whose hosts authenticate against that domain, so a cold start of the whole cluster waits for something that is not running.
The backup console, its repository and the VMs it protects share one storage array. When the array fails, you lose both the data and the means to restore it.
DNS, NTP and certificate services run on the platform they are needed to start.
The password vault holding the break-glass credentials lives behind the very identity provider that is down.

The cure is to enumerate dependencies explicitly and break the loops on purpose. Keep at least one independent source of time and name resolution. Keep break-glass local administrator access to hypervisors that does not depend on directory authentication, and store those credentials offline with a documented, audited procedure. Place the backup repository in a different failure domain from what it protects, and keep one restore path that does not need the production network.

Worked example: a layout, not a price list

Consider an MSP with a few dozen tenants and its own tooling. A defensible structure, described entirely in roles:

Two dedicated hosts form the management plane: RMM, PSA integration services, documentation, and the backup console. They sit in different failure domains (separate racks or, better, separate locations), with their own management network and their own administrator identities.
One or more tenant clusters run client workloads, separated by criticality so that a problem in the cluster for general workloads does not affect the cluster for tenants with strict recovery objectives.
A backup target in a third failure domain holds immutable copies of both planes, reachable with credentials that no production administrator holds.
A short runbook says, in order, how to bring each piece back from nothing, and who holds the break-glass access.

Nothing in that layout names a supplier or implies a cost. It is a shape to compare suppliers against.

Checks you can run on a self-hosted tool server

These are read-only and safe on a host you administer:

# What is listening on this machine, and under which process? Anything unexpected is a finding.
sudo ss -tlnp

# When does the certificate your agents trust expire? Replace the hostname with your own.
echo | openssl s_client -connect rmm.example.com:443 -servername rmm.example.com 2>/dev/null \
  | openssl x509 -noout -subject -enddate

An expired certificate on an agent-facing endpoint is a classic self-inflicted outage: agents stop checking in and nobody notices until the next incident.

Common mistakes

Running tenants and tooling on the same hosts because there is spare capacity. The spare capacity is the risk.
Backups of the tooling stored alongside it, protected by the tooling’s own credentials.
Assuming dedicated means isolated. A dedicated host still shares the network, the management plane and the staff who administer it.
Ignoring the operational load: firmware, hardware replacement and on-call all become yours.
No exit plan for a rented dedicated server: how do you get your data and configuration off it, and how quickly? See evaluating a hosting provider.

What to do next

List which tenants, if any, justify dedicated hardware, and write out the dependency map for your own management plane. The requirements planner will flag the dedicated and management-plane requirements your answers imply, and backup and recovery covers how to give the tooling its own recovery tier.