Engineering blog

One post per advanced topic

The marketing pages promise that publishing is a merge. These posts explain the mechanisms behind that promise: what we hash and why, which cache lies to whom, why invalidation uses a separate identity, and which cloud constraints shape the service. Condensed, readable top to bottom, and candid where the boundaries matter.

Every claim here matches the internal hosting contract. Cloud and git platform names are real; only the company around them is invented. Where something is planned rather than running, the post says so.

Index by feature

Feature	Post
One repository per hostname, two tenant secrets, stable origin paths	Onboarding
Apex and dashed-preview formulas, global uniqueness, redirect inventory	Hostnames
Externally managed zones, two provisioning applies, visitor TLS policy	DNS and TLS
Immutable project UUID, hostname folders, path-scoped blob modification	Project prefix
Transparent and passthrough hashing, dated names, 100-path limit	Fingerprints
Browser revalidation, four-week edge retention, upload order, parallel SHA-1/404 verification	Cache
Durable purge queue, route-backed hostname authorization, path compaction, and manual full-host recovery	Invalidation
Dropped pages and folders, pre-mutation recovery state, one-request compaction beyond 100 paths, and public 404 proof	Durable removal
Tenant uploader versus stack purger, immutable claims, tested tag pins	Workload identity
Managed certificates, two TLS hops, 307 redirects, public-origin limitation	Edge and origin
Planned two-week storage deletion threshold, same-day hard stop, current seven-day soft delete	Storage lifecycle
Source-SHA-addressed adaptive image compression, current-output reuse, responsive fallbacks, dynamic modern-format loading	Images

Prefer pictures first? Follow the publish path, shared-site model, and stale-edge recovery on How it works.

First the repository. Then the cloud.
Why a site starts with visible git, receives two secrets, and keeps one stable origin path.
A hostname is a promise we can account for
One-to-one repository names, safe preview formulas, collision checks, and redirects that remain in inventory.
Sometimes the right DNS automation is a handoff
A short record sheet, two applies, managed certificates, and no subscription access for the DNS operator.
One quiet UUID holds a site together
The join key between identity, storage, and routes—and the boundaries it does not create by itself.
Give changing files new names
Content hashes, deploy dates, rewritten references, and a deliberately small set of durable URLs.
One response, two very different caches
Why browsers revalidate pages while Front Door holds them, and why production cannot refresh preview.
Why cache invalidation became its own service
The endpoint-wide permission gap, the trusted workflow, platform-owned route proof, and durable retry queue.
A deleted page needs a durable goodbye
How files and virtual folders that disappear from git are recorded before mutation, removed from origin, purged at every public cache key, and proved absent.
Upload and purge should never share a badge
Two workload identities, immutable subject claims, and the nested-workflow pinning limit.
What Front Door gives us—and what it does not hide
Managed domains and global cache alongside the candid limitation of a publicly reachable static origin.
Cache purge is live. Storage lifecycle is next.
Why immediate edge invalidation and eventual deletion of old fingerprinted blobs solve different problems on different clocks.
Beautiful images, without making hosting depend on them
Source-SHA-addressed compression for each display width, unchanged-output reuse, dependable HTML fallbacks, and dynamic modern-format loading.