Managed MCP Server Hosting With Isolation Between Tenants

Host every tenant's MCP server in its own Firecracker microVM with its own guest kernel. CreateOS Sandbox puts each tenant on a machine no other tenant can see, enforces your egress rules from the host kernel, keeps each tenant's network private, and bills per second. You bring the servers. The isolation is already built.

Why Tenant Isolation Is the Whole Problem

An MCP server (Model Context Protocol) is a program agents call to reach tools and data. Host servers for many tenants and each one holds that tenant's credentials, data, and tool access. Put them in a shared process or a shared container and they share a kernel. One compromised tenant becomes a path to every other tenant.

This post covers the isolation half of managed MCP hosting. Who may call a server is an identity question, and we take that angle separately in deploying a remote MCP server behind your SSO. What a tenant's server can touch once it runs is a machine-boundary question. That is the one a shared host gets wrong.

The Short Version

One Firecracker microVM per tenant, each with its own guest kernel. Isolation is the default state, not a setting someone has to remember.
Egress rules are enforced in the host kernel with eBPF, outside the guest, so code inside cannot rewrite or route around them. Outbound is open until you set a rule. Inbound is closed either way.
Private overlay networks with per-network DNS let each tenant's servers find each other by name and stay invisible to every other tenant.
Pause takes about 1.4 s and stops the meter. Same-host resume is under 0.7 s. Billing is per second with $0 egress.
Self-serve start: SDK, CLI, and MCP on one API, with 500 free credits.

Why a MicroVM Per Tenant Fits MCP Hosting

An MCP server is not a build job that ends. It runs for months, holds live credentials, and answers calls from agents nobody fully controls. The failure mode to design against is lateral movement: tenant A's server reaching tenant B's data.

A container shares the host kernel with everything else on that host. A sandbox does not. Every CreateOS Sandbox is a Firecracker microVM with its own guest kernel, so the boundary sits at the machine, below anything the code inside can touch. That is the property you want when the code on the machine belongs to your customers.

Running this yourself means operating Firecracker, snapshot stores, eBPF programs, and host patching. CreateOS runs that host layer and exposes one API. When a tenant's contract says the workload stays on your infrastructure, the same API runs on your machines through bring-your-own compute.

Isolation alone is table stakes. Every vendor claims a VM. The combination is what holds for multi-tenant hosting: per-VM kernel isolation, egress enforced outside the guest, networks that keep tenants apart, and self-hosting when data cannot leave your boundary.

The Controls That Separate Tenants

A machine per tenant, sized like a server. Shapes run from a quarter CPU up to 8 CPU and 16 GB of memory, with 10 to 60 GB of disk. Bring your own Dockerfile to ship the MCP server image you already have, and each sandbox gets a live web URL for anything running, so an MCP client has an address to call.

Egress enforced where the code cannot reach. Outbound access is open until you set at least one rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest, so it holds even against a full guest compromise. Rules take a host, a host:port, wildcard subdomains, IPs, and CIDRs. Set them in the egress field at create time, through PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or createos sandbox firewall set on the CLI. The docs cover each mechanism. Inbound is closed by default no matter what you set.

Networks that keep tenants apart. Attach sandboxes to private overlay networks with per-network private DNS. One tenant's fleet talks by name with no public exposure. Traffic between networks is denied by default, so tenant A's servers and tenant B's servers cannot route at each other.

A lifecycle that matches MCP traffic. MCP servers idle between calls. Pause writes a snapshot of the full machine in about 1.4 s and stops compute billing. Same-host resume is under 0.7 s. A cross-host cold start runs 11 to 13 s. Auto-resume triggers on ingress HTTP only, and the idle timeout is configurable. Fork branches a paused server's memory and disk, which is how you test an upgrade against a copy of a tenant's state.

What Is Proven and What Is Young

The scale is real: 2.6 million sandboxes created since June 2026, and CreateOS's own CI has run on sandboxes since July 2026. Uptime is 99%+. The infrastructure company behind CreateOS, NodeOps, has operated production infrastructure since December 2023. Traces and usage dashboards are live, so per-sandbox usage is visible while it runs.

The young parts, said plainly: compliance certifications are on the roadmap, not shipped, for the Sandbox surface. There are no GPU sandboxes. If your security review requires a held certification today, treat that as a gap on this surface and plan for it.

What to Check Before You Move Tenants In

Set the egress allowlist at create time. Outbound is open until a rule exists. The locked-down network you assumed is what you get only after you set it.
Cross-host resume runs 11 to 13 s. If your client timeouts are tight, tune the idle window or keep the server warm.
Auto-resume triggers on ingress HTTP only. Other protocols need an explicit resume call.
No GPUs. A tenant's server that needs one needs another home.
Self-hosting covers the control plane and storage. Full air-gap is not available today.
Cost scales on concurrency, not unit price: per-second billing, $0 egress, pause stops the meter. The Sandbox pricing page publishes the table.

Frequently Asked Questions

Is one microVM per tenant wasteful next to shared containers?

A container shares the host kernel with every other workload on it. A sandbox is a Firecracker microVM with its own guest kernel, so the boundary is the machine, not a namespace. Shapes start at a quarter CPU, and a paused server stops drawing compute entirely.

Is outbound access locked down by default?

No. Outbound is open until you set at least one rule. Once a rule exists, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default either way. Rules go in through the create-time field, a live API update, the SDK, or the CLI.

What happens when an MCP server sits idle between calls?

Pause writes a snapshot of the full machine in about 1.4 s and stops compute billing. Resume on the same host is under 0.7 s. A cross-host cold start runs 11 to 13 s. Auto-resume triggers on ingress HTTP only, and the idle timeout is configurable.

Can one tenant's servers reach another tenant's?

Not by default. Sandboxes join private overlay networks with per-network private DNS, and traffic between networks is denied by default. Put each tenant's fleet on its own network and a shared internal tool on its own. Membership decides what can route where.

Where This Leaves You

Tenant isolation for hosted MCP servers is a machine-boundary decision. Containers share a kernel. Sandboxes do not. CreateOS Sandbox gives every tenant a Firecracker microVM of its own, egress enforced from the host kernel, private networks per tenant, and per-second billing that stops on pause.

Create an API key free at createos.sh and put your first tenant's server on its own machine today. Five hundred credits come with a new account.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.