Skip to content

PATTERN Cited by 1 source

Phased CDN rollout — passthrough → managed → auto

Phased CDN rollout: passthrough → managed → auto is the pattern in which a CDN launches a new protocol-level feature in three cumulative phases, each phase absorbing more of the implementation cost from the customer.

The three-phase progression is:

  1. Phase 1 — Passthrough. CDN forwards the new protocol's headers / encodings without modification, and makes sure caching is correct. Customer implements the protocol at origin. The CDN is a transparent conduit.
  2. Phase 2 — Managed. Customer configures a rule or high-level declaration saying "this asset class should participate in the new protocol." CDN implements the protocol's lifecycle, the customer's origin keeps serving ordinary responses. The CDN is a stateful intermediary.
  3. Phase 3 — Automatic. No customer configuration. CDN detects candidate URLs, generates the protocol's state, validates the benefit (often via RUM-validated selection or equivalent feedback loop), and turns the feature on. The CDN acts without being asked.

Canonical 2026 instance

Cloudflare Shared Dictionaries for RFC 9842: Compression Dictionary Transport:

  • Phase 1 passthrough — active development 2026-04-17, open beta 2026-04-30. Cloudflare forwards Use-As-Dictionary, Available-Dictionary, dcb, dcz unmodified; extends cache keys to vary on Available-Dictionary + Accept-Encoding. Advanced customers run their own dictionary lifecycle (e.g. via pmeenan/dictionary-worker).
  • Phase 2 managed dictionaries — unscheduled. Customer sets a rule naming which assets serve as dictionaries; Cloudflare handles header injection, dictionary-byte storage, on-the-fly delta compression, per-client variant selection. Origin serves ordinary responses.
  • Phase 3 automatic dictionaries — unscheduled. No customer action. Network detects URL patterns where successive responses share most content but differ by hash; auto-stores previous version as dictionary; auto-delta-compresses; validates benefit via RUM beacon before serving.

See sources/2026-04-17-cloudflare-shared-dictionaries-compression-that-keeps-up-with-the-agent.

Why this shape

  • Accessibility gradient. Phase 1 serves advanced customers (already have engineering bandwidth); Phase 2 serves customers who know what they want but not how to build it; Phase 3 serves the long tail that would never turn on anything requiring configuration. Each phase widens the addressable population.
  • Risk minimisation. Phase 1 is low-risk for the CDN — it's a conduit, can't break what the customer isn't already doing. Phase 2 introduces state management and variant storage. Phase 3 introduces inference about customer traffic (which URLs are versioned, which dictionaries are safe) — the hardest risk profile, which benefits most from the validation loops the earlier phases surfaced.
  • Feedback-loop substrate. Running Phase 1 at scale gives the CDN traffic observability it needs to power Phase 3: which URLs produce compression wins, which dictionaries get hit, which client populations upgrade between deploys. The feedback signals from Phases 1 + 2 are the training data for Phase 3's heuristics.

Why customers accept the phasing

  • Immediate Phase 1 value for the subset willing to build origin-side.
  • Clear commitment to Phase 2/3 — customers can adopt Phase 1 knowing the CDN will eventually take over the hard parts.
  • No regression risk — each phase is strictly additive. Customers on Phase 1 don't lose anything when Phase 2 ships; they can choose to migrate or stay.

Sibling instances on the Cloudflare wiki

The pattern recurs across Cloudflare feature launches where the protocol touches every layer:

  • Workers AI ship path: customer brings their own origin-served model → Cloudflare-hosted managed-model catalogue → auto-routing across providers (analogous multi-phase accessibility gradient).
  • HTTP/3 / QUIC rollout: edge termination → auto-negotiation with clients.
  • Bot management / verified bots: customers add rules → Cloudflare curates verified-bot categories → Cloudflare applies default policy at the category level.
  • PQC TLS: passthrough (customers bring hybrid KEM support) → managed (Cloudflare terminates with hybrid KEM) → automatic (default-on PQC negotiation for eligible clients).

Seen in

Last updated · 200 distilled / 1,178 read