Self-hosted infrastructure for CI and AI agents
Kobe keeps Kubernetes clusters warm, leases one in about a second, and destroys and replaces it when the lease ends. Agent sandboxes get the same identity, limits, TTLs, and cleanup.
kubeconfig ready
exit=0 · released
Install the Kobe CLI
Install one signed binary, connect it to your self-hosted operator, then lease clusters or run agent sandboxes.
Kubernetes clusters on demand
Lease a ready cluster from a warm pool. Kobe writes the kubeconfig, enforces the TTL, and recycles the environment when you release it.
Sandboxes built for agents
Run an agent command in a bounded workspace without exposing the Kubernetes cluster underneath it. Kobe creates the sandbox, returns the command result, and releases it.
Warm. Lease. Use. Recycle.
Every cluster is used once. Kobe keeps the pool full, hands out ready clusters, and replaces each one after its lease, with policy and cleanup enforced for sandboxes too.
Keep a Warm Pool
A ClusterPool keeps ready clusters waiting, at a fixed size or autoscaled to a minimum. Administrators define SandboxPools with fixed resources and isolation.
Set Access Policy
Use OIDC, SSH, or tokens to grant each identity the right pools, TTL, concurrency, resources, and sandbox operations.
Lease in a Second
Take a ready cluster from the pool for CI or development, or a policy-controlled sandbox for an agent workload.
Recycle & Refill
Release it or let the TTL expire. Kobe revokes access, destroys the environment, verifies cleanup, and builds a fresh cluster to refill the pool.
A fleet layer for ephemeral workloads
Manage identity, capacity, isolation, and lifecycle for CI jobs, developer environments, and AI agents.
Ready Cluster Pools
Keep Kubernetes environments warm and lease them with the Kobe CLI for CI jobs and developer workflows.
Agent Sandbox Pools
Offer fixed, administrator-owned workspace templates. Callers choose a pool, TTL, and alias without injecting pod specs, mounts, or target credentials.
Policy-as-Code
AccessPolicy separates cluster and sandbox grants, including pool allowlists, verbs, TTLs, concurrency, and resource ceilings.
Placement & Isolation
Place sandboxes in the management cluster or a child-cluster pool. Sandboxes run on trusted runc today; gVisor and Kata tiers are planned.
Capacity Automation
Autoscale warm cluster capacity and restore configured k3s or k0s environments from Velero snapshots instead of rebuilding every lease.
Observable Lifecycle
Track capacity with Prometheus metrics, capture cluster diagnostics, and quarantine sandbox capacity when cleanup cannot be verified.
Choose a backend
Clusters run on nested k3s, the default, or k0s, upstream vcluster, or CAPI. Sandboxes run on Kubernetes Agent Sandbox. Leases come from warm pools, so a ready environment binds in about a second; provision time only applies when a pool builds a new instance.
k3s
★ defaultRuns lightweight, nested real clusters as StatefulSets for full Kubernetes API and node semantics.
k0s
productionRuns nested k0s clusters for workloads that need full Kubernetes fidelity or standardize on k0s.
vcluster
high densityRuns one upstream vcluster per pool instance for high-density environments with low per-cluster overhead.
CAPI
enterpriseDelegates provisioning to any Cluster API infrastructure provider for full lifecycle control.
Agent Sandbox
sandboxesRuns sandbox pools on Kubernetes Agent Sandbox v1.0.0. Kobe installs and manages it for you, or uses an install you already run.
gVisor · Kata
plannedStronger isolation tiers for untrusted code: a user-space kernel with gVisor, or a microVM with its own kernel with Kata. Reserved in the SandboxPool schema today.
Cluster backends
Set per pool with spec.backend.type. Every backend serves the same lease API.
| Feature | k3sdefault | k0s | vcluster | CAPI |
|---|---|---|---|---|
| Status | Production | Production | Production | Available |
| Best for | CI and dev clusters | Teams standardized on k0s | High-density CI | Existing Cluster API infra |
| Isolation | Full cluster | Full cluster | Namespace | Full cluster |
| Lease from a warm pool | ~1s | ~1s | ~1s | ~1s |
| Cold build, to refill the pool | ~30s | ~30s | ~15s | ~60s+ |
| Overhead per cluster | Low | Low | Very low | Provider-dependent |
| Shared PostgreSQL datastore | Yes | Yes | No | No |
| Custom addons | Yes | Yes | Yes | Yes |
k3sdefault
- Status
- Production
- Best for
- CI and dev clusters
- Isolation
- Full cluster
- Lease from a warm pool
- ~1s
- Cold build, to refill the pool
- ~30s
- Overhead per cluster
- Low
- Shared PostgreSQL datastore
- Yes
- Custom addons
- Yes
k0s
- Status
- Production
- Best for
- Teams standardized on k0s
- Isolation
- Full cluster
- Lease from a warm pool
- ~1s
- Cold build, to refill the pool
- ~30s
- Overhead per cluster
- Low
- Shared PostgreSQL datastore
- Yes
- Custom addons
- Yes
vcluster
- Status
- Production
- Best for
- High-density CI
- Isolation
- Namespace
- Lease from a warm pool
- ~1s
- Cold build, to refill the pool
- ~15s
- Overhead per cluster
- Very low
- Shared PostgreSQL datastore
- No
- Custom addons
- Yes
CAPI
- Status
- Available
- Best for
- Existing Cluster API infra
- Isolation
- Full cluster
- Lease from a warm pool
- ~1s
- Cold build, to refill the pool
- ~60s+
- Overhead per cluster
- Provider-dependent
- Shared PostgreSQL datastore
- No
- Custom addons
- Yes
Agent Sandbox isolation
Sandboxes run on Kubernetes Agent Sandbox v1.0.0, which Kobe installs and manages, or consumes from an install you already run. Every sandbox is a container today. Administrators set the tier per pool; callers cannot change it.
| Feature | Containertoday | gVisor | Kata |
|---|---|---|---|
| Status | Production | Planned | Planned |
| Kernel | Shared with the host | Runs in user space | Own kernel, per sandbox |
| Use for | Trusted workloads | Untrusted code | Untrusted code |
| Tier in the pool spec | trusted-runc | gvisor | kata |
Containertoday
- Status
- Production
- Kernel
- Shared with the host
- Use for
- Trusted workloads
- Tier in the pool spec
- trusted-runc
gVisor
- Status
- Planned
- Kernel
- Runs in user space
- Use for
- Untrusted code
- Tier in the pool spec
- gvisor
Kata
- Status
- Planned
- Kernel
- Own kernel, per sandbox
- Use for
- Untrusted code
- Tier in the pool spec
- kata
Every sandbox pool includes
- kobe run, exec, attach, and logs
- SSH straight into a sandbox
- Sessions that survive a dropped connection
- Optional Linux desktop you can view or drive
- Published ports and authorized port ranges
- File transfer with scp, sftp, or rsync
- Idle reclaim with maxIdle
- Direct or peer-to-peer transport (iroh, preview)
- Placement in the management or a child cluster
- Non-root, capabilities dropped, seccomp on
Give every job the right environment
Run Kobe in your own cluster. Pool Kubernetes environments for CI and define bounded sandboxes for agent workloads.
>_ apache-2.0 · open source
Feedback and contributions welcome
We read every issue. Backend support, a bug in a lease lifecycle, a gap in the docs: open one and it lands in front of the people who wrote the code. The roadmap lives in the issue tracker, so an issue is also how a priority changes.
kunobi-ninja/kobe · pull requests welcome, including the first one