Self-HostingIndex
Self-hosting means running platform components on infrastructure you control rather than a hosted instance — booting the published seL4 appliance images, standing up the wiki engine against your own content, and wiring the inference gateway to your own hardware. Every component here degrades gracefully rather than refusing to start: a deployment with only one piece running is still a valid, useful deployment.
Start here: Self-host a deployment — boots the two independent seL4 appliance images (os-totebox, app-orchestration-slm) that everything else in this category runs on top of.
Getting the platform running
- Self-host a deployment — Boots the published os-totebox and app-orchestration-slm seL4 appliance images under QEMU, with configuration baked in at build time via device-tree bootargs, and verifies both come up healthy.
- Deploy a knowledge instance — Deploys an instance of app-mediakit-knowledge from a local content path: write a knowledge.toml [site] + mount configuration, build the binary, and start it with the serve subcommand.
Wiring up inference
- Configure the Doorman gateway — Configures a single-instance Doorman gateway via environment variables — Tier A local endpoint, optional Tier B Yo-Yo burst compute, optional Tier C external providers — and verifies tier state through /readyz.
- Run local SLM inference — Starts the local Tier A SLM service, verifies Doorman readiness, and submits an inference request from the console or the API, with all prompt data staying on the deployment.
Each guide carries its own prerequisites, verification steps, and rollback procedure; this page doesn't repeat them. Day-to-day operation of a running deployment is in How You Run It.
See also
- How You Run It — the remaining day-to-day operational guides
- Where It Runs — the architecture these guides deploy against
- Security and Trust — the identity and permissions model self-hosted deployments participate in