cix

Open-source Linux for dedicated infrastructure

Run the machine.
See everything.

Cix is a rolling-release Linux operating system, written in C and built from source for operators who want one clear way to run containerised infrastructure. Every workload runs in a container; one API manages the host, boot, networking, storage, hardware, services, and workloads around it.

Try Cix Download the installer
Workloads
Container-only
Control plane
One REST API
Software supply
Source → image
cixctl / control plane
Cix — Systems, directly.
(c) The Cix Project — Apache-2.0

host   cix 0.2.57-378 · slot a · kernel 7.2.3

Type a command, "help", or "exit".
cix.internal> boot
build:       0.2.57-378
slot:        a
kernel:      7.2.3
root disk:   vdb
esp:         /dev/vdb1
root_a:      /dev/vdb2
root_b:      /dev/vdb3
config:      /dev/vdb4
containers:  /dev/vdb5
cix.internal> boot-manager
boot manager: 12288 bytes · installed
pre-update backup: available
cix.internal> container ls
dns-1       running  ready=yes  services=dnsmasq:running
dns-2       running  ready=yes  services=dnsmasq:running
ldap-1      running  ready=yes  services=glauth:running
ldap-2      running  ready=yes  services=glauth:running
ntp-1       running  ready=yes  services=chronyd:running
ntp-2       running  ready=yes  services=chronyd:running
syslog-1    running  ready=yes  services=syslogd:running
syslog-2    running  ready=yes  services=syslogd:running
jump        running  ready=yes  services=sshd:running
cr-1        running  ready=yes  services=keepalived:running,bird:running
cr-2        running  ready=yes  services=keepalived:running,bird:running
ar-1        running  ready=yes  services=hostapd:running
cix.internal> network ls
management  <management-network>/24  address=<management-address>
services    <services-network>/24
access      <access-network>/24
cix.internal> kmod
rtw88_8822bu  Live
rtw88_8822b   Live
igc           Live
igb           Live
e1000e        Live
ixgbe         Live
tg3           Live
cix.internal> device ls
usb: Realtek 802.11ac NIC                         assignable
pci: vdb (virtio-pci)                               assignable
net: eth0                                            unassignable
gpu: card0                                           unassignable
disk: sr0 QEMU DVD-ROM                              assignable
cix.internal> server-health
ntp      ntp-1     healthy  in_service=yes
ntp      ntp-2     healthy  in_service=yes
syslog   syslog-1  healthy  in_service=yes
syslog   syslog-2  healthy  in_service=yes
dns      dns-1     healthy  probe=tcp:53
dns      dns-2     healthy  probe=tcp:53
ldap     ldap-1    healthy  probe=tcp:636
ldap     ldap-2    healthy  probe=tcp:636
cix.internal> ldap config show
start_uid=10000 start_gid=10000
client_uri=(unset)
effective_client_uri=ldaps://<ldap-provider>:636/
base_dn=dc=<site>,dc=<domain>
bind_password=(set)
listeners=managed ldap=off:3893 ldaps=on:636 clients_use=ldaps
cix.internal> iso status
state=ready
signature=present
cix.internal> schedule ls
refresh-upstreams  pkg.refresh-upstreams  every 6h  ok
recipe-sync        pkg.sync               every 6h  ok
cix.internal>
host state · API-backed controlsstart with the quickstart

01 / The Cix proposition

Infrastructure you can
explain end to end.

Cix is for people who want to understand and control the whole machine. It is a rolling-release Linux operating system, written in C and built from source—not a pile of layers you have to stitch together, but one system with one API.

Run containers with explicit networks, storage, hardware, limits, and real resource reporting. Build from recipes, use verified artefacts when they exist, and update through immutable images and rollback-aware A/B slots.

One machine. One control path. From source code to running workload, Cix keeps the important parts visible.

Choose your path

Choose your next
useful step.

Cix is built for systems operators and engineers. Start by running it, understanding it, or integrating with it—you do not need to read the whole architecture first.

01 / Run it

Run it on a machine.

Download the signed x86-64 installer, verify it independently, and review the current UEFI and hardware boundaries.

Get Cix →
02 / Evaluate it

See what is different.

Compare Cix’s source-built, API-first operating model with a conventional distribution and container stack.

Read the case for Cix →
03 / Integrate it

Build on the API.

Inspect the architecture, OpenAPI contract, and service model before you automate.

Explore the API boundary →
04 / Build it

Build from the source.

Follow a recipe through CBS, packages, images, host updates, and installer creation on a Cix host.

See the build path →

01

Built from source

Packages, images, the kernel, and Cix itself belong to one source-build pipeline. Compilation is part of the system, not an afterthought.

02

C control plane

The container runtime, REST daemon, CLI, and custom networking plane are native C systems compiled with the Tiny C Compiler.

03

API-first

The CLI and web dashboard are REST clients. Capabilities exist in the API before any client exposes them; no control surface gets a privileged back door.

04

Everything is visible

Containers, networks, disks, GPUs, DNS, PKI, packages, and services follow one visible lifecycle.

02 / Architecture

One short path.
No hidden control plane.

Every operator surface converges on cixd. The daemon is the only process linked to the runtime, which uses the Linux mechanisms underneath directly.

