Active engineering project
Show what works.
Name what does not.
Cix’s roadmap is a phase-by-phase engineering record, not a future-feature checklist. This page describes implemented engineering—not a production-support or general-availability promise.
Source Public Cix source mirror ↗
Evaluation posture Build and test from source
Update model Rolling source and release evidence
Current foundation
What shipped lives in one place.
Use the roadmap to see what is available now and how each capability was tested.
This page highlights the limits that matter before you install or operate Cix. The roadmap contains the detailed change history and test evidence.
Read what shipped, and how it was verified
Evidence model
Four routes to technical truth.
Known boundaries
Read these before evaluating.
These are the limitations most likely to affect an installation or first workload. Check the installation and administration guides for the exact procedure.
- Permissioned APIOnce authentication is active, protected reads and operations require the permission declared by the API. Health, login, logout, and whoami remain public; other reads need a session. A 401 means no valid credential; a 403 means the credential lacks the required permission. App passwords provide revocable machine access.
- Fresh-install pathSigned, prebuilt install media is available from Cix Cache; Cix can also build and publish its own media. A seed is needed for an offline first container, and the installation guide records a current outbound-DNS limitation on fresh systems. Evaluate the exact guide before choosing hardware.
- Building from sourceCurrent source builds use CPDL 1.0 and CBS. Cix no longer builds shell recipes; older shell artefacts are historical and may only be usable when a verified cache entry remains available. Read the build guide before planning a source-only workflow.
- Release confidenceInstaller releases are signed and tested, but Cix is alpha. Verify the installer yourself and evaluate the exact hardware and workload you plan to use.
- Multi-host coordinationIntentionally not designed yet. The current architecture avoids foreclosing it, but makes no cluster or distributed-systems promise.
- Wireless verificationA real 2.4 GHz access point now runs with its radio inside a container, but client association, over-air DHCP leases, and end-to-end wireless-to-wired traffic are not yet proven. 5 GHz remains dependent on an operator-confirmed country setting.
- Hardware verificationSome positive device paths—particularly real GPU, physical-NIC, and wireless-client scenarios—have narrower verification than emulated and software-only paths.
- Container isolation boundaryThese are Linux namespace containers, not virtual machines. Direct device grants do not provide a VFIO/IOMMU hypervisor isolation boundary.
- Approval gatesPublish, rolling, and host-deploy gates exist for changes that cross their normal blast radius, but default to off. A deployment can wait for its image to be built; this does not imply unattended production delivery.
- Upstream release discoverySigned upstream-release discovery is designed but not shipped. Recipes still need a published revision; Cix does not silently follow arbitrary upstream tags.
- Rolling does not mean newestRolling describes the delivery model. It does not claim every component always tracks its latest upstream release.
Last word
Check the current evidence.
Use the roadmap and guides for the detailed evidence.
Read the full roadmap