Read through the CLI.
$ cixctl site show
instance_name=cix
site_name=(none)
domain_suffix=internalReproduced product workflow
One contract.
Three views.
This is a historical capture of real output from a disposable Cix daemon—not a live status page or website mock-up. A CLI write changes API-owned state; an independent REST read and the first-party dashboard show the same result.
Source revision
4d5f4ffaCaptured1 September 2026
DaemonCaptured daemon build, TCC
FixtureDisposable local data directory
The workflow
Change identity.
Read it back.
The site identity is a small example chosen because it is safe to reproduce. The same client boundary applies throughout Cix: cixctl and the dashboard call the REST API rather than private control paths.
Write through the CLI.
$ cixctl site set \
--instance-name=demo \
--site-name=cix \
--domain-suffix=invalid
instance_name=demo
site_name=cix
domain_suffix=invalidConfirm through REST.
$ curl -s \
http://127.0.0.1:18766/v1/system/site
{"instance_name":"demo",
"site_name":"cix",
"domain_suffix":"invalid"}Run the path yourself
From health check
to workload.
The current quickstart uses the same API boundary shown here. Run these commands against an installed host; the first response confirms reachability, and the later commands create the image, network, service, and declared console needed for a first useful container.
cixctl --host=<host-ip> health
cixctl pkg install --name=glibc
cixctl pkg install --name=bash
cixctl pkg install --name=coreutils
cixctl network create --name=lan1 --subnet=172.31.0.0 --prefix=24
cixctl container run --name=hello --image=base --network=lan1 \\
--service="main=/usr/bin/sleep infinity" \\
--console="shell=/usr/bin/bash"
cixctl container inspect hello
The first-party dashboard
The same state reaches the browser.
The dashboard header below rendered demo.cix.invalid from the same daemon after the CLI write. The capture is intentionally narrow: it proves the product surface without exposing host inventory.
Evidence scope
Know what was tested.
Cix records evidence by path rather than turning one successful boot into a universal compatibility promise.
- Automated and QEMU pathsInstaller, boot, API, console, and update behaviour have source tests and disposable-machine coverage. Follow the roadmap for the exact test and revision.
- Physical hardwareSelected real-machine paths have been exercised, but there is no complete hardware certification catalogue. Check the installation and resources guides for the current boundary.
- Dashboard evidenceThe screenshot on this page is an actual historical dashboard capture from a disposable daemon, not a mock-up or live production view.
- Re-run the proofUse the current release, quickstart, API contract, and source revision together. A historical capture demonstrates a path; it does not replace a current evaluation.
Follow the evidence
Inspect the exact contract.
GET /v1/system/site and PUT /v1/system/site are defined in the OpenAPI document and described in the API guide. The CLI and dashboard implementations are in the same source tree.