How this site runs

Nobody, including me, can push straight to the main branch. Push access is off for everyone, only a maintainer can merge, force pushes are rejected, and a merge is blocked until its own pipeline has passed. Once a merge request lands, its source branch is removed automatically. Every change goes out on its own branch and comes in through a merge request instead, so there's always a record of what changed and why before it ever reaches production.

The commits and merge requests themselves come from Claude Code, an AI coding agent I run against this same GitLab. In this site's repository it works only on its own branches, opens each merge request itself, and merges once that request's own pipeline has passed. Like me, it can't push straight to main there. I decide what gets built and check the results. How I work with AI covers the rest of that split.

Every push to main deploys to a staging environment first, runs a smoke test against it, and only deploys to production once that passes. The smoke test checks that the homepage returns a real 200, that the security headers are actually present, that an unknown path gets a proper custom 404 instead of a generic one, and that every asset the homepage links to actually loads. A request only gets retried when it got no response at all; a real error status has to show up on the first try, because that's a real failure, not a dropped connection.

This gate caught a real bug in its first hour. The staging smoke test got an intermittent 502 during a rolling update: an old pod started shutting down while the ingress was still sending it requests. The pipeline stopped there, before production. I fixed it with a short delay before a pod is told to stop, so the ingress has time to stop routing to it first. Each pod now waits five seconds, inside a fifteen-second shutdown window. The site runs two replicas on a single-node cluster, with a disruption budget that keeps at least one available if a pod gets evicted.

Removing the poll wait and a caching delay on the build record together cut the time from merge to a verified live site from around nine minutes and thirty six seconds down to somewhere around five minutes. The panel further down this page shows exactly how the most recent run did.

The sentinel is a Kubernetes CronJob that reads the nginx access logs out of Loki and scores each client against a handful of fixed rules, which look at probe paths, a surge of 4xx errors and the request rate. There's no model making the call. When a client crosses the threshold, it can create a Cloudflare IP block that expires on its own after a set TTL, with a cap of 10 blocks per run. It also fails closed, so it won't create a block it can't undo later. It ships suspended and in dry-run, and it only starts taking real action once it's switched on by hand with a scoped API token.

Deployed build

This comes straight from /build-info.json, which gets refreshed on every deploy. If that file can't be reached, the panel says so instead of showing old data.

Latest pipeline run

After production is deployed and verified, the last job in the pipeline builds a public, unauthenticated report of that entire run and publishes it the same way as the deploy itself, through the manifests repository. It runs last on purpose, after verification, so the "merge to live" number below only counts a deploy that passed its checks. Before it writes anything, it scans its own output for internal hostnames or addresses and refuses to publish if it finds one, so an unauthenticated report can go out safely with no login in front of it. That report also counts how many of the latest change's commits came from the AI agent, pulled straight from the merge request's own commits, and the panel below shows it.

The report always lists its own job as "running" because the file gets written to disk before that job is marked done. The panel below shows that job as the one that wrote this report, not as something stuck.