How to Host an MCP Server Agents Can Reach Without Exposing It to the Public Internet

Run the MCP server inside a Firecracker microVM sandbox on a private overlay network with per-network private DNS. Agents reach it by name over that network, inbound stays closed to the public internet by default, and a host-kernel egress allowlist controls what the server can call. Pause stops the meter while it waits.

Introduction

An MCP server is a strange kind of service. It is not a website that needs traffic from everywhere. It serves a known set of agents, often ones you wrote or approved, and it often holds credentials, database handles, or internal tools on the other side of every tool call. Yet the default way teams expose one is a public endpoint with a token in front of it, which means every scanner on the internet can knock on the door and every misconfiguration is reachable.

The question worth asking is different: can an agent reach the server without the server being publicly addressable at all? With CreateOS Sandbox, the answer is yes. Each MCP server runs in its own microVM, agents connect over private overlay networks with private DNS, and the public internet has no route in. This piece walks through how that works, what it costs, and what to check before you move your servers over.

Key Takeaways

Inbound is closed by default on every sandbox. A private overlay network with per-network private DNS lets agents reach your MCP server by name with no public exposure.
Outbound is open until you set at least one egress rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.
MCP traffic is idle-heavy. Pause snapshots the machine in about 1.4 s and stops compute billing; same-host resume is under 0.7 s.
The same API runs on your own machines, with your own S3, R2, or MinIO bucket, when the server must stay inside your boundary.
Per-second billing, $0 egress, and 500 free credits make the first server cheap to try.

Why a Private Network Beats a Public Endpoint for MCP

A public endpoint plus an API key is one failure away from a compromised tool server. The key leaks, the endpoint is scanned, and whatever the MCP server can reach is now reachable by whoever holds the key. The constraint is not authentication. It is addressability.

Private networking removes the addressability problem. Sandboxes attach to private overlay networks, each with its own private DNS. Your agents resolve the MCP server by name inside that network. Traffic between different networks is denied by default, so one tenant's servers and another tenant's servers cannot route at each other. Nothing needs a public IP, so nothing gets scanned.

This is the same isolation model CreateOS Sandbox applies to untrusted code: every sandbox is a Firecracker microVM with its own guest kernel, not a shared-kernel container. The product page describes the full picture, and the docs cover the networking setup in detail.

What the Server Gets: Isolation, Egress Control, and a Lifecycle That Fits MCP

A machine per server. Each MCP server runs in its own microVM with its own guest kernel. A compromised session hits a machine boundary, not your host or your other tenants.

Egress you govern, enforced outside the guest. 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 VM, so code inside cannot rewrite or route around it. The rules survive a full guest compromise. Rules take a host, 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. For an MCP server that talks to exactly one database and one API, that allowlist is a short list.

A lifecycle that matches idle-heavy traffic. MCP servers spend most of their time waiting 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 before touching the real one.

Your boundary when it must be yours. The same API runs on customer machines through bring-your-own compute, with your own S3, R2, or MinIO bucket underneath. When the MCP server fronts data that cannot leave your VPC, it does not have to.

The Numbers Behind It

The scale is real: 2.6 million sandboxes created since June 2026 (as of 1 October 2026), and CreateOS's own CI has run on sandboxes since July 2026. 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 the server runs.

Where compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

The young parts, said plainly: there are no GPU sandboxes. If a tenant's MCP server needs one, plan for another home for that piece.

Pricing is published: per-second billing, $0 egress, shapes from a quarter CPU up to 8 CPUs with 16 GB of RAM, and 10 to 60 GB of disk. New accounts start with 500 free credits, which is enough to stand up a server, wire an agent to it, and measure the idle-resume pattern before spending anything.

What to Check Before You Move Your MCP Servers

How agents authenticate to the server. Private reachability is not authorization. Keep your tool-level auth; the network removes scanning, not the need for identity.
The egress default. Outbound is open until the first rule exists. Write the allowlist into provisioning, not into a follow-up ticket.
Resume latency tolerance. If an agent cannot tolerate an 11 to 13 s cross-host cold start, keep sessions warm on one host or accept the pause-first pattern.
GPU needs. None today. Plan around it.
Self-host requirements. If the server must run on your hardware, confirm bring-your-own compute covers your topology before committing.

Start free at createos.sh, or read the deeper guide on managed MCP server hosting with isolation between tenants if multi-tenant isolation is your case.

Frequently Asked Questions

Can agents reach my MCP server without any public endpoint?

Yes. Attach the server's sandbox and the agents' sandboxes to the same private overlay network. Per-network private DNS resolves the server by name inside the network. Inbound from the public internet is closed by default regardless of your egress settings.

What can the MCP server itself reach on the internet?

Whatever your egress allowlist permits, once you set one. Outbound is open until the first rule exists; after that, everything else is denied. Enforcement sits in the host kernel with eBPF, outside the guest, so the server's own code cannot rewrite the rules.

What happens when no agent is calling the server?

Pause takes about 1.4 s, writes a full memory and disk snapshot, and stops compute billing. Same-host resume is under 0.7 s. Auto-resume triggers on ingress HTTP only, so the next tool call wakes the server.

Can this run inside our own VPC?

Yes. Bring-your-own compute runs the same API on machines you provision, with your own S3, R2, or MinIO bucket for storage, so the MCP server and the data behind it stay inside your boundary.

Conclusion

Hosting an MCP server securely is mostly a networking question. If the server has no public address, nobody can scan it, and the security review shrinks to the controls that remain: which agents reach it, and what it can reach. CreateOS Sandbox gives you the private network, the per-VM isolation, the host-enforced egress allowlist, and a pause-resume lifecycle that stops the meter while the server waits. Spin up the first one with 500 free credits and see how little surface is left.

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.