The whole system, part by part

Everything a learner needs runs on their own machine, and keeps working with no network once an image and a lab are downloaded. The server exists for what a client must not do alone: keep accounts and ratings, run the consultant on its own Ollama, carry live sessions to viewers, and serve the site. It calls no hosted model. It is one Docker Compose project on one machine — no cloud provider's services, no Kubernetes.

A golden image is the distribution's own cloud image plus a baseline applied by Ansible: every package the track needs, a serial console, a persistent journal, shell history written after every command. Nothing is installed while you work, which is why a lab runs on a plane. The keys below are the lab screen's.

c copies the lab's check scripts into the guest, runs them as the grading account with a 30-second timeout each, deletes them, reboots the machine, waits for SSH, and runs them again. A check counts as passed only if it passed both times. If the machine never comes back, every check fails with the tail of the serial console as evidence — which is exactly what you want to read when a boot stops in emergency mode.

x is the same run without the reboot: feedback while you work, and it can never mark a lab passed. w repeats it every couple of seconds in a side panel. Persistence is the thing being taught.

This runs in CI for every lab a change touches and every base image the lab supports, and for every lab when the runner, the engine, the image registry or the baseline role change. It is the reason the labs can be trusted, and the reason an upstream change that quietly breaks a lab shows up as a red build instead of a bad afternoon.

Two accounts, one machine, and a line between them. The learner's account is what the lab says it is — an exam simulation gives it no sudo. The grading account is created before the clean snapshot, has its own key and its own sudo, and is the only one the engine uses. No host directory is mounted, no port is forwarded, no agent is forwarded.

The claude track runs in a container with the real Claude Code, and nothing in it talks to Anthropic. The launcher on the PATH points Claude Code at a scripted Messages API on loopback — the same stand-in the CI rehearsal uses. A check writes the model's side of the conversation: delete this directory, read that token, call this MCP tool, never stop. Claude Code does everything else for real, and the check grades what it did.

Four jobs use a model and four do not. Each Claude job is started by an event, runs headless with a turn cap and an explicit tool list, and has its output applied by a script rather than by the model. Measured on real runs: a triage label costs under half a cent, release notes two cents.

One Ubuntu 26.04 machine, bootstrapped, hardened and configured by Ansible, running one Docker Compose project. Only Caddy publishes ports. The API is stateless — everything it keeps is in PostgreSQL or Redis — so a restart, a second worker or a rolled-back image loses nothing.

Anything that runs on a learner's machine can be read by that learner, so an answer cannot be shipped and then hidden. The catalogue is split instead. Unrated labs and banks live in this repository — faults, checks and solutions in the open — and run offline. Rated ones live in a private repository attached as the rated/ submodule: GitHub shows the folder and the pointer, not a byte of content, and a plain clone simply leaves it empty.

A rated attempt is issued by the API with a nonce and a short-lived key. The guest receives what to break and which facts to collect, never the criteria those facts are compared against; checking signs the facts from both sides of the reboot and sends them back, and the server decides. The answers never enter the published API image either — they reach the server beside the container, mounted read-only.

The honest limit: whatever is delivered into a VM you control can, with effort, be read out of it. This raises the cost of cheating a long way; it does not make it impossible. Today every lab in the catalogue is unrated. The full write-up.

Four places, and each holds only what belongs there. PostgreSQL keeps everything that must survive; Redis keeps only what may be lost — a lost key costs a reconnect or a cold cache. The schema is plain SQL applied on every start under an advisory lock, and a column holding data is never renamed or dropped, which is what lets an older API image run against a newer database during a rollback.

GitHub, and nothing else — no password to steal, no email to keep, no registration. GitHub is asked who someone is; the answer kept is GitHub's numeric user id and the login beside it, and the GitHub token that carried it is revoked at once and stored nowhere. A terminal uses GitHub's device flow through the API, so no GitHub token ever reaches the learner's machine and the API never has to trust a token another app obtained. The site uses the web flow and gets back only a one-time code, in the URL fragment, after checking its own state. The server keeps the SHA-256 of each of its tokens, never the token; revoking one deletes a row.

P on a lab records the shell and publishes it. The recorder flushes a batch every couple of seconds; the API stores it and publishes it; every viewer's server-sent-events stream forwards it. A viewer subscribes before reading what is stored, so nothing published in between is lost, and a late viewer replays from the first frame.

Four agents, separated by what they are allowed to know. The separation is enforced in code, not in a prompt: the tutor's request model has no field for the reference solution, and the guard that filters every reply is a different component from the model that wrote it. Nothing a model says is executed.

The API is also a Model Context Protocol server, at /mcp: the docs search, the catalogue, a lab's briefing and first two hints, journals without their walkthroughs, the boards, a quiz that asks the user rather than the model — and, with a token, the account's own progress. It speaks the 2026-07-28 revision statelessly, so any worker answers any request. The API is its OAuth 2.1 authorization server, and an mcp token opens this server and nothing else.

The consultant answers questions about Norboten from Norboten's own text. Retrieval is BM25, not embeddings: the useful terms in this corpus are exact ones — lvextend, fstab, restorecon — which lexical ranking finds better, for free, with no vector database and a score anyone can explain. The model is the server's own Ollama, and the call runs off the event loop.

Every executable question in the repository's banks runs in CI. New ones are drafted on a maintainer's machine, on a Claude subscription: no draft goes into a bank until other models have solved it blind, a critic has failed to find a second defensible answer, a container has printed what it claims a program prints — and a person has read it. A learner can draft practice questions of their own the same way, with g on Theory.

Content is written with norboten-author, a Claude Code plugin this repository publishes as its own marketplace. /norboten-author:idea takes an idea, decides whether it is a lab, theory questions or a journal, and asks only what the specifications need and the idea leaves open, with a default for each. After a yes to its plan, the work runs in the same session, where the author steers it, or in a subagent that returns a draft — the questions always come first, because a subagent cannot ask them. Nothing is done until the repository's own checks say so: a hook lints every edited lab, and the gate, the question pipeline or the journal linter has the last word.

The Analytics page is drawn from the attempts table: nightly on the server, from the sample population when the site is built. How labs, topics, banks and journals relate is computed rather than curated — deterministic, explainable, and needing nothing a relational database and scikit-learn do not already do.

GitHub Actions does all of it. A pull request proves the code, the specs and every touched lab; a push to main tests against real PostgreSQL and Redis, builds the API image and the site, and rolls both out over SSH. A rollout that does not become ready rolls itself back.