本页面仅提供英文版本。英文文本为具有约束力的版本：合同承诺的机器翻译并非合同承诺，我们也不会将其呈现为经律师审阅的版本。

Multi-Cloud Proof

A Kubernetes cluster has one control plane. Ours drives tenant nodes on more than one public cloud from a single control plane — and we can show you the live nodes, not a diagram of what the architecture would allow.

What is actually running today

Reading directly from the control plane's own service registry on 21 August 2026, one tenant's node fleet holds two nodes, both ready and heartbeating within the minute:

NodeCloudStatusAgent
alicloud-node-1Alibaba Cloudready0.7.9, specVersion 4
gcp-node-1Google Cloudready0.7.9, specVersion 4

alicloud-node-1's registered WireGuard endpoint is a public IP in Alibaba Cloud's own address range, which we independently confirm rather than take from the node's self-reported label. Both nodes are joined to the control plane over a WireGuard mesh, not a shared cloud VPC — the mesh is what lets one control plane treat two different clouds' networks as one addressable fleet.

Cross-cloud placement, proven live — not just designed

It is one thing to enroll nodes on two clouds. It is another to move a running workload between them without a gap where neither copy is healthy. We built a mandatory live gate for exactly that case (internally “LG6”): create a deployment pinned to alicloud-node-1, let it become healthy, then re-place it onto gcp-node-1. The assertion that matters is the third of seven: the alicloud-node-1 container is still present at the moment the gcp-node-1 container is created — and only removed once the new one is confirmed healthy. That is the difference between a guarded migration and a window where a cross-cloud move drops the workload entirely. The gate is documented as mandatory specifically because every other live gate at the time ran against single-node placements and could not have caught a regression here.

What we are not claiming

Two clouds enrolled today; three were tested, once, and measured

What is enrolled right now is two clouds. An earlier design read on this fleet listed a third node, aws-node-1, as Alibaba Cloud and Google Cloud's peer. Reading the control plane's registry directly, on the same date as the table above, aws-node-1 has no node record at all — only two leftover sub-keys from a service that once ran there. The scheduler's own node listing code skips it for exactly that reason: a node with no name field is not a node it will place anything on.

The three-cloud test did happen, and it produced a number. On 14 June 2026, one tenant ran a three-node fleet across Amazon Web Services, Google Cloud and Alibaba Cloud. A marker file written into the primary volume on the AWS node appeared in its replica on the Google Cloud node in about forty seconds, node‑to‑node across the WireGuard mesh — with the control plane not in the data path at all. The AWS node was decommissioned after the test, which is why the registry shows its remains rather than the node. Source: internal engineering log 2026-06-15_dvm-materialization-mesh-replication.md, which also records the four agent releases (0.3.48–0.3.51) it took to get real replication working rather than a local marker that merely looked like it.

So: two clouds are live and continuously proven by the gate above; three clouds were proven once, on a dated test, with a measured transfer. We publish both, labelled, and we do not blend them into a single present-tense claim. Nothing in the placement or mesh code records which continent a node sits on — "Alibaba Cloud" and "Google Cloud" above come from the node's own name and its WireGuard endpoint's address range, not a stored region field — so continents are not asserted as a tracked platform fact. If a third live cloud node is enrolled, this page gets a third row and a re-run of the same live gate, not a rewritten claim on the strength of a design document.

Beyond this one tenant: production runs on infrastructure we don't own

Separately from the two-cloud test fleet above, our production control plane manages a mixed fleet today: its own platform node, plus two customer-owned nodes running on infrastructure those customers control, not us. Customer-owned nodes cannot be upgraded remotely by us at all — they upgrade only through an explicit dashboard approval the customer drives themselves. That is a second, independent proof of the same underlying claim: one control plane, genuinely separate infrastructure, with the isolation boundary enforced by who can even reach the node, not just by network policy.

For the tenant-isolation mechanism that makes sharing a control plane across separate infrastructure safe, see Compliance.

How these numbers and claims were arrived at

  1. The node table was read directly from the control plane's Consul-backed service registry on 21 August 2026 (odysseus/tenants/<tenant>/nodes/<name>), not from a design document describing the intended topology, and re-verified independently a second time the same day: both alicloud-node-1 and gcp-node-1 read status: "ready" with a lastSeen timestamp seconds old at read time. alicloud-node-1's public WireGuard endpoint address falls in an Alibaba Cloud-allocated IP range.
  2. The aws-node-1 finding is the most load-bearing correction on this page: multiple design documents from June–July 2026 refer to a three-node fleet including it, and one earlier spec even recorded it as a DVM replication primary. The live registry read on 21 August 2026 shows no top-level node record for it — only two orphaned sub-keys (/rsync/secret, /services/rsync/status) with no name, status, or agent version. The scheduler's node-listing code (pkg/scheduler/consul_provider.go:88) explicitly skips any entry with an empty name field, and internal design docs note the same thing. We are treating the code's behavior, not the older documents, as the fact of the matter.
  3. The cross-cloud placement gate (“LG6”) is drawn from the reconciler placement-safety design and workplan documents, which record it as mandatory and describe its seven assertions; we did not re-run the live gate ourselves for this page, and say so rather than implying a fresh run.
  4. The production fleet figures (platform node plus two customer-owned nodes, dashboard-approval-only upgrade path) come from a promotion runbook's measured starting state, corrected in the same document after an earlier count under-reported it. We did not independently re-verify prod's node count for this page beyond that document.