Protecting many hostnames as one Access application
Cloudflare Access has historically treated each protected resource as a single, explicitly named hostname. That model created friction for teams running Single Page Applications (SPAs) or fleets of automatically provisioned services. Administering security for those architectures meant manually stitching together sessions or duplicating the same policy hundreds of times. Two updates now eliminate those workarounds: multi-domain applications and wildcard support.
Why single-hostname policies fell short
Access sits in front of applications, evaluating identity, location, network context, and device posture before issuing a browser cookie containing a JSON Web Token (JWT). That session cookie is scoped to the protected hostname, and every subsequent request to that hostname must present it. For a classic monolithic app, one hostname is plenty.
SPAs are rarely so simple. They commonly split the user-facing front end and the backing API across two hostnames, for instance app.example.com and api.example.com. The two services do not share an Access JWT, so requests from the front end to the API were blocked unless developers invented their own mechanism to mint and share tokens between hosts.
On the opposite end of the spectrum, large organizations deploy software as a service per tenant or per environment using patterns like example.service123.example.com. Each of those hostnames needed its own Access application record even when every instance enforced the same security requirements. As fleets scaled, administrators were on the hook for creating hundreds or thousands of near-identical configurations.
One application, many hostnames
Multi-domain applications let a single Access configuration cover several subdomains at once. That collapses the management overhead and removes the need to duplicate policy logic per hostname.
The same feature resolves the SPA session problem. Access handles JWT cookie issuance across every hostname attached to the application, so a front-end service and its API can talk to each other over separate domains without extra code or token-sharing plumbing.
Wildcard matching and specificity rules
For fleets that follow a naming convention, wildcards remove the need to enumerate each host individually. A wildcard (*) can now appear anywhere in the subdomain or path of a hostname, matching a family of applications instead of forcing an administrator to define each entry. One policy can then govern hundreds of functionally identical services.
Conflict resolution follows a predictable rule: the most specific hostname definition takes precedence. If a wildcard application covers *.example.com, a separately defined test.example.com application wins for that subdomain, which is useful when a particular instance needs stricter controls than its siblings.
Availability
Wildcard applications are currently available in open beta through the Cloudflare One Dashboard. Multi-domain support is scheduled to enter open beta in the coming weeks. Full configuration details are covered in the product documentation.