Explore the architecture →
See a reproduced product workflow →
cixctlREST client
Web dashboardREST client
{ }Your toolsOpenAPI
HTTP / JSON
PID 1 · API-FIRST CONTROL PLANEcixdC · TCC · epoll
direct interfaces
clone3()namespaces + cgroups
OverlayFSshared immutable roots
rtnetlinknetwork data plane
/devhardware grants
KERNEL.ORG LINUX · OPERATOR-SELECTED RELEASE POLICY

Platform services

The host owns intent.
Containers serve protocols.

Cix keeps infrastructure data visible through its API, then projects it into replaceable containers running real service software. DNS, LDAP, DHCP, NTP, syslog, and PKI become integrated platform capabilities without hiding their ownership or protocol boundaries.

Explore the service model
API-OWNED INTENTrecords · identities · ranges · policy
render · register · synchronise
ORDINARY SERVICE CONTAINERSdnsmasqglauthchronysysklogd
standard protocols
CONSUMERShost · workloads · network clients

Why another distribution?

A different operating model.

Cix does not claim that every abstraction is bad. It removes layers when direct, explainable mechanisms can do the job reliably.

ConcernConventional stackCix
Control pathMultiple tools and privileged surfacesOne API-first C control plane
Workload isolationExternal container runtime layersLinux namespaces and cgroups directly
NetworkingSeparate switching or orchestration layerCustom C plane over rtnetlink
Software deliveryPrebuilt packages from an upstream distributionSource recipes, builds, images, and verified artefacts
Host updatesMutate the live root in placeWrite, verify, then boot the inactive A/B slot
The complete case for Cix

03 / Resource model

The same nouns everywhere.

The API, CLI, web dashboard, and documentation describe the same resources with the same lifecycle logic. Explore resources and hardware →

Containers

Namespace isolation, cgroup controls, supervised services, derived readiness, dependencies, and console.

/v1/containers

Networks

Bridges, routes, VLANs, physical interfaces, addressing, DNS, and DHCP.

/v1/networks

Hardware

Discover and grant real PCI, USB, GPU, radio, network, disk, CPU, and memory resources.

/v1/devices

Software

Recipes, source builds, packages, immutable images, artefacts, and rolling updates.

/v1/pkg

Control the real machine

Isolation, devices, and disks are not afterthoughts.

Cix makes host mechanisms visible as policy-driven API resources—from the identity a container runs under to the physical port a device occupies and the disk where state lives.

01 / Isolation

Namespace containers by default.

Containers use Linux namespaces and cgroup v2 controls, but full user-namespace UID/GID isolation is not enabled by default. Container processes currently run with real host UID 0; capability bounding-set trimming removes dangerous privileges, while user-namespace isolation remains an open implementation boundary.

  • Linux namespaces and cgroup v2
  • Capability bounding-set controls
  • Explicit boundary: not a virtual machine
ContainerCreateRequest.userns
02 / Hardware

Name hardware once. Resolve it live.

Grant PCI, USB, GPU, raw disk, or physical network hardware by discovered ID or an operator-named device map. Exact mappings pin a bus/port location; vendor-model mappings follow matching hardware when it moves.

  • BPF cgroup device enforcement
  • Optional devices + USB hotplug reaction
  • Atomic live attach and revoke
/v1/devicemaps
03 / Storage

Place storage by intent.

Discover real disks and partitions, assign closed operational roles, format ext4 or btrfs, and migrate storage without inventing a parallel storage registry. The OS disk is protected from role assignment and formatting.

  • State, logs, builds, backups, swap
  • Per-container placement and kernel quotas
  • Persistent volumes with enforced size limits, live usage, snapshots, and restore
/v1/storage-roles

Boundary: Cix containers use namespaces, not a hypervisor. Device grants are direct container access—not a VFIO/IOMMU virtual-machine isolation boundary. The installer also supports a Secure Boot-capable installed boot chain.

04 / Package management + build + delivery

Its own software
supply chain.

Self-hosting proof

Cix builds Cix.The same container and recipe system can compile the Cix control plane, build the Linux kernel, assemble the root filesystem, and produce an installer ISO on a running Cix host.Inspect the self-hosted build path →
  1. 01SyncTrack recipe source
  2. 02VerifyPin source + checksum
  3. 03BuildCompile inside Cix
  4. 04PackageRecord files + version
  5. 05ImageImmutable rootfs versions
  6. 06DeliverRolling or A/B update

One package systemRecipes, dependencies, source builds, install manifests, upgrades, and removals are managed by Cix.

One pipeline modelPackages, images, deployments, and host updates share visible stages, history, and a common view of what is waiting or blocked.

Build artefactsReuse checksum-verified artefacts when configured; build from source when the recipe supports the current CPDL/CBS path.

API-controlledRepository sync, build jobs, packages, images, deployments, artefacts, and updates are exposed through REST.

05 / Project status

Know what is ready.
Know what is not.

Cix is an alpha operating system. Check the current limitations before using it on a machine or workload that matters.

See project status Explore the API
01

Architecture decisionsHard-to-reverse choices documented as ADRs.

02

Real-system verificationBare-metal paths exercised through QEMU and hardware checks.

03

OpenAPI contractThe management surface is specified and inspectable.

04

Explicit boundariesUnbuilt work is named rather than marketed as complete.

Cix / pronounced “six”

Run it—or inspect every line.

Start with the signed installer, or follow the design from public contract to implementation.

Get started View source