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 — boot the
os-toteboxandapp-orchestration-slmappliance images under QEMU - Deploy a knowledge instance — serve a documentation, projects, or corporate wiki from a local content path
Wiring up inference
- Configure the Doorman gateway — set Tier A/B/C endpoints through environment variables, no config file
- Run local SLM inference — start the local model and submit a request through Doorman
What this is not
This page is not a substitute for reading the linked guides — each one carries its own prerequisites, verification steps, and rollback procedure that this page doesn't repeat. It does not cover day-to-day platform operation once a deployment is running (pairing devices, issuing tokens, scaling access) — those guides stay in How You Run It until they get the same category treatment in a later pass.
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