This guide covers everything needed to deploy xpander.ai onto your Kubernetes cluster — SSL certificates, ingress controller, Helm chart installation, DNS configuration, API key management, verification, and SDK setup.
Before you start, ensure you have:
A running Kubernetes cluster (see EKS Cluster Setup if you need one)
URL (optional): Your server’s FQDN (e.g., xpander.my-company.com)
Use dash-based subdomains: Enable if your DNS uses chat-xpander.domain.com format instead of chat.xpander.domain.com
Click “Continue to connect location”
The platform will generate your Helm installation commands with all required keys — including your organizationId, environmentId, and deploymentManagerApiKey.After deployment, the location page shows a Components tab with heartbeat status for each service, and a Configuration panel where you can toggle Cloud Controls (Chat, Streaming, Scheduler).
The xpander services (agent controller, chat UI, API, etc.) communicate with each other internally via Kubernetes Services — no ingress is needed for that. You only need external access so that users can reach the chat UI, API, and other endpoints from their browser or client.
If your organization has a VPN that routes into the VPC, users can access xpander services directly — no ingress controller, NLB, ACM certificate, or public DNS needed.Point internal DNS records to the Kubernetes services:
The certificate must include a wildcard for *.chat.<DOMAIN> because the xpander chat UI generates per-thread subdomains (e.g., moccasin-prawn.chat.<DOMAIN>). Standard wildcards only match one level, so *.<DOMAIN> does not cover these. If you omit *.chat.<DOMAIN>, the chat UI will show SSL certificate errors for thread URLs.
Add the DNS validation CNAME records to your Route 53 hosted zone. There will be two unique validation records — one for <DOMAIN> / *.<DOMAIN> (shared) and one for *.chat.<DOMAIN>:
Create wildcard CNAME records pointing *.<DOMAIN> and *.chat.<DOMAIN> to the NLB hostname. Both are required — the chat UI generates per-thread subdomains under chat.<DOMAIN>.
After the upgrade, pods that use the updated secrets will automatically restart. Verify with:
Copy
Ask AI
kubectl get pods -n xpander
Secret not updating after helm upgrade?
The xpander-static secret has a Helm resource keep policy — helm upgrade may not update it on subsequent installs. If your API key isn’t being picked up after a helm upgrade, set it directly in the secret:
Copy
Ask AI
# Set the key directly in the Kubernetes secretkubectl patch secret xpander-static -n xpander --type=merge \ -p "{\"data\":{\"ANTHROPIC_API_KEY\":\"$(echo -n '<YOUR_KEY>' | base64)\"}}"# Restart the worker to pick up the new keykubectl rollout restart deployment xpander-agent-worker -n xpander
from xpander_sdk import Backend, Configurationfrom agno.agent import Agentconfig = Configuration( api_key="your-agent-controller-api-key", # From Helm installation organization_id="your-org-id", base_url="https://agent-controller.my-company.com")backend = Backend(configuration=config)agno_agent = Agent(**backend.get_args(agent_id="agent-123"))result = await agno_agent.arun(input="What can you help me with?")
Make sure your base_url points to the Agent Controller endpoint (e.g., https://agent-controller.{your-domain}), not the root domain.For more SDK examples, see the Self-Hosted SDK Configuration.