Skip to content
MSP SERVER HOSTING

Independent reference for managed service providers

Server hosting designed around how MSPs actually operate.

Multi-tenant estates fail differently from single-business infrastructure. This is how to structure isolation, backup and margin when your clients share your platform.

Build a requirements profile How to get in touch

The planner runs in your browser and sends nothing anywhere. This site sells no hosting.

Illustrative model · not telemetry Isometric illustration of a multi-tenant hosting platformFour tenants sit on one shared compute platform, each inside its own boundary. A new tenant is provisioned and its boundary forms. One tenant then pushes its load up to the ceiling of its boundary and is contained while the other three stay level. A separate backup target sits on its own platform, fed by a continuous stream. Illustrative only.tnt-01tnt-02tnt-03tnt-03at its cap,limit enforcedtnt-04 · reservedtnt-04 · provisioningtnt-04 · provisionedSHARED COMPUTEone platform, many tenantsBACKUP TARGETseparate failure domain
  • Tenant inside its boundary and cap
  • Tenant at its cap, contained
  • Backup copies in a separate failure domain
A new tenant is provisioned and its boundary forms. Later one tenant stacks load up to the ceiling of its boundary, which here stands for an enforced cap or reservation, and presses on the wall; the limit holds while the other three stay level. Without an enforced cap, a neighbour’s burst would not be contained. Backup streams from every tenant to a target on separate infrastructure. An illustration of the isolation property, not telemetry from a real system.
Exploded view of four platform layersFour stacked planes: isolation boundaries on top, then compute, storage and networking. The same four tenant footprints appear on every plane and one tenant column is highlighted through all of them, showing that isolation has to hold at every layer. Illustrative only.ISOLATIONCOMPUTESTORAGENETWORK
The same four tenant footprints on every plane. The amber column is one tenant: isolation has to hold at every layer it touches, not only the top one. Illustrative, not a real system. Not drawn: the management plane (RMM, hypervisor consoles, credentials) and backup, which cut across every plane; the ledger below covers both, because one compromised console reaches every tenant at once.

The platform, layer by layer

What the tenants share, and how each layer fails

Isolation is not one switch. It is a stack of boundaries, and a multi-tenant platform is only as separate as its weakest layer. The ledger below is the checklist the rest of the site expands.

  1. Isolation

    The boundary around each tenant: hypervisor, container or dedicated hardware, and what each one does not contain.

  2. Compute

    CPU, memory and scheduler on common hosts.

  3. Storage

    Arrays, pools, caches and queues.

  4. Network

    Switches, uplinks, firewalls and address space.

The ledger: what is shared and how it fails

LayerWhat is sharedHow it failsRead
ComputeCPU, memory and scheduler on common hostsOne tenant bursts and starves the rest (noisy neighbour)Virtual servers
StorageArrays, pools, caches, queuesLatency rises for everyone when one workload saturates the poolPrivate cloud
NetworkSwitches, uplinks, firewalls, address spaceOverlapping ranges, a flat management network, a mis-tagged VLANPrivate cloud
Management planeRMM, PSA, hypervisor consoles, admin credentialsOne compromised console reaches every tenant at onceDedicated hosting
BackupRepositories, schedules, retention, keysBackups share the failure domain, or the credentials, of productionBackup and recovery
CommercialCost, margin, contract termsUnmetered tenants erode margin; weak exit terms trap youHosting economics

Reading path

Read in the order the decisions arrive

Eight articles, ordered the way an MSP meets the decisions: boundary first, exit and migration last.

  1. Multi-tenant isolation

    Pick the boundary type per tenant: hypervisor, container or dedicated hardware, and what each one does not contain.

  2. Virtual servers and capacity

    Size hosts from measured peaks, decide on overcommit, and keep failure headroom.

  3. Private cloud and network design

    Segmentation, address planning, out-of-band management and failure domains.

  4. Dedicated hosting and your own tooling

    When whole machines make sense, and where to run the RMM, PSA and backup consoles.

  5. Backup and recovery

    Recovery objectives per tier, independent copies, and restores you have actually rehearsed.

  6. Hosting economics

    How to structure a cost model without borrowing anyone else’s numbers.

  7. Evaluating a hosting provider

    Questions, evidence to request, and the contract terms that decide your exit.

  8. Migration and tenant onboarding

    Moving a client onto the platform in waves, with a rollback you can actually use.

Requirements planner

A requirements profile to take to suppliers

The planner turns tenant count, workload mix, recovery objectives, compliance pressure, growth and support model into a written profile: the isolation model to ask for, the headroom reasoning, backup and recovery design considerations, network and monitoring concerns, and the questions a provider should be able to answer.

It is a rule-based worksheet. It names no supplier, quotes no price and measures nothing about your systems. Open the requirements planner or read the requirements worksheet first.

Scope

What this site is, and is not

MSP Server Hosting is an independent reference written for the provider side of the relationship: the people deciding where client workloads run and how the hosting line earns its keep. It is not a hosting provider. It operates no data centres, sells no capacity, and publishes no prices, uptime figures, service levels or certifications, because it has none to publish. Where a commercial figure depends on your supplier, the text says it is unknown and tells you what to ask.

  • Data centres
  • Capacity for sale
  • Prices
  • Uptime figures
  • Service levels
  • Certifications