Architecture

Architecture

Three moving parts: content as files in git, an editor that runs entirely in the browser, and a static build that goes live by swapping a symlink. Each exists for a specific reason.

Content is files, in their own repository

There is no database. A page, post, author or navigation menu is a file with structured metadata at the top, validated against a schema that both the build and the editor import from the same place — so there is exactly one definition of what a valid page is.

Content lives in a repository separate from the code. The reason is blast radius, not tidiness: the editor can write to the content repository and to nothing else. The code, the build configuration and the deployment automation are never editor-writable.

The editor is WordPress, in the browser

Editors work in `wp-admin`. That `wp-admin` is not served by anything — it is WordPress Playground, a WebAssembly build of WordPress running inside the browser tab, booted fresh each time.

Because it is genuinely WordPress, the editing experience is the familiar one. Because it is ephemeral and client-side, it holds no data and enforces no permissions. Editing is a round trip rather than a live save: existing content is loaded into the editor, a person works on it, and on save the result is written back out as files.

The block palette is restricted to the types the schema can represent, and the styling controls are removed. This is a content-quality mechanism, not a security one — the real boundary is what the editor is allowed to write, and what a human has to approve.

The build is static

The site is built to static HTML. Links between pieces of content are resolved at build time, and a link that cannot be resolved fails the build rather than shipping as a broken href. A single flag decides whether draft content is included, which is the entire difference between a preview build and a production one.

How a change reaches production

1. An editor signs in and starts a change. A branch and a draft pull request are opened immediately, before any editing.
2. They edit in `wp-admin` and save. The save writes the changed files as one commit.
3. That commit triggers a preview build. The change gets its own site, at its own address.
4. They send the change for review. A person reads the file changes and the preview.
5. Publishing merges the change, which triggers a production deploy.

Deployment

A deploy builds into a fresh, timestamped directory, verifies the result, and only then swaps a symlink to point at it — a single atomic operation. A build that fails never becomes live; the previous release keeps serving, untouched. Rolling back is the same mechanism pointed at the previous release.

The server runs no PHP, no WordPress and no database. It serves static files and two small services: one that exchanges sign-in credentials, and one that receives notifications about changes.

The pieces, and what each is for