Trust and limits

Verify the bytes.
Understand the boundary.

Cix makes its installer verifiable and its current limitations visible. This page separates what a check proves from what still requires hardware testing, operational judgement, or future project work.

Verify the current release

Review project status

Channelalpha

ReleaseCix 0.2.57-678

Architecturex86-64

01 / Release integrity

Trust the signed file.

The Download page publishes the ISO, detached minisign signature, release key, key identifier, and SHA-256 values from one release manifest. Verify the signature on a machine you already trust before writing the image.

Open verification steps

Review release keys

02 / What verification means

Useful proof, not a magic stamp.

A valid signature tells you that the downloaded bytes verify against the published Cix release key. It does not certify every machine, workload, configuration, or security property of the running system.

It provesThe ISO and detached signature match the release identity published by Cix and the signature verifies against the selected public key.
It does not proveThat your hardware is supported, that a workload is secure, or that an alpha release meets your production requirements.
It is reproducible to inspectThe manifest, source mirror, guides, API contract, and test evidence are public. A public source/build record is not the same as a formal reproducible-build guarantee.
It is independently checkableThe verification command uses minisign on a machine you already trust; it does not require trusting the website’s JavaScript.
API access is separate proofRelease verification proves installer bytes, not authorisation. Once host authentication is active, API operations follow explicit permissions; a valid session without the required permission receives 403.
MCP follows the same boundaryNative MCP calls use cixd’s existing permission and audit path. Agent app passwords are scoped by groups and cannot create identities or mint replacement credentials.

Security boundary

Containers are not virtual machines.

Cix workloads use Linux namespaces, cgroups, and user namespaces by default. Their image-derived roots are presented through id-mapped mounts; trusted internal build containers may opt out where required. Direct device grants provide access to hardware rather than a hypervisor isolation boundary, so evaluate the boundary against the workload you intend to run.

namespacesuser namespacescgroup v2not a VM

Update safety

Write, verify, then hand over.

Host updates target the inactive A/B slot. When the kernel is unchanged, Cix can hand the running control plane to the staged root in place: the successor validates the handover, running containers remain running, and the slot is confirmed only once the new daemon serves. Kernel changes still reboot, and failure falls back to the previous slot.

same-kernel handoverread-only rootverified cutoverrollback

Compatibility

Supported paths are narrower than Linux.

The current installer targets UEFI x86-64 and documents specific storage, network, console, and hypervisor paths. Real GPU, physical-NIC, and wireless scenarios have narrower verification than software-only or emulated paths. Check the installation guide before choosing hardware.

Read installation boundaries Review hardware limits

06 / Project posture

Alpha means a real boundary.

Cix is available for evaluation and community use, but it does not yet publish formal support tiers, certifications, or a complete lifecycle commitment. For now, report suspected security vulnerabilities privately to osakka@gmail.com with the subject “Cix security report”; do not put sensitive details in a public issue. This is a maintainer contact, not a bug bounty or guaranteed response SLA.

See current status

Contribute to the work