TL;DR

• Both xpander.ai and kagent can keep agent execution, data, and credentials inside your infrastructure. xpander provides a managed control plane with a self-hosted data plane, while kagent provides an open-source Kubernetes runtime.

• xpander ships its data plane through one Helm chart with single-vendor support. kagent is an Apache 2.0 CNCF Sandbox project, and its open-source installation includes no commercial support or SLA.

• Choose kagent if you have deep Kubernetes and AI infrastructure expertise and can own integration, hardening, upgrades, and on-call support. Choose xpander if you need private-cloud or on-premise residency without creating another internal infrastructure project or negotiating separate support.

Why self-hosting Kubernetes agents is the real question here

Keeping agent execution, credentials, and sensitive data inside your infrastructure sets the baseline for both products. The useful comparison starts with what you receive on day one and who owns failures, upgrades, and security fixes after deployment.

xpander.ai is an enterprise AI agent development platform with a supported self-hosted data plane for Kubernetes. Its task execution engine runs agents inside the customer environment while xpander manages selected control-plane functions. kagent is an Apache 2.0 Kubernetes-native agent runtime that represents agents as custom resources and fits established GitOps practices. The project currently sits in the CNCF Sandbox stage.

You should therefore compare each product’s deployment boundaries and operating model. xpander provides a defined vendor-supported path, while the open-source kagent runtime leaves production integration and ongoing operations with your engineers unless you purchase separate commercial support.

Snapshot: xpander vs kagent for self-hosted deployment

The comparison gives the most weight to accountable support because production self-hosting requires security updates, upgrade planning, and incident response. Architecture clarity and explicit data residency boundaries follow. Feature breadth carries less weight because both options provide credible Kubernetes agent capabilities.

How xpander's self-hosted architecture works

xpander.ai separates management functions from agent execution through a control plane and data plane. The control plane remains in xpander Cloud, where it handles agent registration and connector definitions. The data plane runs inside your Kubernetes cluster and executes the agents within your VPC.

A single Helm chart installs the full data plane. The chart includes the Agent Controller and Agent Worker for execution. It also deploys the API, API Proxy, MCP service, Chat UI, Code Runner, AWS Operator, Postgres, and Redis. You do not need to package these services or combine independently maintained distributions.

The customer cluster initiates every connection to xpander Cloud. xpander Cloud has no inbound network path into the cluster. You can route outbound traffic through AWS PrivateLink or public TLS, depending on your network requirements. The outbound-only model lets your security team apply egress controls without opening the Kubernetes environment to vendor-initiated connections.

Agent operating data remains inside the VPC. Chat threads, activity views, debugging and monitoring data, and knowledge base storage do not leave customer infrastructure. xpander Cloud receives user identity and login information along with agent metadata, which supports authentication and control-plane management. The documented split gives you a specific residency boundary to review instead of a general claim that customer data stays private.

Deployment follows a defined sequence. You prepare the Kubernetes cluster, configure PrivateLink or public TLS connectivity, install the Helm chart, and connect the required integrations. xpander supplies and supports the complete chart, so one vendor owns the deployment path and the interaction between its components. When an upgrade or runtime failure crosses service boundaries, you do not have to determine which independent project or distributor should handle it.

Air-gapped deployment for government and regulated environments

Outbound-only connectivity solves data residency for most enterprises, but some environments cannot allow any connection to the public internet at all. Government agencies, defense contractors, intelligence and classified networks, and regulated industries like banking, healthcare, and critical infrastructure often operate under rules that prohibit outbound traffic to any vendor cloud, full stop. PrivateLink and public TLS do not clear that bar because both still assume a live path out of the cluster.

xpander supports a fully air-gapped deployment for exactly this case. The complete data plane, Agent Controller, Agent Worker, API, API Proxy, MCP, Chat UI, Code Runner, AWS Operator, Postgres, and Redis, runs inside your network with zero connectivity to xpander Cloud. No metadata sync, no heartbeats, no outbound call of any kind. Agent execution, memory, credentials, and every byte of runtime data stay entirely inside your perimeter, disconnected from the internet by design rather than by policy.

This is the deployment model government and defense customers ask for by name, and it is why xpander gets evaluated in classified and air-gapped procurement processes where an open-source project with no vendor of record cannot. kagent's open-source core assumes a live cluster with normal outbound access to pull images, sync with LLM providers, and reach any commercial support tier. Getting kagent into a true air-gapped environment means building and maintaining that isolation yourself, on top of everything else self-hosting kagent already asks of your team. xpander ships air-gapped as a supported deployment path, not a custom project your engineers have to invent.

How kagent's Kubernetes-native model works

kagent treats AI agents as Kubernetes resources rather than workloads managed through a separate control plane. Each agent uses a Custom Resource Definition, or CRD, that describes its model, tools, and runtime configuration. You can store these definitions in Git, review changes through pull requests, and deploy them with kubectl or an existing GitOps controller. Platform engineers can apply the same versioning and rollout practices they already use for other Kubernetes workloads.

