Containers
Each workload gets namespaces, a cgroup, an image-derived root, network attachments, resource limits, declared services, and optional hardware.
/v1/containersResource model
Name the thing.
Control the boundary.
Cix treats workloads, networks, storage, and hardware as visible API resources. That makes placement and access explicit—and makes the limits of the machine easier to inspect.
The nouns
One model for the real machine.
These are not decorative categories. Each resource has an API identity, lifecycle, and place in the control path.
Networks
Bridges, veth, routes, VLANs, addresses, physical interfaces, and whole wireless radios are configured through the custom C data plane.
/v1/networks
Storage
Disks and partitions are enumerated live, assigned explicit roles, and can be formatted through a separate destructive action. Filesystem identity and capacity are probed in a helper snapshot, so the API can say “probing” instead of blocking the daemon or guessing that a disk is empty.
/v1/disks/v1/storage-roles
Devices
PCI, USB, GPU, radio, network, disk, CPU, and memory resources can be discovered, named, and granted to workloads with cgroup enforcement.
/v1/devicesWhat an operator controls
Isolation, placement, and access stay concrete.
Cix exposes the mechanisms that decide where work runs and what it can touch. The API records intent; the daemon applies it to Linux primitives and reports the result.
01 / IsolationNamespace containers, with an explicit root boundary.
Workloads use Linux namespaces, cgroup v2 controls, and user namespaces by default. Their image-derived roots are presented through id-mapped mounts; trusted internal build containers may opt out where required. Capability bounding-set trimming still applies. This is a container boundary, not a VM or a complete hypervisor isolation boundary.
- Linux namespaces, user namespaces, and cgroup v2
- Id-mapped image-derived roots
- Capability bounding-set controls
02 / PersistencePut durable state on volumes.
Volumes outlive containers and can carry an enforced size limit. Usage is measured through the kernel’s quota accounting where available, with the accounting source exposed rather than hidden.
- Persistent data
- Size limits
- Live usage and backups
03 / HardwareGrant hardware by intent.
Operator-named mappings can follow matching hardware when it moves. Device access is explicit, shared ownership is checked, and attach/revoke is reflected through the API.
- PCI, USB, GPU, radio
- Physical network interfaces
- cgroup device filtering
Hardware boundaries
Implemented is not the same as fully proven.
Evaluate the exact machine against the source guide. Cix keeps narrower verification visible rather than turning a capability into a compatibility promise.
- Namespace containersContainers are not virtual machines. Direct device grants do not provide VFIO/IOMMU hypervisor isolation.
- WirelessA real 2.4 GHz access point runs with its radio in a container, but client association, over-air DHCP, and end-to-end wireless-to-wired traffic remain narrower proof paths.
- GPU and physical NICsDiscovery, grants, and API paths exist, while some positive real-hardware scenarios have less verification than software-only or emulated paths.
- Storage compatibilityThe installer documents covered paths and exclusions. Check the current installation guide before choosing disks, controllers, or a hypervisor configuration.
Canonical references
Inspect the resource contract.
Use the API and administration guides for exact fields, routes, and machine prerequisites.
Read administration guide
Review install boundaries