Why we publish this
We argue that teams should not hand their most valuable data to a third party and hope the contract holds. Making that argument while running a careless website would be unpersuasive, so here is our own homework, in enough detail to be checked.
One thing to say plainly first. This is a marketing site. It holds no player data, no medical records and nothing commercially sensitive, so it is the easy version of the problem. Anyone can run a few DNS queries and see that it is served from a cloud provider rather than a rack we own. Pretending otherwise would be silly. What it does demonstrate is the discipline, and the discipline is what carries over to work that does matter.
Every domain, configured properly
We hold 34 domains. All 34 are signed with DNSSEC and anchored at the parent registry, verified by computing the digest from the key currently serving each zone and requiring an exact match on key tag, digest type and all 64 hex characters. Algorithm 8, digest type 2.
All 34 resolve over both IPv4 and IPv6, and all 34 present a valid certificate. That last point matters more than it looks: only two of them serve the site, and the other 32 return a permanent redirect to the canonical host. A redirect is sent after the encryption handshake completes, so a domain with an expired certificate fails to connect rather than redirecting quietly. A domain that serves nothing still needs its certificate to be current.
Both of those checks live in our infrastructure repository as reports that get re-run, not as claims someone made once. When we changed the redirect behavior, the report was regenerated from live probes the same day, because a status document that is not re-run is just a rumour with a date on it.
The page you are reading
It is static HTML in object storage behind a load balancer. There is no application server, no database and no framework, because a brochure does not need one.
- No JavaScript is required to read it. Turn scripting off and every word is still here.
- The fonts are ours. They are served from the same place as the page, so no font provider gets a record of your visit. That is a small thing that most sites get wrong by default.
- One third-party request exists, and it is optional. Analytics does not load unless you accept it. Decline, or simply ignore the banner, and nothing is requested and no cookies are set. The choice itself is kept in local storage rather than a cookie, so it does not travel with requests.
- A missing page returns a real 404. Not a 200 with an apology on it, which is a surprisingly common way to confuse a search engine.
How a change reaches you
Every change to this site is an issue, a branch, a pull request and a cryptographically signed commit. Merging to the main branch triggers a job that mirrors the directory into storage and clears the cache at the edge, so what you see is what is in version control, usually within a minute.
No deployment credential is stored anywhere. The build proves its identity with a short-lived token issued for that single job, exchanged for temporary cloud credentials that expire on their own. There is no key in a settings page to leak, and no secret in the workflow file. If you are wondering whether that is worth the effort for a three page website: the same mechanism is what we would use to move a team's data, and it is easier to get right once than to retrofit.
What this does not prove
Plenty. A static site with no user accounts, no personal data and no uptime obligation is a soft target for a page like this. Nothing here demonstrates handling medical records, running compute inside a stadium on game day, or keeping a season of tracking data safe for a decade.
It does show what we consider normal: check the thing rather than assume it, write down the result, re-run it when the world changes, and do not quietly leak your visitors to third parties because it was the default. If that is the standard you want applied to your own data, get in touch.