Skip to content

Blog

Domain mirroring and DR controls — new on Control Plane

By Nathan McNeill2 min read
Mirroring and DR

Between February and April 2026 we shipped two related capability sets: domain mirroring (route a copy of real traffic to a second workload while users still see only the primary’s response), and GVC-level geo-routing controls (named knobs for which region serves a user and what happens when a region is unhealthy).

Domain mirroring — testing in production, safely

Domain mirroring means a copy of every incoming request to a workload also gets sent to a second workload. The second workload processes the request, generates a response, and the response is silently discarded. The user only sees the primary’s response.

Here are some of the use cases:

  • Shadow deployments — a new version of an API receives real traffic in the background, you compare its behavior to production offline, and you only cut traffic over once you’ve watched it handle real load cleanly.
  • Performance benchmarking under real load — measure how a new architecture (different language, different database) actually performs against your real traffic, not synthetic load tests.
  • Security and anomaly detection — run a new threat-detection pipeline against real traffic without putting it in the critical path.
  • Migration validation — mid-migration, mirror to the new system, prove parity, then cut over.

March 2026 also added sticky sessions for service-to-service traffic — a related but distinct feature that keeps a user’s requests routing to the same backend replica, useful for any workload holding state in memory between requests.

GVC geo-routing controls — the DR story your SRE team wanted

A GVC can span multiple regions across multiple clouds — say, aws-us-east-1, gcp-europe-west1, and azure-eastus. When a user makes a request, the platform decides which region to send them to. The simple default is “closest healthy region by network latency.” That’s fine for most use cases.

It’s not enough for some teams — regulated industries, large B2B, anyone with formal SLAs. They want named, specific controls. we added three:

  • Location routing tier — sort regions into tiers. “Tier 1: aws-us-east-1, gcp-europe-west1. Tier 2: azure-eastus, only use if Tier 1 is unavailable. Tier 3: emergency only.”
  • Latency offset — bias a region’s measured latency. “Add 30ms to anything routing through azure-eastus.” Makes the platform prefer cheaper or better regions unless the real gap closes.
  • Latency tolerance — how much extra latency you’ll accept before failing over. Prevents flapping during minor network blips and prevents users sitting on degraded performance too long.

Try it

Mirroring is configured per domain — see the domain reference. GVC geo-routing controls live on the GVC itself — see the GVC reference.

Further reading

Domain reference (mirroring, routing, regex hosts)

GVC reference (geo-routing, locations)

Release notes, February 2026 (mirroring introduced)

Release notes, March 2026 (cross-GVC mirroring, sticky sessions)

Release notes, April 2026 (geo-routing controls)