Versioning L7 Config: How HTTP Applications Separate “What” from “Where”
In December, Cloudflare introduced HTTP Applications in closed beta, a tool aimed at giving enterprise customers granular control over their Layer 7 configuration by introducing staging and versioning. That beta has now been opened to all enterprise customers. The core idea is to shift configuration management away from a per-hostname model and toward a per-application model, allowing teams to test and deploy changes with less risk.
Managing Configuration by Use Case
Traditionally, Cloudflare configuration is tied directly to a zone and its hostname. HTTP Applications changes that relationship. An HTTP Application represents a logical grouping of configuration, such as the settings for a marketing site or an internal tool, rather than being bound to a single domain. It contains a series of independent versions, each acting as a snapshot of settings like Page Rules, Firewall Rules, and cache controls. Creating a new version starts with a copy of the current one, ensuring a consistent baseline for iteration.
The initial version of an HTTP Application is instantiated by copying the configuration from an existing zone. From that point forward, changes to the zone and changes to version 1 are independent. Critically, no version impacts live traffic until it is explicitly deployed via Routing Rules.
Routing: Mapping Traffic to Versions
Because versions aren’t tied to a specific hostname, something else must determine which configuration applies to which requests. That job falls to Routing Rules. These rules, built on Cloudflare’s Ruleset Engine, use conditional logic to match hostnames to a specific version of an HTTP Application.
If zone.name = `example.com`
Then use configuration of HTTP Application id: xyz, version 2When a request matches such a rule, the network applies the configuration from the specified version (e.g., version 2) instead of the zone’s default configuration.
This mechanism is what enables staging without a separate staging zone, which was previously a common workaround. Cloudflare provides dedicated IPs for testing. Sending requests to those IPs lets you evaluate a version against live traffic patterns and catch misconfigurations before they reach end users.
Under the Hood: Ownership Lookup and Rule Execution
The process within Cloudflare’s global network involves a per-request ownership lookup. Each request is assigned an account/config pair (e.g., 777:123 for account 777 and zone 123) to determine which configuration settings will be applied.
When HTTP Applications and Routing Rules are active, the initial ownership lookup still happens. However, an additional step checks whether any Routing Rules exist that should override the zone-level config. For instance, if a rule matches example.com and points to version 2 of an HTTP Application, which might have a config id of 456, the effective lookup becomes 777:456.
For staging, the same principle applies with a twist. The Routing Rules can specify that a version should only apply when a request arrives via the dedicated staging IPs. All other traffic continues to use the production version. This lets you validate a set of changes in an isolated environment and then promote the exact same configuration to all traffic simultaneously.
This feature also simplifies incident response. If a rollout goes wrong or a staged test reveals problems, rolling back is a single action: revert to the previously deployed version. There’s no need to hunt through settings to find what changed—the restoration is immediate, and a deeper investigation can happen afterward.
Enterprise Access
HTTP Applications and Routing Rules aim to offer both power and safety in configuration management. Enterprise customers interested in participating in the beta or exploring deployment strategies should contact their account manager.
