Zone Versioning Reaches General Availability
Cloudflare has announced the general availability of Zone Versioning for enterprise customers. The feature, previously known as HTTP Applications, has been redesigned based on customer testing and feedback. Zone Versioning lets teams version their zone configuration and control when and how those changes are deployed to specific segments of traffic.
The core problem it addresses is one that many site reliability engineers know well: configuration changes in production are risky, and rolling them back quickly can be even riskier. Cloudflare heard two recurring concerns from customers:
How can zone configuration changes be tested safely before they hit live traffic?
When a change has a negative impact, how can it be reverted fast?
Existing workarounds tend to be manual and brittle. Teams often maintain a separate staging zone — for example, staging.example.com — apply changes there first, and then attempt to replicate them on the production zone. Tracking changes across multiple environments becomes error-prone, especially when changes are never rolled back or mirrored, leaving environments out of sync. For rollbacks, teams frequently log changes in external systems such as JIRA, which requires an on-call engineer to correlate ticket history with actual configuration changes during an incident. The result is that customers hesitate to adopt new features or make configuration tweaks because they lack confidence in their ability to validate and recover from them.
Versions and Environments
Zone Versioning introduces two new concepts to configuration management: Versions and Environments. Together, they provide a structured workflow for testing, deploying, and reverting changes.
Versions are independent snapshots of zone configuration. Creating a version never affects live traffic; each version can be edited without impacting others. Version 1 is created automatically when Zone Versioning is first enabled, based on the zone's current baseline configuration. All changes made to a version are stored and propagated to Cloudflare's global network but aren't applied to any traffic until the version is explicitly deployed.
Environments map portions of a zone's traffic to a specific version. They are powered by the Ruleset Engine, the same infrastructure behind Custom WAF Rules and Cache Rules. Filters can be built around parameters such as hostname, client IP, location, or cookie. Traffic that matches an environment's filter uses the version assigned to that environment.
Three environments are created by default:
- Development — Applies to traffic that carries a specific development cookie.
- Staging — Applies to traffic sent to Cloudflare's staging IP addresses.
- Production — Applies to all traffic on the zone.
The Production environment cannot be modified, but additional environments can be created, and the Development and Staging filters can be changed. Newly created environments start in an unassigned state, meaning traffic matching their filters falls back to the baseline configuration.
A common workflow is to deploy a new version to Development and Staging, validate the changes, and then promote it to Production. If issues surface after promotion, the rollback action restores traffic to the previous version's configuration.
Fast, Atomic Rollbacks
One of the key technical details is how these changes propagate across the network. Whenever a configuration change is made to a version, it's stored in the service's system of record and pushed to Cloudflare's global network so it's available everywhere at any time. However — unlike standard zone configuration changes, which take effect immediately — a change is not used until its version is deployed to an environment receiving traffic.
This design also applies to promotion and rollback operations. Since all versions are already available across the network, shifting an environment from one version to another only requires pushing a single, atomic update. The update simply directs the network to use the newly specified version for traffic matching that environment's filter.
The result is that promotions and — more importantly — rollbacks execute as quickly as any ordinary configuration change. There's no waiting for propagation when a bad deployment needs to be undone. A customer can return to a last known good configuration in seconds, which can significantly reduce the duration and impact of an incident.
Getting Started
Zone Versioning is available today for enterprise customers through the Cloudflare dashboard. The feature requires the new Managed WAF rules. More technical details and documentation are available in the Cloudflare Developer Docs.
