Skip to content
Kyber

Multi-cluster and the API

Kyber scales from one box to several clusters, and everything the console does is backed by a REST API you can call yourself. That means the same platform covers a laptop experiment, a production install, and scripts that automate both.

Several clusters, one place

Section titled “Several clusters, one place”

Each Kyber install is its own cluster with its own console. For operators running more than one, Holocron is a multi-cluster hub: it mounts the same console once per cluster, so you move between installs without juggling URLs or separate logins. Every screen shows a cluster identifier with the cluster’s name and version, so you always know which cluster and which build you are about to act on.

Clusters follow a simple naming convention: the logical name is the Helm release name, in the kyber-<env> pattern, such as kyber-laptop or kyber-gcp. Pick a name that describes the environment’s role, not its hardware, and keep it stable. The values file plus the release name is the complete definition of a Kyber install, so standing up a new environment is a values file and an install away. See the quickstart for the first one.

The API and its keys

Section titled “The API and its keys”

All operator-facing requests go through the control plane’s REST API under /api/v1/*, authorized by the Kyber API key: a single 256-bit credential generated at install time. The console itself is a client of this API, exchanging the key once for a session cookie rather than keeping it in browser storage.

The key can be rotated programmatically with no downtime: one authenticated call swaps the key, and the old one stops working on the next request. A manual rotation path exists for compromise recovery.

For agent lifecycle actions, you can also issue scoped keys. A lifecycle:write key can start, stop, and restart agents; the more impactful force-re-auth verb needs lifecycle:admin, which includes everything write grants. Enforcement is opt-in per cluster: under-scoped callers are audit-logged but not blocked until you turn it on, so you can define scoped callers, watch the audit log, and then enable enforcement.

Durable tasks and public capability discovery have their own mandatory scopes and tenant/principal ownership checks. Those checks remain enforced independently of the optional lifecycle enforcement switch. Callers also need permission for the exact agent resource.

Agents authenticate to the platform separately, with per-pod credentials that only let an agent act on itself; no agent can drive another agent through the API.

When creating agents through the API, supply the selected runtime’s required authentication inputs. Claude subscription creation uses the complete PKCE exchange; Codex subscription creation starts the in-pod device flow. The console guides those flows, and the runtime descriptor advertises supported auth modes. Do not assume that a credential format accepted by one runtime works for another.

Learn more

Section titled “Learn more”