Infrastructure · We run it ourselves
A hosting platform built by the authors of Next.js, where a push to a git branch becomes a globally cached deployment whose per-route cache behaviour is taken from the framework's own build output.
The interesting part of Vercel is not that it deploys quickly. It is that a cache policy declared inside a route file — one exported constant — becomes CDN behaviour without any infrastructure code describing it, and that response headers set in next.config.ts are applied above the framework rather than by it. That second property is not a convenience: on this site, content negotiation is correct in production and cannot be reproduced by running the same build locally, which is the honest shape of the lock-in and the reason the trade is worth stating rather than assuming.
01
The deployment code that is not in this repository is the measurable part of what the platform removes. There is no Dockerfile, no compose file, no deploy script, no reverse-proxy configuration, no certificate renewal and no asset-fingerprinting step. The comparison is on the same disk: the mozg monorepo carries compose.build.yml, compose.dev.yml, compose.override.yml, an infra/docker tree and a deploy.sh, and openclaw carries three separate Dockerfiles including two sandbox variants. Those files are real engineering, they have to be correct at three in the morning, and for this site the entire deployment surface is a push to main plus one build script in package.json.
02
Cache tiering is declared in the route and honoured by the delivery layer, so no part of the application implements it. app/crawler-census.json/route.ts exports revalidate = 3600 and answers with s-maxage=3600, stale-while-revalidate=86400 — a reader is served the existing copy immediately while the recomputation happens behind them. Nothing in the repository holds a lock against two workers recomputing the same aggregate, expires a key, or runs a cron to warm one. On an origin of our own, that same behaviour is a cache store, a lock and a scheduler, all of which can fail independently of the page they serve.
03
Response headers set in next.config.ts are applied by the delivery layer, not by the Next server, and on this site a correctness property depends on it. Every negotiable address has a Markdown twin, which means one URL has two representations, which means the answer must carry Vary: Accept or a shared cache will serve the wrong one. Next 16.2.12 discards a vary header set from proxy.ts and substitutes its own rsc value — a neighbouring Link header from the same place survives, so this is an observed behaviour rather than a preference. Set in the config, it survives, because the platform applies it above the framework.
04
Instrumentation runs at the edge and is kept out of the reader's critical path by the runtime rather than by our own queue. proxy.ts identifies declared automated clients, returns the response immediately, and hands the insert to event.waitUntil, so a failed write leaves the request successful and a human visitor is never recorded at all. The cost is named in the file itself: the site was served entirely from the CDN, and a proxy puts an edge invocation in front of every page request, including every human one, which is recorded nowhere and still pays the hop.
05
The build environment is legible enough to make staleness detectable, which matters because atomic deployment hides it. VERCEL_GIT_COMMIT_SHA is baked into a force-static /version route, so the commit serving the public site is a public fact. This exists because deployment stopped for six days: pushes landed, every build failed on a type error in a file git had never been given, and production kept serving a week-old copy without a single visible symptom. The platform supplied the commit; it did not supply the alarm, and scripts/check-deploy.mjs had to be written to compare that number with the local head.
06
A failing build cannot reach the public, which is what makes expensive build gates affordable. The build command runs check-knowledge, check-schema and check-markdown before next build, so a dangling @id in the structured data or a disagreement between content negotiation and the route table stops the deployment instead of shipping. Because the previous deployment stays live and unchanged, the cost of a wrong commit is a stale site rather than a broken one — the same property that produced the six-day failure above, read from the other side.
07
The analytics that ship with it are cookieless and carry no device identifier, so the site shows a notice rather than a consent wall, and the script is served from an obfuscated first-party path instead of a third-party host. Speed Insights, the platform's paid performance product, is deliberately not connected — the field data it collects is not worth a per-project line item on a site whose pages are pre-rendered and served from cache.
An entry that cannot point at something you can open, run or read does not compile. That is a property of the type, not a promise in a paragraph.
Invariant
Two places where it stops. First, the delivery layer is not reproducible off the platform: the Vary: Accept behaviour that content negotiation depends on is dropped under next start, so a property this site is correct about can only be confirmed with curl against production — the lock-in is not in Next.js, which is portable, but in the fact that no local or alternative host reproduces the response the reader actually receives. Second, the billing is metered per invocation and per gigabyte, so the economics invert exactly when a site stops being static: putting a proxy in front of every page to count crawlers means every human visit is now a billed edge invocation for a row that is never written, and for media-heavy or bot-heavy traffic a fixed-price origin with flat bandwidth is cheaper by an order of magnitude and stays cheap when traffic spikes. It also stores nothing — forms and the crawler census both write to Supabase, so a second vendor is in the critical path for every stateful thing the site does.