Skip to main content
xpander runs in one of three places. On xpander cloud there is nothing to deploy: agents run on xpander’s executors and Xpander Chat is chat.xpander.ai. The two self-hosted deployments put the runtime in your own cluster and are installed by the same one-line installer:
  • Hybrid (default): your data and agents run in your cluster, control plane in xpander cloud. The Agent Controller is the only cluster egress to Cloud: it pulls agent definitions and the skills catalog, and reports heartbeats (the heartbeat JSON schema is not published). Execution, runtime data, credentials, and model keys stay inside your VPC. See Hybrid Architecture.
  • Air-Gapped: every component runs in your environment with no connection to xpander cloud at run time. UI, database, and every xpander service live in your cluster; two sealed, signed Ed25519 license files enforce entitlement in-cluster, and images are pulled from your own registry mirror. Nothing is sent to xpander Cloud; every other connection is optional and yours (the egress table lists them). It installs in a cloud VPC in private mode (no internet or NAT gateways) or in any disconnected compute environment. See Air-Gapped Architecture.
The reference installations run on Amazon EKS, and the supporting guides below are written for AWS. Any Kubernetes 1.28 or later with a CNI, cluster DNS and a CSI driver that provides a default RWO StorageClass meets the chart’s requirements; no other distribution has a step-by-step guide here yet. In both self-hosted deployments, agents’ skill calls, including skills served over MCP, run from your cluster, and agent workspaces (the agents’ computers) run there too. MCP clients (Claude, ChatGPT or Cursor connecting to Omni, the built-in agent) are offered once the install sets its MCP origin, global.mcp.publicUrl; until then Settings > Channels lists MCP as not configured. In both self-hosted deployments, agents run on Claude Code, Codex or OpenCode, and their turns land on the executor fleet, a warm pool the chart always renders. Its sizing and node prerequisites are on Sizing and requirements.
The installer’s first question is which edition you are installing, and it walks you through the rest: run it from a terminal with kubectl access to the target cluster. Xpander Chat generates a personalized one-liner with everything filled in.

Hybrid deployment

The complete Hybrid guide: architecture, requirements, the installer wizard, PrivateLink, LLM keys, upgrades, troubleshooting

Air-gapped deployment

The complete Air-gapped guide: license, mirroring, the install pipeline, data tier, sign-in, upgrades, troubleshooting
Network boundary, identity, and what leaves each environment are on the architecture pages, one page per deployment:

Cloud Architecture

Hosted control plane and data plane

Hybrid Architecture

Data plane in your VPC; catalog and heartbeat sync to Cloud

Air-Gapped Architecture

Every component in your environment; nothing sent to xpander

Choosing a deployment

The full requirements are published as JSON at charts.xpander.ai/requirements.json. The installer shows the same numbers before it changes anything. Choose Hybrid when you need data residency (runtime data, credentials, and model keys inside your network) but are fine with xpander cloud managing agent definitions, identity, and the skills catalog. It is the smaller footprint and the default. See Hybrid Architecture. Choose Air-Gapped when xpander must run with zero dependency on xpander cloud: sealed or classified networks, strict egress policies, or full operational ownership. “Air-gapped” means air-gapped from xpander’s cloud: internet-backed skills can stay enabled or be sealed off, your choice. See Air-Gapped Architecture.

Supporting Guides

EKS Cluster Setup

Provision a new EKS cluster with VPC, IAM, nodes, and add-ons

AWS Operator Setup

IAM roles and Pod Identity for AWS skills

IAM Best Practices

Three-tier IAM role architecture for least privilege

Sizing and requirements

Base footprint per deployment, the workspace pod, the executor fleet, capacity planning