Kubernetes support is currently in early access. To get on the list, book a demo call with the Tembo team: Book a Demo
How it works
Tembo on Kubernetes has three layers:
You install the platform once. The agent layer adds hosts as your workload grows. See How it works for the services in your cluster, and Agent hosts for the agent layer.
Agent hosts
You describe the agent hosts you want in your Helm values, and the controller runs them. If you’ve used Karpenter or the GitHub Actions Runner Controller, the model will feel familiar. The controller:- Scales on demand. It launches hosts as sessions need room, within the limits you set. Removing idle hosts is coming.
- Joins hosts automatically. New hosts register with your Tembo installation.
- Replaces hosts that fail to start. A host that doesn’t register in time is replaced.
Supported providers
Configured as code
Everything about your deployment lives in files you can review, version and promote between environments:- Helm values: domain, ingress, TLS, images, and whether to use the bundled database and cache or bring your own.
- Agent hosts: instance types, network placement and scaling limits.
- Terraform: the cloud permissions and object storage, from Tembo’s module.
helm upgrade in CI or a GitOps tool.
Security
- Runs in your account. The platform, agent hosts and session data all stay in infrastructure you own.
- VM isolation for agents. Each session runs in its own virtual machine with its own kernel, separate from your cluster.
- No privileged pods. The chart doesn’t need host access, privileged containers or special node configuration.
- Least-privilege cloud access. The controller only manages resources it created and tagged.