Key Concepts
DevCell uses a few precise terms to separate product objects from implementation details. Start with the relationship: clients pair with a host; the host manages cells; every cell runs one workspace.
celld · state · policy · support planeCellOS · workspace · runtimeProduct objects
Section titled “Product objects”DevCell Host
The trusted NixOS appliance that owns identity, policy, storage, routing, credentials, and cell lifecycle.
Cell
A durable development-machine identity. It survives runtime restarts and owns one workspace, its operations, ports, and checkpoint lineage.
Workspace
The checked-out repository and its resolved development environment inside a cell. Usually driven by a devcontainer.
Fabric
The product-level model: one or more DevCell Hosts presented through a consistent control plane. The current prototype is one host.
Client
Anything paired to the host: the Swift app, CLI, IDE integration, or a program using the generated Connect API.
Capability
A scoped permission requested by a workspace and granted by host policy. Repository configuration can ask; only the host can authorize.
Runtime terms
Section titled “Runtime terms”celld
The Go control-plane daemon. It serves the API, persists state, coordinates backends, and reconciles reality after restart.
CellOS
The small, immutable guest supervisor image used inside a Firecracker cell. It is an implementation boundary, not a general-purpose distro.
cell-agent
The guest-side Go service that initializes the workspace, executes commands, reports ports and services, injects grants, and quiesces snapshots.
Backend
The machine provider behind the lifecycle contract. DevCell currently implements fake, container, and Firecracker backends.
WorkspacePlan
The deterministic result of resolving repository files, devcontainer configuration, machine resources, and requested capabilities.
Support plane
Trusted host services a cell may consume through policy: private routing, identity, credential brokering, storage, and later shared caches.
State and lifecycle
Section titled “State and lifecycle”Operation
A durable record of a long-running change such as create, start, checkpoint, fork, or destroy. It contains ordered steps and events.
Runtime descriptor
Backend-specific facts needed to inspect or reconcile a cell: process identity, paths, TAP device, vsock CID, guest endpoint, and isolation label.
Checkpoint
A saved workspace state. The container demo stops services and copies the workspace; Firecracker memory and diff snapshots are a separate layer.
Snapshot
The API object representing a restore point and its lineage. In current CLI copy, “snapshot” creates a filesystem checkpoint where supported.
Fork
A new cell identity created from a snapshot. The parent remains untouched while work continues independently in the child.
Sleep
A capacity action. Today it means checkpoint plus stop on the container backend, then a cold start; it does not claim RAM suspend.
Now trace these objects through System Architecture or see them in motion in Run the Demo.