Skip to content

PATTERN Cited by 1 source

Config deployment as code deployment

Apply the same staged-rollout + health-gating + automated- rollback discipline to configuration changes that already governs code deployments. The meta-pattern: configuration is deployed; deploys require rollout discipline; therefore configuration rollouts require the same discipline as code rollouts. Organisations that have solved the code plane and left the config plane on rapid-fleet-wide push have a single unsolved blast-radius surface.

The pattern

At a minimum, a mature configuration-deployment system should match the code-deployment system on four axes:

  1. Bundle the change into a package. The rollout orchestrator has a single atomic unit it can advance, observe, and revert.
  2. Progressive rollout by cohort / region / stage. Canary → small cohort → progressive fan-out; the blast radius at any stage is bounded.
  3. Real-time health monitoring between stages. Automated signals gate the next stage's advance. See concepts/health-mediated-deployment.
  4. Automated rollback on regression. Revert without paging a human.

Cloudflare's 2026-05-01 post names the meta-pattern directly:

For products that run on our network processing customer traffic and receive configuration changes, we no longer deploy these changes instantly across the network. Instead, relevant teams have adopted a "health-mediated deployment" methodology, the same we use when releasing software, for all configuration deployments.

The "same we use when releasing software" clause is the pattern's one-line articulation.

Why the config plane tends to lag

Organisations often ship the code plane's rollout discipline first because code is the headline artifact. Config inherits a rapid-fleet-wide-push channel for two legitimate reasons:

  • Threat response. DDoS mitigations, zero-day WAF rules, malicious-IP blacklists — the rapid channel is required for minutes-matter scenarios. See patterns/global-configuration-push for the (justified but dangerous) antipattern framing.
  • Per-team effort barrier. Building a health-mediated rollout pipeline is significant engineering per team. As Cloudflare's post notes: "applying this methodology to config was possible but difficult. It required significant per-team effort and wasn't consistently applied across the network."

Both are real. The pattern isn't "never use the rapid channel"; it's "the rapid channel should be the explicit exception, not the default, and every configuration unit that doesn't need rapid delivery should inherit code-deployment discipline."

The system-tier realisation

The pattern becomes feasible at scale when there's a unified system teams can onboard a configuration unit to, inheriting the rollout discipline without per-team engineering. Cloudflare's Snapstone is the canonical wiki instance:

Snapstone closes this gap by providing a unified way to bring progressive rollout, real-time health monitoring, and automated rollback to configuration deployments by default.

The key word is default: a team onboarding a config unit to Snapstone gets the rollout discipline without per-team implementation. Before Snapstone, the discipline was possible but rare; after Snapstone, it's the default.

Composes with sibling patterns

The pattern is one of three that compose into defense-in-depth for configuration changes:

All three must be present; any one alone is insufficient. Snapstone is the system-tier realisation of the first. Codex rules enforce the third on every MR. Killswitch infrastructure per module is the organisational complement.

When NOT to apply

  • Genuine rapid-threat-response channels — a zero-day CVE response cannot tolerate a multi-minute staged rollout. Keep the rapid channel; wrap it with monitoring + rollback discipline separately.
  • Truly read-only / never-changes config — if a config value never changes in production, the deployment discipline for it doesn't matter.
  • Per-request config (feature flags, A/B test assignments evaluated per request) — already gated by percentage rollouts and canary semantics; the deployment pattern applies to the rule not the evaluation.

Canonical wiki instance

sources/2026-05-01-cloudflare-code-orange-fail-small-complete — Cloudflare names "health-mediated deployment, the same we use when releasing software, for all configuration deployments". Snapstone is the system-tier realisation. The pattern completes the progressive- configuration-rollout discipline stated as a remediation in the 2025-07-14, 2025-11-18, and 2025-12-05 post-mortems — taking it from "stated remediation" to "shipped default".

Seen in

Last updated · 445 distilled / 1,275 read