Self-host a deployment
Prerequisites
- A host that can run QEMU for
aarch64(the appliance images target this architecture regardless of your host's own CPU) - The published
os-totebox-loader.imgand, optionally,app-orchestration-slm-loader.imgfromsoftware.pointsav.com - A persistent disk image, created once and kept — an ext4-formatted raw file the guest mounts at
/data - If you need non-default configuration (a specific orchestration endpoint, a Tier B license): the source repo, the Microkit SDK, and an
aarch64cross-compilation toolchain — the published images alone don't let you change configuration after the fact (see Step 3)
Purpose
Self-hosting a deployment means booting one or both of two independent, self-contained seL4/Microkit appliance images on operator-controlled infrastructure: os-totebox (the Sovereign WORM Data Vault — local DataGraph, corpus ingestion, Tier A operations) and app-orchestration-slm (the Yo-Yo broker chassis — health, fleet, and discovery endpoints; Tier B brokering requires a license). Each runs standalone by default; neither needs the other present to start.
Procedure
-
Create your persistent disk, once:
qemu-img create -f raw persistent.raw 2GThis is where DataGraph state, adapter weights, and cached identity survive across restarts. Losing this file means losing everything the appliance has accumulated — it is not regenerated from the image.
-
Boot the image via QEMU's
-device loadermechanism (this is Microkit's own loader path, not the-kernel/-appendpath a general-purpose Linux VM would use):qemu-system-aarch64 \ -machine virt,virtualization=on,secure=off -cpu cortex-a53 \ -device loader,file=os-totebox-loader.img,addr=0x70000000,cpu-num=0 \ -m size=2G -nographic -global virtio-mmio.force-legacy=false \ -drive file=persistent.raw,format=raw,if=none,id=hd \ -device virtio-blk-device,drive=hd,bus=virtio-mmio-bus.1 \ -device virtio-net-device,netdev=netdev0,bus=virtio-mmio-bus.0 \ -netdev user,id=netdev0,hostfwd=tcp::<host-port>-:<guest-port> -
If the published, generic image's default configuration is sufficient, skip to Step 4. Otherwise, understand this before you try to change anything: runtime configuration is baked into the image at build time, in the device tree's
bootargs. There is no post-boot config file and no-appendequivalent on this boot path. Changing configuration means rebuilding the image yourself, with your ownfoundry.*bootarg values, and replacing the published one — see the relevant keys below and the full rebuild procedure in the internal dogfood development guide (GUIDE-live-flow-doorman-orchestration-yoyo.draft.md, project-totebox).Key Appliance Purpose foundry.orchestration_endpointos-totebox Chassis URL for Tier B brokering foundry.tier_b_subscribedos-totebox trueto claim a paid subscription at registrationfoundry.yoyo_default_endpointapp-orchestration-slm Default Yo-Yo compute backend URL foundry.license_token/foundry.license_pubkey_hexapp-orchestration-slm Ed25519-signed Tier B license -
Repeat Step 2 for
app-orchestration-slm-loader.imgif you want the Yo-Yo broker chassis too — it's an independent image with its own boot invocation, not a component started from insideos-totebox.
Expected outcome
os-totebox reaches a healthy, standalone state within seconds of boot, with or without app-orchestration-slm present — this degrade-not-refuse behavior is the intended design, not a sign of misconfiguration. app-orchestration-slm, if booted, answers health/fleet/discovery requests standalone; Tier B brokering itself stays disabled until a valid license is baked into a rebuilt image.
Verification
curl http://<host>:<totebox-port>/healthz # os-totebox
curl http://<host>:<orchestration-port>/healthz # app-orchestration-slm
curl http://<host>:<orchestration-port>/readyz # license / fleet / circuit status
Rollback
Stop the QEMU process. The persistent disk (persistent.raw) is untouched by stopping the guest — restarting the same boot command resumes from the same accumulated state. To discard accumulated state entirely, discard the persistent disk file itself and create a fresh one (Step 1); there is no partial-reset mechanism short of that.
Next steps
- Deploy a knowledge instance — deploy the wiki-serving engine, a separate concern from these appliance images
- Configure the Doorman gateway — configure the inference gateway once your deployment is running
- Authenticate binary downloads — verify a downloaded image's signature before booting it
Known limitations, as shipped (2026-08-03)
- No automated update mechanism — a configuration change means a rebuild and a full image replacement, not a live edit.
- The published images have not been through a customer-scale security review; treat as an early release.
- Real GPU-scale training requires your own Yo-Yo compute backend — the images themselves don't include one.
See also
- Deployment patterns — gateway configuration patterns and deployment topologies
- Edge deployment and boundary ingest — edge instance architecture and connectivity model
- PointSav software distribution substrate — how signed binary releases are delivered
- Authenticate binary downloads — verify a release before running it
- Configure the Doorman gateway — wire up the inference gateway after the deployment is running