Basic packed slot
Optional static live+preview, or one optional redirect-only live FQDN with one whole-host 307.
Place in standard-n / first free slotCommunity feature proposal
Start with one lot. Reserve more room as the site grows.
Basic is a tiny fixed envelope with two mutually exclusive uses: reserved optional live + preview static sites, or one optional live FQDN whose complete tree performs one whole-host 307. Intermediate guarantees an expandable reservation. Dedicated is simply that reservation at the profile maximum.
The proposed boundary
50 Basic envelopescontent pair or one whole-host redirect
Expandable reservationbuy unreserved room without moving
Maximum reservationDedicated holds all usable shard capacity
0 blob movesduring every tier migration
Why this proposal exists
Known capacity can be packed; variable capacity needs a boundary
Live plus one optional preview has a fixed shape: the Basic slot reserves two domains and two routes even when preview is not published. Variable requirements can enter an Intermediate shard under a guaranteed Intermediate reservation or take the maximum Dedicated reservation. Every later placement change is a deliberate migration.
Intermediate shard
Extra hosts and namespaced rules grow inside capacity reserved for this tenant.
Expand in place—or reserve a larger lot before movingDedicated Standard
One centered tenant reserves every usable dimension of a separate fixed-size profile.
No later capacity-driven shard move
What do you think?
Is “minimum lot, expandable reservation, or maximum reservation” understandable before onboarding? Share concerns through your usual platform-team channel.
The proposal in one screen
Read this context before voting
The voting tree later on repeats only the decisions explained here: Basic, Intermediate, Dedicated, explicit migrations, and stable allocation.
Basic packed slot
One tenant gets one fixed envelope in either content mode (optional static live+preview) or redirect mode (one optional redirect-only live FQDN).
- 50 fixed envelopes per Standard profile
- Up to two domains/routes plus one tenant rule set reserved
- Only redirect mode uses its one fixed whole-host 307 rule
Intermediate shard
Every tenant begins with the same minimum lot, then can reserve more of the shard’s still-unreserved capacity.
- The reservation is guaranteed and never silently shrinks
- Chargeback is lot size plus utilities; unused fenced room is still billed and cannot be sold to a neighbor
- A larger lot that cannot fit is reserved elsewhere before migration
Dedicated Standard
Dedicated is the same reservation model set to every usable dimension of one Standard profile, centered on one tenant with no internal lot boundaries.
Review Dedicated capacity →Stable slot allocation
New Basic tenants take the lowest fully vacant slot. Existing tenants never slide around to compact a shared profile.
- A slot is free only after complete teardown
- One serialized Terraform allocation prevents collisions
- New
standard-nappears only when earlier packs are full
Proposed feature: basic
One inexpensive envelope, two fixed modes
Content mode: live and preview are independently optional. Their two domain/route positions remain reserved even while inactive.
Route ALiverepo-name.example
Route BPreviewrepo-name-preview.example
Redirect mode: one optional live FQDN uses one domain/route and one rule set for a single unconditional /* 307 to one validated https:// destination. It has no preview or origin content.
Unit ALive FQDNwww.example
Unit BWhole-host 307one HTTPS destination
Not Basic: content mixed with redirects, a second redirect FQDN, path-specific/multiple rules, rewrites, headers, cache actions, staging, QA, or a third hostname.
Proposed feature: basic packing
One standard-n shard, fifty fixed Basic envelopes
This is specifically a Basic example. Every envelope reserves up to two domain/route positions plus one tenant rule-set position. The same fixed boundary can hold an active static live+preview pair, live-only or preview-only with its counterpart still reserved, or one live FQDN plus the fixed whole-host 307 mechanism. Intermediate does not use these equal envelopes; it uses explicit multidimensional reservations.
Illustrative inventory: 46 envelopes are allocated: 36 publish live+preview, three publish live only, three publish preview only, and four are redirect-only. Four complete envelopes remain vacant. That is 82 active routes plus 10 reserved-but-inactive domain/route positions, so the allocator has committed 92 of 100. Only the four redirect envelopes deploy their reserved tenant rule set.
Stable allocation
Reuse the first complete hole; never slide the neighbors
- 1Destroy completelyEvery active domain, route, and redirect set leaves the old envelope.
- 2Confirm both viewsTerraform and Azure must agree that the complete envelope is vacant.
- 3Take the lowest vacancyThe next Basic tenant receives the first fully free envelope.
- 4Leave neighbors aloneOccupied envelopes never move merely to compact the cabinet.
Proposed feature: intermediate
Reserve a real lot inside a fixed-size shard
Every Intermediate shard is the same fixed-size Front Door Standard profile. Tenants begin with the same minimum Basic envelope, then may reserve wider multidimensional lots from unreserved capacity. A reservation never shrinks unless the tenant chooses a smaller plan. Being a good neighbor means not warehousing a large unused lot: that empty fence cannot be sold to anyone else, so it reduces the packing efficiency of the whole shard instance.
Every fence is a vector
The reservation covers routes, domains, rule sets, composite route complexity, and enabled policy associations. It is not one misleading “rules” number.
Be a good neighbor
Do not hold a large unused reservation “just in case.” Tenant chargeback is lot size plus utilities, so extra fenced room is billed even while empty. That unused fence also cannot be resold, which lowers packing efficiency for everyone else on the shard.
Expand here, or reserve before moving
If the current shard has enough unreserved vector capacity, the lot expands atomically in place. Otherwise the complete larger lot is held on a sparser/new shard before preview-first verification (when present) and scheduled-live migration.
Dedicated is the maximum lot
Dedicated is not an oversized shard. Its pictured lot has the same total area as one complete Intermediate shard, with one tenant holding all usable capacity—the only option that avoids every future capacity-driven shard move.
Chargeback is lot size plus utilities
Tenant chargeback is lot rent priced from the reservation vector (current use plus extra reserved) plus metered utilities for traffic, requests, stored bytes, and storage operations. Releasing unused fence returns capacity to the shard and lowers that tenant’s lot rent because the lot got smaller. A future bill must reconcile hostname/project telemetry to the actual Azure invoice rather than present estimates as exact tenant charges.
Proposed feature: dedicated
The final reservation is the whole shard
Intermediate and Dedicated are one reservation continuum. Intermediate holds a fenced, guaranteed lot inside a shared fixed-size shard. Dedicated places one tenant on an identical profile and reserves its complete usable capacity vector after platform-owned capacity. The Azure limits and service contract do not become larger; only the internal co-tenant boundaries disappear.
Same vector, set to maximum
Domains, routes, rule sets, composite route complexity, and policy associations remain the dimensions. The reservation reaches each usable profile limit rather than inventing a larger tier.
One tenant boundary
Live, preview, staging, QA, experiments, and namespaced rules may occupy the one reservation as admitted. There is no neighboring tenant allocation inside it.
The last capacity-driven move
A neighbor can no longer block an expansion, so Dedicated is the only placement that cannot require another move solely to obtain a larger reservation.
Pay for room; meter utilities
Dedicated chargeback is a maximum-size lot rent plus the same metered utilities. Requests, transfer, stored bytes, and storage operations remain separately measured.
Dedicated changes placement, not migration
The maximum lot is a destination size, not a shortcut. The platform still recreates the current service unchanged, transfers the exclusive hostname, and keeps the source reservation through soak. Only after that sequence may the tenant use its additional room.
Proposed feature: explicit growth
Move the whole service unchanged; grow only after it lands
A tenant moves because its current lot cannot hold the
requested reservation. The destination lot is larger, but migration does
not change behavior: every currently valid domain, route, rule
association, cache policy, origin path, and environment moves as one
service inventory. The new feature that triggered growth remains pending
until that same service is stable on the target. Repository,
PROJECT_ID, uploader identity, and blobs stay where they are.
Capacity gate
Hold the larger destination lot
Platform and operations
Serialize allocation, reserve the complete target vector, retain the source reservation, inventory every active edge object, and capture a source-health baseline.
What users experience
Nothing changes. The source shard keeps serving the last valid configuration; the requested growth remains inactive.
Why this phase exists
Capacity must be guaranteed before touching service. It prevents a half-built move and avoids displacing target-shard neighbors.
Exit condition
Target reservation is durably held, source and target generations agree, and the complete migration inventory is frozen.
Equivalence gate
Recreate the same service and verify it
Platform and operations
Recreate origins, routes, rule associations, cache behavior, and environments against the same immutable storage paths. Test through a platform hostname and transfer preview first when one exists.
What users experience
Production still uses source. Owners compare target status, bodies, redirects, headers, and cache behavior; preview may undergo its own non-production handoff.
Why this phase exists
Separating placement from feature change makes failures diagnosable. The target must prove it serves the same site before receiving live traffic.
Exit condition
Automated comparisons pass, route health is green, and the customer accepts the unchanged target behavior.
Exclusive hostname gate
Schedule and hand off live
Platform and operations
Offer evidence-backed quiet windows when exact-host logs are representative; otherwise use a clearly labeled manual window. The customer confirms, and DNS TTL cools for at least one old TTL before cutover.
What users experience
Source serves until release. During the unique-domain, TXT, certificate, route, and DNS handoff, requests may be interrupted; managed-certificate deployment can take minutes to an hour or longer.
Why this phase exists
Front Door cannot bind the same custom domain to both profiles. Target-specific TXT proof and managed TLS cannot be completed before target-domain creation.
Exit condition
The public FQDN has valid TLS, returns the expected body or Location through target, reports healthy routing, and appears in target access logs.
Rollback gate
Soak, free source, then grow
Platform and operations
Keep the low TTL and complete source reservation while monitoring public responses, TLS, route health, logs, deploys, and purges. Rollback is a full reverse ownership and certificate handoff—not a CNAME flip.
What users experience
Traffic uses target with unchanged behavior. The growth request remains pending until the soak is accepted; failures trigger the documented reverse handoff.
Why this phase exists
The intact source lot is rollback insurance. Freeing it early would remove the known service inventory before target behavior is established.
Exit condition
Customer and platform accept the observed soak, normal TTL is restored, source edge objects are retired, its reservation is freed, and only then may the target use its empty growth room.
A repository declaration cannot move infrastructure
Unsupported additions leave the last valid service running. The platform allocator performs the unchanged move; the newly admitted capability applies afterward inside the larger reservation.
Proposed feature: custom rules
Rules live only inside a reserved boundary
One redirect today can become a match tree tomorrow. We do not want to promise “five redirects,” watch the file grow, then reshuffle neighboring sites.
Basic supports only one platform-shaped rule: the unconditional whole-host 307 in its redirect-only mode. Intermediate applies path-specific, mixed-content, or other namespaced rules inside its guaranteed vector; a larger change first expands that reservation or offers a pre-reserved move. Dedicated sets the same vector to the profile maximum.
Redirects remain temporary HTTP 307, evaluated before cache and origin. Azure’s per-profile, per-rule-set, per-route, condition/action, and effective-rule accounting still applies.
One reservation, several environment routes
A shared Azure quota model—not one arbitrary quota per environment
Intermediate and Dedicated may give live, preview, staging, QA, and other test hosts their own routes. Rule sets may be shared across those routes or scoped to one environment; each route still obeys Azure’s associated-rule ceiling. The platform validates the complete reservation before apply.
100rule sets per profile
100rules per rule set
100associated rules per route
10 + 5conditions + actions per rule
live307 redirects + security headers
previewpreview-only cache behavior
stagingpath rewrite + shared headers
Examples and limits follow Microsoft’s current match conditions, rule actions, and Front Door Standard service limits. Cache-enabling route overrides can consume extra effective rule capacity.
Simply put
Match a request, then apply one or more edge actions
Conditions can identify an environment hostname, path, extension, query string, header, cookie, method, protocol, client location, IP range, or device type. A tenant may declare a requested rule; platform identity validates and applies the namespaced configuration from a reviewed action set.
Temporary 307 redirect
Match: /old-guides/*
Action: send the browser to /guides/*, preserving the request rather than proxying it.
URL path rewrite
Match: an application route such as /app/*
Action: request a different origin path while the visitor keeps the original URL.
Request or response headers
Match: one environment or content type
Action: add, replace, or remove approved headers—for example security or CORS response headers.
Cache behavior override
Match: /status.json, an extension, or selected query parameters
Action: bypass cache, honor origin, set a different TTL, or control query-string caching.
Incoming request
Platform-applied match rules
307redirect
200static origin
headersfuture proposal
Proposal tree
The same proposal, grouped for lightweight voting
Each collapsible branch below restates one of the three summaries above. The branches start expanded so every proposed item remains visible, but you can collapse them while comparing priorities. Every item uses the same wording as its detailed section and links back to that context. The scores are illustrative—not community results—and your vote changes only this browser tab.
Preview interaction
Votes are not submitted yet. Collapse a branch by selecting its emoji summary; example scores reflect likely platform usefulness.
-
CDN tenant placement
Choose Basic, an expandable Intermediate reservation, or the maximum Dedicated reservation, then use an explicit verified migration whenever placement changes.
-
Basic fixed envelopeOptional static live+preview, or one optional redirect-only live FQDN. 4 voting topics
Basic fixed envelope
A tiny predictable slice supports a static pair or one whole-host redirect.
-
Optional live + optional preview
Reserve two static domain/route positions even while either is inactive.
-
50 fixed envelopes per standard-n
Each safely reserves up to two domains/routes and one tenant rule set.
-
One redirect-only live FQDN
One unconditional whole-host 307 uses the complete Basic mode; custom rules remain Intermediate.
-
-
Intermediate and DedicatedAn expandable shared reservation or the maximum reservation, reached at onboarding or through verified migration. 6 voting topics
Intermediate or Dedicated
Reserve an expandable lot on a fixed shard, or reserve the maximum usable capacity for one tenant.
-
Move the same edge placement, not the data
Probe target, rehearse preview when present, schedule live, verify and soak, then free source.
-
Live + preview + test environments
Intermediate grows them inside its reservation; Dedicated holds the maximum profile budget.
-
Temporary 307 redirects
Path and host redirects before origin, with source-tree cache purge.
-
Custom match/action rules
Reviewed, namespaced rules use an Intermediate reservation or the maximum Dedicated reservation.
-
Azure service maximums
The dedicated profile’s service limits are the product ceiling, not an arbitrary platform quota.
-
-
Stable slot allocationLowest fully vacant slot first; complete teardown; never move neighbors. 4 voting topics
Stable slot allocation
Placement is infrastructure state, serialized and fail closed.
-
Never move neighboring tenants
Reuse complete holes; do not compact occupied slots.
-
Lowest fully vacant slot first
A destroyed slot becomes the next tenant’s slot without reshuffling.
-
Serialized Terraform allocation
One lock prevents two new tenants from choosing the same vacancy.
-
-
Proposed feature: self-service control plane
One authoritative map from project to edge placement
A registry can make placement easy to query, but serialized Infrastructure-as-Code remains the allocator of record. It maps immutable PROJECT_ID to Basic slot, Intermediate shard, or Dedicated profile plus the exact host and route inventory. A generation mismatch between desired state, registry, and Azure fails closed.
Deployments stay least-privileged
Tenant workflows upload only beneath their project prefix. A trusted platform operation resolves the current edge placement for purge and verification; repositories do not receive arbitrary Front Door authority.
A future GitHub App can onboard repos
With explicit installation permissions, an App can propose the standard workflow, set repository variables or encrypted secrets, and ask the backend to provision GitHub OIDC trust. Installation grants repository access—not Azure or DNS authority.
DNS has distinct ownership paths
Platform-managed zones can automate aliases, CNAMEs, and TXT proof. External DNS needs customer action or a separately authorized provider integration. Apex names use provider alias/flattening support; they are not ordinary CNAMEs.
A stable project hostname is optional
A platform-owned prj-<id> name can hide shard endpoints, but it does not remove the Front Door custom-domain transfer. Direct visitor CNAME to *.azurefd.net remains the simplest managed-certificate path.
Request for comments
What would make this useful—or wrong?
Basic shapes
Are optional static live+preview and one redirect-only live FQDN the right fixed, inexpensive choices?
Intermediate contract
Is “your reservation never shrinks unless you release it; chargeback is lot size plus utilities; a good neighbor does not warehouse unused capacity” clear?
Rule support
Which redirects and safe match/action rules would you actually request?
Maximum reservation
When is avoiding every future capacity-driven move worth reserving a complete Dedicated profile?
Migration cutover
What proof and soak should be required before traffic leaves any source shard and its allocation is freed?
Operations
What failure or teardown case should the slot allocator plan for?
Rent and utilities
Which lot-size chargeback rates and metered traffic/storage breakdowns would make costs understandable and auditable?
Help shape the next platform feature
This preview is the discussion starter. Vote on the topics that feel useful, then share the “why,” missing branches, and counterexamples through your usual platform-team channel. The illustrative scores are not collected feedback.