A small catalog beats a blank subscription

🧰What we provide

Included	Why it is deliberate
A repository in our organization, one per hostname, with our reusable deploy workflow	If we host the bytes and the edge, we cannot be blind to the pipeline that fills them.
A workload identity with federated credentials for that repository	No secrets to rotate, no shared login, and teardown removes it cleanly.
Visitor files under $web/<PROJECT_ID>/<fqdn>/public/ with workflow state beside them	A fixed Front Door origin path, plus durable deployment and purge state outside the tenant's routed subtree.
Front Door custom domain, route, managed TLS, the cache split, and platform-run invalidation	Authors should not be designing cache policy for a shared endpoint.

🚧What we do not provide

• Your registrar or nameservers — and no promise that we can write your zone, even inside the same organization.
• A dedicated storage account, multi-region origin, a web application firewall you designed, or bring-your-own certificates from a tenant workflow.
• Route changes, per-commit origin paths, or cache-purge rights on the upload identity.
• A second production hostname inside one site. That is another repository and another prefix.

🏘️Multi-tenancy, stated plainly

Many named sites share one storage account. The proposal separates fixed Basic envelopes, expandable Intermediate reservations, and maximum Dedicated reservations. Each site receives a distinct storage prefix; attribute conditions restrict uploader mutations, while platform identity alone holds edge rule and purge authority.

That last point is the interesting one. Purge permission in Azure is granted at the endpoint, while the list of domains is a field in the request — so any identity able to purge could name a neighbor. We withhold that permission from tenants and authorize the caller repository plus requested FQDN from platform-owned custom-domain and route inventory. Tenant-writable storage folder names do not count as proof.

📈How it scales past this demo

The awkward case is normal: a zone run by another business unit, a delegated subdomain, an affiliated domain someone else operates. Three provisioning flags cover it — whether a site is a zone apex, whether we may write that zone at all, and whether the other team has published the ownership record yet.

When we are not authoritative, provisioning still creates the domain and produces the validation record, then pauses. Your DNS operator installs a TXT record and a traffic record from a one-page sheet. They never need a cloud login, and we never wait on a portal invitation.

🧾Cost of ownership, honestly

Onboarding is one provisioning run plus two repository secrets. Ongoing work is close to zero for content teams: certificates renew themselves, cache policy is ours, and a manual Purge all dispatch can recover one typed, provisioned FQDN without giving the uploader edge permission. Automated storage lifecycle cleanup is planned, limited to public/ and guided by state/version.txt; it never sweeps unfinished purge queues. Until that feature is active, old fingerprinted blobs remain available at origin.

What it costs you is flexibility. If a team wants its own storage account, its own firewall rules, or its git somewhere we cannot see, this is the wrong product and we will say so early.

“I own the budget, not the YAML. One hostname, one repository, and we did not buy a second origin just to serve www. I have not been paged about certificates.”

— Dana R., product owner. One of our hypothetical reviews.

Next: how sites and prefixes divide up, DNS we are not allowed to write, cache as a product decision, or the full blog index.