Terrane Runtime 2.0: unified deployment surface, 24 regions, live observability

The second major release of the runtime brings one deployment file for inference, APIs and backend services, six new regions and a rebuilt observability layer.

Runtime 2.0 is available today for every account. It is the largest release since launch, and most of it came directly from watching teams operate on 1.x for eighteen months.

One deployment surface

Until now an inference endpoint, a REST API and a background worker were three different deployment paths with three different config formats. In 2.0 they are one file:

runtime: edge-inference
regions: [iad, sfo, fra, sin]
autoscale: enabled
batching: dynamic
observability: full

services:
  - name: embed
    kind: inference
    model: bge-large-v2
    hardware: l40s
  - name: api
    kind: http
    image: registry.terrane.example/acme/api:2026.08
  - name: reindex
    kind: worker
    schedule: "*/15 * * * *"

Routing, scaling rules and rollout policy apply across all three. A canary rollout on the API and its embedding backend now moves in lockstep instead of drifting apart.

Six new regions

gru, bom, syd, jnb, yyz and arn bring the total to 24. Every region runs the same hardware tiers (H200, Gaudi 3, L40S) so a deployment file is portable without edits. Cross-region routing treats new regions exactly like existing ones from the first minute; see the routing post for how traffic finds them.

Observability, rebuilt

The old metrics view was a wall of charts. The new runtime view is organised around four questions operators actually ask:

  • Is it healthy? Regional availability, error rate and saturation on one line.
  • Where is the traffic? Live request flow between regions, with failover ramps visible as they happen.
  • What is slow? Latency broken down by model, region and batch size, with p50, p95 and p99 side by side.
  • What changed? A deployment timeline overlaid on every chart.

Every panel links to the runtime logs filtered to the same window. Alerts are configured from the same view, so the thing you are looking at is the thing you can be paged about.

Smaller changes worth knowing

  • terrane deploy --dry-run prints the full resolved plan, including which regions will receive capacity and in what order.
  • Rollouts can now be paused and resumed from the CLI and the UI.
  • Hardware tier h200 gains a --reserved flag for teams with committed capacity.
  • The Python and TypeScript SDKs expose the batching budget as a per-request header override.

Upgrading

1.x deployments keep working unchanged. Run terrane migrate to convert an existing configuration to the unified format; it prints a diff and does not apply anything without confirmation. Full notes are in the documentation.