Push your AI agents from pilot to production with Kubernetes
Kubernetes is an ideal control plane for enterprises that want to securely run and manage MCP servers and AI agents on their existing infrastructure.
Landing pages like this are supposed to have one call to action. Sorry, we have two. You can either:
Talk directly with our CEO, Craig and/or our CTO, Joe
Craig McLuckie and Joe Beda are co-creators of Kubernetes (and Google Compute Engine, and the CNCF and more).
They’re also incredibly down-to-Earth and love to geek out on Kubernetes, MCP and agentic workflows.
If you’re trying to figure out how to connect Kubernetes and your AI initiatives, just fill in the form below and we’ll arrange time to talk.
Read more about running MCP on Kubernetes
Sure, we wrote the code behind Kubernetes. Now, we’ve written the guide on how to run MCP servers on Kubernetes.
It turns out that Kubernetes can streamline isolation, observability, authentication and more for MCP servers.
If you’re looking to dig in on your own for now, our How-to Run AI Agents on Kubernetes guide covers the core principles and steps to start down the path.
We’re proving Kubernetes is an ideal control plane for MCP servers now and AI agents next:
Our users make 4M tool calls every month (doubling every month)
Our Kubernetes operator is in production at multiple Global 2000 firms
Our open source platform, ToolHive has external maintainers and a growing community of contributors
Frequently asked questions
Kubernetes provides the scheduling, isolation, identity, and observability primitives that MCP servers require at enterprise scale. Container isolation maps directly to MCP’s per-server trust boundaries. RBAC and namespace policies enforce which agents can reach which tools. Kubernetes-native secrets management eliminates locally stored credentials. And the declarative resource model means MCP server deployments can be version-controlled, audited, and rolled back like any other infrastructure.
Local MCP server processes tie tool availability to individual developer machines, create inconsistent environments, and leave credentials in plaintext config files with no central audit trail. Running MCP servers on Kubernetes gives platform teams centralized control: containers are isolated by default, per-request identity is enforced via OIDC, and every server is deployed from a curated, signed registry rather than ad-hoc developer installs. Stacklok’s Kubernetes Operator manages this lifecycle declaratively, using CRDs that integrate with existing GitOps pipelines.
Stacklok can run in standalone mode for individual developers or small teams without Kubernetes. The full enterprise feature set, including centralized policy enforcement, multi-tenant isolation, GitOps-based CRD deployment, the enterprise registry, and observability integration, requires a Kubernetes deployment. Organizations evaluating Stacklok for production at scale should plan for a Kubernetes-native architecture from the start. Documentation is available at docs.stacklok.com.
Stacklok’s Portal and Registry Server components allow platform administrators to curate a trusted catalog of approved MCP servers. Developers discover and deploy only from that catalog; arbitrary servers cannot be installed outside of it. Policies are deployed as Kubernetes CRDs through existing CI/CD pipelines, which means enforcement integrates with GitOps workflows rather than requiring a separate policy sidecar or manual approval process.
Stacklok’s embedded authorization server handles per-request identity using OIDC and OAuth 2.0. Agents running on Kubernetes do not store credentials locally. Stacklok injects short-lived tokens at request time. This architecture is compatible with enterprise identity providers including Okta, Microsoft Entra ID, and Google Workspace. As of April 2026, Stacklok supports SSO federation without requiring individual agents to manage credential rotation.