Kibotos

Glossary

Short definitions of the terms used across the Kibotos documentation, in alphabetical order. Each entry links to the page that covers the term in full. On the site, a link to an entry shows its definition when you hover over it.

Annotation

A key-value pair that a caller stores on an object such as a Workspace or a Volume. Kibotos only stores annotations; to filter lists, use labels. See Labels and annotations.

Command ID

A stable identifier that the caller generates for every write request. Resending a request with the same command ID does not run the operation twice. See Write operation conventions.

Context

The local directory where kibo keeps the ctrl address, the Operator identity, and the trusted CAs. kibo context enroll creates it, and every later command reads it. See Context directory.

Control plane

The path for managing objects: creating, querying, stopping, and deleting Workspaces, Volumes, and other objects. Requests go to ctrl and authenticate with an Operator identity. See Control plane and data plane.

ctrl

The control-plane service of a Kibotos cluster. It accepts control-plane requests, decides which host each Workspace runs on, and issues session credentials for the data plane. See Architecture.

Data plane

The path for working inside a Workspace: files, processes, terminals, and desktops. Requests go directly to the node that runs the Workspace, with a session credential. See Control plane and data plane.

E2B gateway

The kibotos-e2b service, which translates requests from the E2B SDK into the native API so that programs written for E2B can use Kibotos. See E2B compatibility.

Egress

An outbound SOCKS5 proxy that the caller runs. When a Workspace's network policy references it, TCP connections to the given ranges leave from the caller's network. See Egress.

Enrollment key

A single-use key file with a limited lifetime. An Operator or a node exchanges it for its identity. See Identity and enrollment.

Expected revision

The revision of an object that a write request expects. If someone else changed the object first, the request is rejected instead of overwriting their change. See Write operation conventions.

Exposure

An object that turns an HTTP port in a Workspace into a public https:// address. See Public URLs.

Exposure gateway

The service that receives traffic for public URLs and forwards it to the port of the matching Workspace. See Install the Exposure gateway.

Generation

One run of a Workspace. Every successful start begins a new generation, numbered from 1 upward; the credentials, processes, and connections of the previous generation become invalid. See Workspaces.

guest

The Linux system that runs inside the MicroVM of a Workspace. The guest agent in it performs file and process operations for the node.

Incarnation

The number of one run of a node process. The node increases it at every start, and ctrl rejects a connection that carries an isolated or older incarnation. See isolate.

Instance

The MicroVM that runs a Workspace on a node. Every start creates a new Instance with its own ID, which host directories, process arguments, and logs carry. See Which node runs a Workspace.

Label

A key-value pair that a caller attaches to an object such as a Workspace or a Volume. You can filter lists by label. See Labels and annotations.

Launch

The pairing of one Template revision and one Platform revision that a Workspace boots from. Each Workspace is bound to one Launch, and artifact reclamation keeps every Launch that an undeleted Workspace is bound to. See Artifact reclamation.

Network policy

The rules that decide where a Workspace's outbound traffic may go: its mode, destination rules, and any Egress or Resolver it references. A new Workspace has no network access by default. See Network policy.

node

The service that runs on every host. It starts and stops the MicroVMs of Workspaces and serves the data plane. See Architecture.

Operator

A person or program that holds an Operator identity. An Operator can operate every Workspace in the deployment and administer the cluster with kibo. See Identity and enrollment.

Platform

The kernel, initramfs, and guest programs that Workspaces boot with. When ctrl creates a Workspace, it combines the Template with a compatible Platform. See Catalog.

PlatformKey

The five properties that identify one line of Platform revisions: backend, architecture, kernel series, guest protocol, and rootfs contract. Each PlatformKey has its own default revision. See kibo platform.

Resolver

A DNS server that the caller provides. When a Workspace's network policy references it, the guest's DNS queries go to it. See Resolvers chosen by the caller.

Retained layer

The Operator name for the writable layer of a Workspace: one block file in a storage pool, counted against the pool like a Volume. Operator commands, storage pool listings, and metrics use this name. See Objects in a pool.

Revision

An immutable version of a Template or a Platform. Every publish produces a new revision, and the deployer selects a default revision for each Template. See Templates and revisions.

Session credential

A short-lived credential for the data plane. You request it from ctrl, together with the address of the node that runs the Workspace. See Architecture.

Storage pool

The storage where a deployment keeps Volumes and writable layers. A Workspace starts only on a host that can reach the storage pools it uses. See Storage pools.

Template

The system image a Workspace is created from, such as a minimal system, a programming toolchain, or a desktop environment. See Templates and revisions.

Transfer

An export of the Volume of a stopped Workspace to an archive. You can import the archive as a new Volume and restore it as a new Workspace. See Export, import, and restore.

Use right

The right to open the block file of a Volume or retained layer, which ctrl grants to only one node at a time. A node without it does not open the file, so two hosts never write the same object on shared storage. See Standalone and shared pools.

Volume

A persistent volume that exists independently of any Workspace. A Workspace binds at most one Volume, mounted at /data by default. See Volumes.

Workspace

A complete Linux environment for an AI Agent, running in its own MicroVM. Agents read and write files, run processes, and start services in it without affecting the host or other Workspaces. See Core concepts.

Writable layer

The writable part of a Workspace's root file system, holding changes such as installed packages; Operator pages call it the retained layer. It is kept on a best-effort basis, and only the Volume is guaranteed to keep data. See Guarantees and limits.

On this page