Carbon-Aware Routing

License: pro tier and above. See Licensing. Reference: step semantics, blend math, and query-tracer output are in docs/reference/FilterChains.md.

Nobody else in the GSLB space routes on carbon. ESG procurement questionnaires increasingly ask "does your infrastructure account for carbon intensity?" — with Nexus, the honest answer is yes, and it's a one-line filter-chain step, not a research project.

signal-weight biases DNS answers toward the region with the lower configured value — carbon intensity (gCO2/kWh), a cost table for expensive egress or spot regions, or any scalar where lower is better. It's a bias, not a hard rule: a healthy member in a "worse" region is never excluded, only deprioritized. The same mechanism works for either use case — swap the numbers, not the code.

No external API required for v1: you supply the per-region table yourself, either from a public carbon-intensity source (ElectricityMaps, WattTime) you check periodically, or from your own cost/procurement data.

Step 1 — Configure your zone table

Add to config.yaml on every node (or via GitOps):

signals:
  static:
    us-east: 450   # gCO2/kWh, or any unit you like — lower wins
    eu-west: 120
    ap-south: 610
  weight: 0.5      # 0 disables the bias; 1 lets it dominate. Default 0.5.

systemctl reload gslbd (or wait for GitOps to apply it) — no restart needed. Zones map to your members' existing region field, the same one geo-ip routing already uses.

Step 2 — Add the step to a service's filter chain

WebUI: open the service, switch to filter chain mode, add Signal Weight (carbon/cost) — place it after any narrowing steps (like geo-ip) and before the terminal selector.

API / Terraform:

{
  "filterChain": ["geo-ip", "signal-weight", "weighted-round-robin"]
}

resource "nexus_service" "web" {
  filter_chain = ["geo-ip", "signal-weight", "weighted-round-robin"]
}

Step 3 — See it working

Query tracer (gslbctl trace <service-id> or the WebUI trace panel) shows the zone values it used and whether it actually reordered anything.
Signal Weight page under Infrastructure in the WebUI (or gslbctl signals list) shows the live configured table.
Metrics: gslbd_signal_zone_value{zone} (the configured table) and gslbd_signal_queries_steered_total{service} — an honest count of queries where the bias actually changed the answer. That's your "X% of traffic steered toward lower-carbon regions" number for a press release or an ESG questionnaire — computed from real routing decisions, not a marketing estimate.

The Tuning Knob

weight controls how strongly the signal competes with health/latency scoring:

0.0 — disabled (same as omitting the step).
0.2–0.4 — tiebreaker: only reorders candidates that were already close in score.
1.0 — dictator: the lowest-signal healthy candidate always wins.

Most operators want a tiebreaker, not a dictator — start low and raise it once you've watched the query tracer confirm it's doing what you expect.

Notes

A member with no region set (or a region with no configured signal value) is never penalized — it keeps its original score and competes fairly on the rest.
A future version may add a live feed poller (ElectricityMaps, WattTime) so the table updates itself; today it's operator-maintained, which also means it works air-gapped with zero external dependency.