Systems, directly.
The Cix source is available under the Apache License, Version 2.0. Contributions follow the DCO-based contribution guide; the Cix name and marks are governed separately by TRADEMARK.md.
Cix OS is a rolling-release hardware and workload orchestration platform, compiled entirely from source: a hand-rolled container runtime on raw Linux namespaces and cgroups, OverlayFS-based image layering, a 100% custom C networking data plane, and a REST control layer for the host, containers, hardware, disks, networks, DNS, PKI, and more — no runc, no Open vSwitch, no eBPF-based networking dataplane, compiled exclusively with the Tiny C Compiler (TCC). Every capability, including hardware itself, is a first-class API resource; containers are where all real work happens, the host is the thinnest possible layer underneath them. Full charter: docs/mission/MISSION.md.
Cix — pronounced six. Two halves, each naming a real part of what this is:
| Part | Principle |
|---|---|
| C | Both meanings are literal here. The core is hand-rolled C all the way down — the container runtime, the networking data plane, the REST control layer — compiled exclusively with the Tiny C Compiler; C is not an implementation detail, it is the product. And containers are where all real work happens, with the host as the thinnest possible layer underneath them. |
| ix | For POSIX and UNIX: direct Linux primitives, exposed rather than wrapped. Raw namespaces and cgroups, OverlayFS, rtnetlink — no runc, no Open vSwitch, no bundled platform services. It exposes the kernel, not an opinion. |
The name is the architecture, not a label bolted on afterward. Its full brand system — strategy, voice, colour, typography, the mark and the UI icon set — lives in docs/brand/, with brand-guidelines.md as the authority.
Cix OS is more than a distribution — it's a discipline. Complex routing protocols, VPNs, and container infrastructure are built systematically, one pristine layer at a time, with no hacks and no bypasses. It exists to prove that a completely unified, custom C-based stack can be more reliable than a patchwork of legacy components.
docs/README.md is the index to the entire documentation set — start there if you're not sure which document has what you're looking for. docs/guides/quickstart.md is the fastest real path from nothing to a running container.
See docs/roadmap/ROADMAP.md for the full phase-by-phase history — what shipped, how each was verified. Architecture diagram: docs/architecture/architecture.svg. API contract: docs/api/openapi.yaml, with a narrative walkthrough at docs/api/README.md. Why a given significant, hard-to-reverse decision was made: docs/adr/.
- Build it:
docs/guides/building-cix.md— on a dev machine, or self-hosted from a running Cix box with no separate dev machine at all. - Install it:
docs/guides/installing.md— the installer ISO, disk partitioning, Secure Boot. - Use it:
docs/guides/cli-reference.md(thecixctlcommand surface) anddocs/guides/web-dashboard.md(the browser UI) — both pure REST clients over the same API documented indocs/api/README.md. - Administer it:
docs/guides/administration.md(monitoring, backup/restore, disks),docs/guides/networking.md(networks, routing, VLANs), anddocs/guides/security.md(PKI, HTTPS, LDAP accounts). - Keep it updated:
docs/guides/kernel-build-and-ab-updates.mdanddocs/guides/staying-updated.md. - Extend it:
docs/guides/writing-recipes.md— building real software from source into apkg install-able package.
include/ runtime library public API (container.h) and internal glue
src/ runtime implementation (cgroup, namespaces, mounts, overlay, container networking)
netplane/ custom rtnetlink control plane (bridges, veth, routes — no ip/iproute2, no OVS)
daemon/ cixd: the REST daemon — the only process with direct runtime/network/DNS/PKI access
client/ shared HTTP client library used by the CLI and the daemon's own test suite
cli/ cixctl: pure REST API client, no direct runtime access
web/ browser dashboard: vanilla HTML/CSS/JS, no framework, no build step, served by cixd
image/ bare-metal boot tooling: kernel config, mkbootroot, cix-install, mkinstalleriso
init/ cix-init: PID 1 in every container, freestanding (no libc) — the one exception to the TCC-and-glibc rule
tools/ build-time tooling: apigen (generates the API surface from openapi.yaml), verify-symbols.sh
recipes/ package/ + image/ build & manifest recipes for `pkg install`/`image apply-recipe` (see recipes/README.md and docs/guides/writing-recipes.md)
test/ the test suite: per-feature tests, contract gates, and the subset the release selftest runs
docs/ all documentation — see docs/README.md, which indexes every subdirectory
build/ compiled output (gitignored)
build-inputs/ hand-fetched build inputs that `make` does not reproduce (gitignored): the Phase 11 kernel bzImage, the test floor's package artifacts