kagent leaves model and framework choices open. It supports providers including OpenAI, Anthropic, Google Gemini, Azure OpenAI, AWS Bedrock, Vertex AI, Ollama, and Hugging Face. You can build agents with LangGraph, CrewAI, Google ADK, or custom code. That flexibility lets you change a model provider or agent framework without replacing the Kubernetes runtime.

Standard protocols connect agents to tools and other agents. Model Context Protocol support lets an agent discover and call compatible tools. Agent-to-Agent support enables delegation across multi-agent applications, while OpenAI-compatible endpoints provide a familiar interface for clients. kagent can run with Istio or Ambient Mesh when you need encrypted service communication, access policies, and controlled outbound traffic.

kagent exposes operational data through tools that Kubernetes platform teams commonly use. OpenTelemetry records distributed traces across agent steps, while Prometheus metrics and structured logs feed existing monitoring systems. Postgres provides persistent storage without requiring a proprietary database.

Solo.io created kagent with engineering experience from Istio, and the project now operates under the CNCF as an Apache 2.0 open-source project. Its CNCF Sandbox status places it at the earliest of the foundation’s three maturity stages, before Incubating and Graduated. Sandbox status signals that CNCF has accepted the project into its ecosystem, but it does not certify production maturity or provide commercial support. The architecture still gives experienced Kubernetes operators a credible base for building agent infrastructure through familiar APIs and deployment practices.

The support and accountability gap

The open-source kagent runtime gives you no commercial SLA or vendor support by default. Community maintainers provide help through Discord, public RFCs, and community calls, but your engineers remain responsible for integration, security hardening, upgrades, incident response, and compatibility testing. A production outage therefore enters your own Kubernetes and AI infrastructure queue.

Solo.io addresses that gap through Kagent Enterprise, a separate commercial product that adds production identity, orchestration, and governance capabilities. kagent also lists third-party distributions that provide training and support. Either route requires another purchase and contract. A partner distribution also adds another vendor between your engineers and the project maintainers.

Solo.io has substantial backing and cloud-native experience. The company raised a $135 million Series C at an approximate $1 billion valuation in 2021. Solo.io built its primary business around application networking products such as Gloo and Istio, while Kagent Enterprise extends that portfolio into agent infrastructure. The relevant distinction concerns product ownership rather than funding. Solo.io sells production support separately from the open-source kagent runtime.

xpander.ai treats self-hosted agent infrastructure as a supported deployment path within its enterprise agent platform. One vendor supplies the Helm chart, supports the components running inside your VPC, and remains accountable for the deployment as a whole. You do not need to assemble a support arrangement after installing the software.

For buyers that require contractual accountability, xpander provides the clearer operating model. kagent can still work in production when your engineers have the capacity to own it or when you add Kagent Enterprise or a partner distribution. The cost comparison must therefore include internal engineering and on-call work or the separate commercial support agreement, rather than treating the Apache 2.0 runtime as costless production infrastructure.

Which one should your team run

Choose kagent if your team has deep Kubernetes and AI infrastructure expertise and wants direct control over the runtime. Your engineers must be prepared to handle integration, security hardening, upgrades, and incidents themselves. If you later need an SLA or vendor support, you will need a separate Kagent Enterprise or partner agreement.

Choose xpander.ai if you need private-cloud or on-premise residency without creating another infrastructure project. xpander provides a supported self-hosted deployment under one vendor relationship, so your team can operate agents inside its own environment while xpander remains accountable for the platform.

Your decision determines who owns the operational burden. kagent favors engineering ownership now, with commercial support added separately if needed. xpander favors vendor accountability as part of the self-hosted deployment path.

FAQs

Is kagent production-ready as installed?

The open-source runtime provides credible Kubernetes-native foundations, but it includes no commercial SLA or vendor support. You must handle integration, security hardening, upgrades, and incident response yourself. Kagent Enterprise or a partner distribution can cover some of those responsibilities.

What does CNCF Sandbox status mean?

Sandbox is the earliest CNCF maturity stage, below Incubating and Graduated. The designation gives kagent a neutral governance home but does not certify production readiness. You should evaluate project stability and operational risk independently.

Does xpander’s cloud control plane touch customer data?

xpander Cloud stores user identity, login information, agent registration, and agent metadata. Chat threads, knowledge bases, activity views, and debugging data remain inside your VPC. You can keep operational agent data within your infrastructure while using the hosted control plane.

What does outbound-only connectivity provide?

Outbound-only connectivity prevents xpander Cloud from initiating connections into your cluster. Your data plane reaches approved external endpoints through PrivateLink or public TLS. Security teams can avoid exposing an inbound management path through the network perimeter.

Can you add commercial support to open-source kagent?

Solo.io and third-party partners offer paid products or distributions around kagent’s open-source core. Those options require a separate vendor evaluation and contract, unlike xpander’s supported self-hosted deployment. You can obtain support, but you must define responsibility across the resulting vendor stack.