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 have explicit operational roles. Placement, quotas, backups, swap, and volumes remain visible rather than hidden in a generic mount layer.
/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 / IsolationUser namespaces by default.
Container root maps to a dedicated subordinate-ID range on the host unless user namespaces are explicitly opted out. cgroup v2 governs CPU, memory, processes, pressure, and device access.
- UID/GID mapping
- Real limits and statistics
- Container-visible resource views
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