Add the multi-region compute model

[rossnelson]

Groundwork for Serverless Workers on highly available Namespaces. Renders nothing — this is the model and the gate, so the UI can land in slices.

Taken from the design prototype in #3951 and rebuilt on main. That PR stays open as the design reference.

Description & motivation 💭

Answers one question: given a compute config and a Namespace's regions, which scaling groups serve which region, in the PRD's matching order — an exact regionId first, then any catch-all.

The gate is one switch

The Namespace's regions, and nothing else.

This repo does not decide whether an install has highly available Namespaces. A consumer passes the regions when its own entitlement says so, exactly as it already passes the compute providers a Namespace may use. Fewer than two regions means single region — every self-hosted install, and every Namespace without HA.

So this can ship before the API that feeds it. The feature stays dark until a consumer opts in.

Why the compute config gets no vote

The prototype gated on two things at once: the regions prop and the presence of a regionId on a scaling group. Two conditions that can disagree is how a half-gated feature reaches someone who should not see it — and neither was written down as the gate, so a reviewer could not tell what was live.

Here a single-region Namespace with a stray regionId is still single region. One question, one answer, stated at the top of the module.

Each region says whether it is active

Rather than the caller sorting the active region first. Temporal Cloud reads that from the replica's mode, so it is known rather than conventional — and an ordering rule is one a caller can break with nothing noticing.

Design Considerations 🎨

• Region ids are provider-name, as in aws-us-west-2. That is already how Cloud spells a Namespace's replica regions, so the two sides join directly. A plain string rather than a structured value, because ComputeConfigScalingGroup.region_id is one and a Namespace is in a single cloud today, so the provider is never ambiguous within one Namespace.
• Provider labels read from COMPUTE_PROVIDERS. The prototype added two more switch statements over provider types, which is what Describe a compute provider in one place #3946 had just finished removing.
• Pure throughout. No mutation, no component imports — a plain module the components will consume.
• regionId is optional and read defensively. An empty string reads as unset rather than as a region no Namespace has. The upstream field is Add region_id to ComputeConfigScalingGroup api#875, still in review.

Testing 🧪

How was this tested 👻

• Unit tests added
• Strict type check clean

22 tests: the gate (including that a regionId alone does not open it), the matching order, exact-beats-catch-all, role following the active flag rather than arrival order, multiple groups per region, uncovered regions, and provider label fallbacks.

count-strict-errors.ts reports 0.

What comes next

Each slice is independently reviewable and each stays dark without regions:

1. This PR — model and gate
2. Read-only display: per-region compute on the version detail and table rows
3. Region badges on the deployments list
4. The forms: compute per region
5. The preview panel and failover stories

Checklists

Merge Checklist

• Renders nothing; safe to merge ahead of the API
• Gate stated in one place and covered by a test

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
holocene	Ready	Preview	Oct 7, 2026 8:17pm UTC