Operator model

Declare intent.
Follow it through.

Cix makes the path from a deployment declaration to a ready workload visible: the API records intent, one pipeline shows what is waiting, and the daemon reports the state that actually exists.

The lifecycle

One workload.
One readable path.

Deployments name the image, placement, network, storage, files, services, and restart policy a workload needs. If the image is not ready, Cix queues the work and reports that it is awaiting the image rather than making the operator perform a manual round trip.

01 / DECLAREDeploymentDescribe what should run and which image it needs.

queue and converge

02 / PROGRESSShared pipelineSee acquisition, assembly, staging, deployment, and verification as the work moves.

readiness probe

03 / CONFIRMReady workloadInspect service state, logs, resource views, and the declared console path.

Pipeline state

See what is blocked—and why.

Packages, images, deployments, and host updates use one pipeline vocabulary. The dashboard draws each item as a row across the stages it actually uses, preserves run history, and distinguishes a waiting deployment from a failed one. A shared view makes the next operator action legible instead of hiding it in separate subsystems.

acquireassemblestagedeployverifyrun history

Runtime feedback

Read the workload, not just the process.

Readiness is derived from the service definitions and their checks, not inferred from a process merely existing. The dashboard and API expose logs, health, lifecycle state, container-visible resource limits and usage, and the console entry points a workload explicitly declares.

readinesslogs/proc viewsservices[]declared consoles

State and updates

Keep durable state where it belongs.

A container root is derived from its image. When a rolling image pin changes, Cix rebuilds a stale root so the running workload receives the new image; writes made inside that root do not survive the change. Persistent data belongs on volumes, where size limits and usage are explicit.

rolling imagesrootfs freshnesspersistent volumessize limits

Visible boundaries

Power with visible boundaries.

The operator surface is implemented, but it is not a promise of production readiness or VM isolation.

Authentication bootstrapWrites are open until an admin group has a real member. Once active, mutating operations and container-console access require an admin session.
Approval gatesPublish, rolling, and host-deploy gates default to off. When enabled, the affected item is held and reported as blocked until approval is granted.
Namespace containersCix workloads use Linux namespaces and cgroups. Direct device grants are not a hypervisor or VFIO/IOMMU isolation boundary.
Hardware confidenceSome real GPU, physical-NIC, and wireless paths have narrower verification than software-only and emulated paths.

Go deeper

Operate from the contract.

The dashboard is a client. The API, guides, roadmap, and tests are the operational record.

Open the administration guide

Read the dashboard guide

Declare intent.Follow it through.