Versioned Edge Configurations Arrive in Cloudflare’s HTTP Applications Beta

Cloudflare has opened a closed beta for HTTP Applications, a feature that introduces versioned configuration management for HTTP traffic. Designed for enterprise customers, the system decouples configuration snapshots from hostnames, letting teams stage, test, and promote changes with explicit control over when updates reach the global edge network.

This approach addresses a long-standing operational gap. Traditionally, Cloudflare configuration has been tied to a DNS zone, which works well but forces teams to maintain separate staging and production zones—often under different hostnames—to isolate untested changes. That split requires manual duplication or custom automation to sync settings between environments, and it invites human error and configuration drift.

HTTP Applications split configuration into two core concepts:

  • HTTP Applications — logical containers that group configuration by purpose, such as a marketing site or internal tool. Each application holds multiple independent configuration versions. Creating a new version starts it as a copy of its predecessor.
  • Routing Rules — the mechanism used to map traffic to a specific application version. Powered by Cloudflare’s Ruleset Engine, these are conditional “if then” rules, matching on hostname to apply a given version’s settings.

Notably, an HTTP Application version is not bound to a hostname. Instead, a Routing Rule explicitly directs hostnames to a version. Two rule types are available:

  • Staging rules — match on hostname and also restrict execution to traffic arriving at specified edge IPs.
  • Production rules — match hostnames and apply the version to all matching traffic.

Controlled Rollout of Edge Configuration

The workflow enables testing a configuration tweak against live traffic without impacting customers. In a walkthrough of the dashboard, a user first creates an HTTP Application, selecting a pre-existing zone like example.com to seed the first version with a copy of existing settings. This avoids rebuilding configuration manually.

Edits made to a version will not touch live traffic until a Routing Rule references it. Additionally, not all zone settings are available inside an HTTP Application: DNS records, SSL certificates, Spectrum, and Load Balancing remain outside the versioning model.

Once changes are made—for example, a Transform Rule that rewrites the assets path from /assets/* to /internal/files/assets/*—a staging rule is created. The rule screen shows the IPs reserved for testing. After pointing a local machine’s hosts file at those staging IPs, a developer sees their new rule execute while production traffic is unaffected.

After validation, a production rule is created for the same hostname, applying the identical version to all traffic. The configuration used in staging is, by definition, the same one that rolls out to production.

Repeating the Cycle for Future Changes

When the next change is needed, the current version can be cloned to create a new one. Initially, the new version matches its predecessor and has no Routing Rules attached, meaning it is inert. A subsequent edit—such as adding firewall rules—does not alter edge behavior until the staging rule is updated to point to the new version. Only after successful testing does the production rule get switched to the new version, completing the rollout.

This workflow shifts infrastructure change procedures from manual, error-prone reproduction to a clear promotion path. The closed beta is open to enterprise customers through their Cloudflare account team.