Traffic routing

Blue/green, canary, shadow —
all in config.

The same edge that decides flags and variants can also decide where the request goes. Split traffic across origins by weight, segment, or experiment — no separate load balancer config, no redeploy.

Get early access See segmentation →

Rule types

Three ways to bend a request.

rewrite
Rewrite
Quietly change the path before it reaches the origin. /checkout/checkout-v2 with no client-visible redirect.
redirect
Redirect
Send the client elsewhere with a 301 or 302 — by segment, geo, or experiment, decided at the edge.
origin
Origin split
Route a weighted share of traffic to an alternate origin. The building block for blue/green and canary.

Origin split

Canary an origin by weight.

Point a slice of traffic at a new origin and grow it as confidence builds. Pair it with a rollout policy and the weight advances — and retreats — on its own.

# routing rule — evaluated in position order
rule_type: origin
match_rules: # same ConditionGroup as segments
action: { "url": "https://canary.internal", "weight": 10 }
segment_ids: ["beta-users"]

Targeted by the same rules

Routing speaks segments.

Every routing rule carries a match_rules condition tree — the same recursive AND / OR / NOT structure that powers segments. Route EU mobile traffic to one origin and everyone else to another with a single rule, no glue code.

Put routing where the decisions already are.

AyBee is in development. Get early access and we'll reach out personally.

Get early access