One service mesh across every cluster and region
One service mesh across every region, declared in the same file as your workloads — cross-region peering, mutual TLS and default-deny by service identity.
version: v0.2
cluster_id: "production-mesh"
# Each region becomes a peered member of one fabric.
regions:
mode: explicit
explicit:
- { region_id: region-a, region_name: eu-west, is_primary: true }
- { region_id: region-b, region_name: eu-southwest }
mesh:
tls_enabled: true # mutual TLS between services, on by default
# service-to-service authorization is default-deny — open only explicit paths
peering_enabled: true # join the regions into one fabric
mesh_servers: 3 # control-plane quorum per region
placement:
residency:
require_countries: ["PT", "ES"]DigitalFrontier Mesh features
One mesh, defined once, spanning every region
Declare your regions and per-region control-plane size in a single file; the platform stands up a control-plane quorum in each region and wires them into one fabric. The same declarative format that describes your workloads describes the mesh — no separate tool and no per-region hand-wiring.
regions:
explicit:
- { region_id: region-a, is_primary: true }
- { region_id: region-b }Cross-region service peering
Regions are joined by explicit peering: each pair exchanges a single-use token and establishes a bidirectional, encrypted link, after which services are exported and imported across the boundary. The control plane establishes every declared region pair for you and tracks what each peer imports — no long-lived secret is ever handed across the boundary.
mesh:
peering_enabled: true # join regions into one fabricRegional mesh gateways as the front door
Each region runs a mesh gateway as its single externally-reachable entry point; cross-region traffic and peering flow through it, so individual services never need their own public exposure to talk across regions. Gateway reachability is health-checked continuously and feeds the mesh's health score.
# Preview regions, gateways, peerings
core plan mesh.yamlMutual TLS and default-deny by service identity
Service-to-service traffic runs over mutually-authenticated, encrypted transport, with mutual TLS on by default and certificates issued and rotated automatically. Authorization is keyed to service identity, not addresses: the mesh starts closed, and each still-needed path is an explicit allow rule — a service that isn't permitted to call another simply can't.
mesh:
tls_enabled: true # mutual TLS on by default
authorization_default: deny # allow only explicit pathsContinuously monitored, fault-tolerant fabric
A background monitor scores every region's mesh — control-plane quorum, gateway reachability and peering state — with peer-flap detection, then persists state and exports metrics for alerting. The fabric itself is fault-tolerant: the quorum tolerates a lost node, and when a peer or a whole region drops and returns, peerings re-establish and the mesh reconverges with no split-brain.
mesh:
mesh_servers: 3 # quorum tolerates a lost nodePer-region autoscaling with residency placement
Services opt into the mesh with a single toggle — sidecar, mutual TLS and registration applied automatically — and scale independently in each region under load, then scale back down as it subsides. Placement honors residency constraints, pinning the mesh and its workloads to chosen countries or a geographic scope with declarative fallback ordering.
autoscaling: { min_replicas: 1, max_replicas: 5 }
placement:
residency:
require_countries: ["PT", "ES"]Get early access to Mesh.
Tell us about your workload and we'll get you into the preview.