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. For a running build, one floating log view follows the selected job, identifies the build, shows its current stage and elapsed stage time, and keeps output readable.

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. Image policy controls whether recipe changes are followed, whether applying a recipe converges installed packages, and whether a backward pin is allowed. Writes made inside that root do not survive a new derived root. Persistent data belongs on volumes, where size limits and usage are explicit.

rolling imagesrootfs freshnesspersistent volumessize limits

Image policy

Choose how image state agrees.

An image recipe, its live manifest, and its installed packages are three useful views of the same intent. Set the policy explicitly: follow or manually apply recipes, declare or converge installs, and refuse or allow downgrades. Export the live manifest when the box is the source of a recipe.

manual / followdeclare / convergedowngrade guardrecipe export

Visible boundaries

Power with visible boundaries.

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

Permission-aware accessOnce host authentication is active, protected reads and operations require the permission declared by the API. A 401 means log in; a 403 means the session is valid but its groups do not grant the required permission. App passwords support scripts and automation.
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.

One workload.One readable path.