Outlier Static Site

The static marketing site for Outlier. index.html is hand-written; the ~60 pages under seo/ are generated by _seo_build/scripts/render.py from CSVs in seo/_data/.

Serve locally with:

python -m http.server 8000

Then open http://localhost:8000.

Deployment — read this before changing anything about hosting

This site is NOT served by GitHub Pages. The previous version of this file said it was, and that sentence cost a session real work: acting on it, a careful and correct-looking _config.yml was written to stop the build tooling being served, and it was wholly inert. It had to be reverted.

Verified by asking the server rather than reading this file:

$ curl -sI https://outlier.host | grep -i '^server\|^x-service'
server: openresty
x-service: pixie-sh

The GitHub Pages API also 404s for this repository. The whole repo is synced to the host, and path exclusion lives in the host configuration, outside this repo — _config.yml, .nojekyll and exclude: lists have no effect here.

Deploys go through next — push there, never to main

Porkbun deploys main the moment it moves, so main is the gated branch:

1. Push your commits to next (git push origin HEAD:next, after rebasing onto origin/main).
2. .github/workflows/gates.yml runs every gate on that exact commit.
3. Only if all of them pass, its last step fast-forwards main to that commit, and Porkbun deploys it.

A red gate leaves main where it was: the site keeps serving the last commit that passed. Fix it on next and push again. If main moved some other way, the promote step refuses (not a fast-forward); rebase next onto origin/main.

The local half is scripts/githooks/pre-push, installed per checkout with git config core.hooksPath scripts/githooks. It refuses a direct push to main, and runs claim_freshness_gate and faq_schema_visible_gate on a push to next.

The honest limit. Nothing on GitHub stops a push to main: there is no branch protection. git push --no-verify, or a push from a checkout or a machine without the hook, still reaches main and goes live. CI still runs the gates on such a push and shows red, but after the fact. Closing that needs GitHub branch protection on main (with the workflow allowed to push it), a change to the repository's settings that has not been made.

How long a change takes to reach a visitor, and the one that never does

Measured 2026-09-07, twice, on two different paths: a push is still serving the OLD copy at ~7 minutes and is live by ~11-12. The home page pushed 19:08:59 was stale at 19:16 and live by 19:20; a root .txt pushed 19:18:17 was stale at 19:25 and live by 19:30. So when a gate says the deploy is behind, give it twelve minutes before believing it.

A DELETION NEVER PROPAGATES BY ITSELF. The edge (openresty / x-service: pixie-sh, Porkbun static hosting) serves stale while revalidating and treats the origin's 404 as an error to keep serving stale through — proxy_cache_use_stale behaviour. Measured: a file deleted from the repo still answered 200 with x-cache: STALE fifty-five minutes later, while ?cb=<random> and Cache-Control: no-cache both returned 404 from the origin.

So to unpublish something here, replace its contents; do not git rm it. A 200 revalidates successfully and the edge takes the new body. Removing the file puts the edge straight back into stale-on-404, holding the last 200 it saw, indefinitely.

Verify with a PLAIN GET. Busting the cache asks the origin, which is not what a visitor, a crawler or a verifier sees, and it will tell you the deletion worked when it has not.

⚠️ 67223b34aed54ecb802e8ffcbacb9ec2.txt must STAY in this repo. It is a superseded IndexNow key file whose body is now revoked, which is what makes the old key stop validating. Deleting it would return the edge to serving the original body — the key — with no way to clear it from here. It looks like dead weight; it is a live control.

The consequence that matters

Every tracked file in this repository is readable over HTTP. There is no second line of defence. scripts/, .github/, _seo_build/ and .gitignore are all servable, and internal notes committed here have twice been published at outlier.host/<filename> before anyone noticed.

So: the contents of every tracked file must be safe for a stranger to read — including docstrings, test fixtures, error strings and sample data. A prose cleanup is not enough; a sanitised docstring once shipped alongside a fixture ten lines below that still quoted the internal line verbatim.

scripts/no_internal_docs_gate.py enforces this and is the only thing enforcing it. CI runs it, along with nine other gates, on every push and hourly.

Gates

scripts/*_gate.py — ten of them, all run by .github/workflows/gates.yml. They check download URLs against the current release, checkout links, link and asset resolution, the offline proof and its control, deploy freshness against HEAD, live-status badges, the word floor, internal docs, unstyled classes.

Note what they do not cover: every one reads what a page says. None can see spacing, contrast, rhythm or whether anything renders legibly. Those need eyes and measured geometry from a real browser.