Walkthrough

A change goes live

A commit lands on main, and with no one running a deploy, the live site changes. This Walkthrough follows that commit from the container's side: from noticing it, through the install and the build, to the restarted server that answers the next visitor.

A commit lands on `main`

The commit is a merged PR, or a , which lands without one. Both take the same road from here: a blog post, a session log and a code fix all go live through the same pull, build and restart.

LessonPull requests
LessonSession logs

The container notices it

The script that runs the container fetches main again after each pause. When origin/main differs from its checkout, it resets the checkout to the new commit. It doesn't wait for CI: the Gate also runs on every push to main, but nothing in the container reads the result.

Packages, only when the lockfile changed

The script compares a hash of pnpm-lock.yaml with the hash it saved after its last good install. Only when they differ does it install packages again, from the lockfile exactly. If that install fails, the previous build stays live, and the next commit installs again.

Lessonpnpm and the lockfile
LessonContinuous deployment

The build runs beside the live site

The build runs in the checkout, beside the live server, which keeps answering. It writes .output/: a server that runs on its own, with the content inside. If the build fails, nothing is swapped, the old build stays live, and the next commit tries again.

The swap

The script copies the new .output/ over the folder the server runs from, stops Node and starts it again from that copy. In the short gap while the new server starts, the site doesn't answer.

LessonContinuous deployment

The next visitor gets the new content

The restarted server serves the new build. The first query for each Collection compares its table's checksum with the build's and, where they differ, restores the table from the new dump.

LessonContent database

A real case

On 9 October 2026 an agent checking a diagram of this story against deploy/entrypoint.sh found a gap in stop 3: the script moved its checkout to the new commit before installing, so after a failed install the next commit's lockfile hash already matched, the install was skipped, and the build ran on the old packages. It filed issue #1701; the case had not happened on the live server yet. PR #1717 made the script keep the hash of its last good install outside the checkout. Its description said no test covers the script's behaviour, so a human had to merge it, and a Trusted user did at 05:53 UTC on 10 October.

Where next

Last updated 1 Nov 2026 · Latest source on GitHub ↗