Your MCP gateway, registry and runtime belong on your own infrastructure

The most important decision you’ll make when scaling MCP usage across your organization is where you want the registry, runtime and gateway to run. Most MCP solutions are SaaS; that means they’re easy to set up, but also that data about your connections and calls is routed to a third-party. That’s simply not an option for many enterprises, and it’s why Stacklok built our MCP platform to be self-hosted. Stacklok installs on your existing Kubernetes infrastructure from one Helm chart. We operate nothing in the request path and hold none of your data. There is no SaaS or vendor-managed option, and that is a design decision rather than a gap we plan to close. Here’s the case for self-hosted vs. SaaS.

Everything an agent does passes through the gateway

An MCP gateway sits between AI clients and the systems they call. Every tool call crosses the gateway, along with the arguments, and the identity of the person behind the call. Turn on audit logging and the gateway records a structured event for every protocol operation, with the option to capture request and response payloads as well. Read in order, that log is a complete account of what your staff asked an AI to do with your internal systems, with names attached.

A SaaS gateway has to decrypt that traffic to route it, evaluate policy against it and log it. So the vendor’s infrastructure holds your prompts, your tool arguments and your backends’ responses, and their retention and access policies apply to data you would never otherwise let out.

When the gateway runs in your cluster, the same records go where your other services’ records already go. Audit events ship through Fluent Bit, Grafana Alloy or the OpenTelemetry Collector. Traces go to Jaeger or Azure Monitor over OTLP. Metrics sit on a Prometheus endpoint. There is no new party on the list of systems that hold your MCP traffic.

The registry is a control, so it belongs in your pipeline

The registry is your catalog of approved MCP servers. Approving a server is a governance act, and the cheapest governance is the review process you already run.

A self-hosted Registry Server can take its entries from a Git repository, in which each server is a file. A pull request adds or changes one, CI validates it against the published JSON Schema, and your existing code review is the approval gate. Pin the source to a branch, tag or commit and you decide how fast changes land. Nobody has to learn a new workflow to approve an MCP server.

The registry can also use your cluster as a source and create entries for MCP servers already running there, including the ones nobody registered. That only works when the registry can see inside your cluster, which a hosted registry cannot do without you opening a path in for it.

Ownership is enforced with claims. Each entry records the claims needed to publish it, and every later version has to carry the same claims as the first, so one team cannot quietly take over another team’s server. Those claims come from your identity provider, which is one more thing that stays on your side.

Isolation happens in the runtime, and the runtime is your cluster

A gateway that only brokers calls cannot isolate the servers behind it. Stacklok runs those servers; with our Kubernetes Operator, each MCP server gets its own container, an auto-generated ServiceAccount, and a namespace-scoped Role and RoleBinding, so every server holds a minimal and distinct permission set. The root filesystem is read-only by default. Outbound network access follows a permission profile with host and port allow-listing, enforced by an egress proxy (Squid by default, Envoy since v0.41.0). It is an explicit proxy, so a server that ignores it fails instead of being silently redirected. Secrets come from Kubernetes Secrets, External Secrets Operator or HashiCorp Vault and are never baked into images.

All of that is built from objects your platform team already manages: ServiceAccounts, RBAC, NetworkPolicy, your Vault. A vendor-hosted runtime would have to recreate each of them in someone else’s cluster and ask you to trust the copy.

What it costs you

You run PostgreSQL and Redis, and an embedding service if you turn on the tool optimizer. You decide their high-availability and persistence posture. Redis session state is not persistent by default, so if Redis restarts, sessions are lost and clients reinitialize. Installation is one umbrella Helm chart with preflight checks, artifacts are signed with cosign and ship with SBOMs, and the Enterprise build adds SLSA provenance and backported security patches.

That is the trade. Some operational work, in exchange for keeping the gateway, the catalog of approved servers, the servers themselves, and every record of what your agents did inside the perimeter you already defend.

If you are evaluating MCP gateways, your first questions should be: what runs where, and what does the vendor hold? The deployment model shapes every other answer, so settle it before you compare feature lists.