Open-source Linux operating system

Systems,
directly.

Cix is an independently built Linux operating system for people who want to see—and control—what their infrastructure is doing. Build packages and images from source, then manage the host, containers, hardware, and services through one API.

Get started

Read the architecture

Control plane: Native C
Software supply: Source → image
Interface: REST API-first

cix / host

$ cixctl health
ok

$ cixctl boot
build:   v2.57.122 (2026-09-12T14:27:24Z)
slot:    a
kernel:  7.2.3

$ cixctl kernel-policy show
channel:  stable
running:  7.2.3 (line 7.2)
channel is at: 7.2.5  -- you are behind it

host healthyCaptured · 192.168.15.95 · 2026-09-12

01 / Why Cix

Make the machine
easier to understand.

Cix is an open-source Linux operating system for infrastructure—not a desktop remix and not a container runtime with an OS label. It gives operators a clear path from an API request to the Linux mechanisms carrying it out.

Make the machine make sense. Clear systems, visible state, and tools that reward curiosity—serious engineering with room for joy.

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 →

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.

C control plane

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

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.

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

User namespaces by default.

Every new container gets its own user namespace unless explicitly opted out. Container root maps to a dedicated subordinate-ID range on the host, while cgroup v2 governs CPU, memory, processes, pressure, and device access.

Per-container UID/GID mapping
Real cgroup v2 limits and statistics
Loud failure—never silent downgrade

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 →

01SyncTrack recipe source
02VerifyPin source + checksum
03BuildCompile inside Cix
04PackageRecord files + version
05ImageImmutable rootfs versions
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; fall back to the source build path.

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

05 / Project status

Built in public.
Verified in layers.

Cix is an active engineering project. Its roadmap records what shipped, how it was tested, and which boundaries remain open. Claims on this site follow that record.

See project status

Explore the API

Architecture decisionsHard-to-reverse choices documented as ADRs.

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

OpenAPI contractThe management surface is specified and inspectable.

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.