Multicloud — Architecture Overview

July 19, 2026Download PDF

How Multicloud turns the clouds' capacity markets into one dependable, Kubernetes-native compute pool — and how you plug into it without migrating anything.

1. The idea

Cloud compute is a commodity that doesn't trade like one. The same silicon carries different names, different prices, and different availability in every region of every cloud — and the spot market, where compute is cheapest, asks you to absorb interruptions in exchange.

Multicloud operates that market for you. We maintain a live catalog of priced, benchmarked machine types across AWS, Azure, and Google Cloud; we buy the cheapest capacity that satisfies your workload's real requirements (AWS and Google Cloud in production; Azure provisioning in final validation); we absorb the interruptions; and we hand you the result as something entirely ordinary: a Kubernetes cluster — or even just a single node inside the cluster you already have. Like a power plant behind a wall socket, the machinery is ours to run; what reaches you is standard.

Three principles shape everything below:

Land beside, not migrate. Nothing about your existing setup changes. Your cluster, your pipelines, your tooling stay exactly as they are; Multicloud attaches next to them.
Your accounts, your bill. The machines behind your pool are provisioned into dedicated cloud accounts you own — created for Multicloud, cleanly separated from everything you already run (section 10). Compute reaches you at cost, on your own bill and your own rates; Multicloud charges for the platform, never a markup on machines.
Nodes are replaced, never repaired. Every machine in the pool is disposable by design. All durable state lives outside the fleet, so losing any machine — or all of them — loses nothing.

Six layers, from the ways in down to every region of every cloud

2. The engine: one catalog, one vocabulary, one placement decision

Underneath everything is a continuously refreshed catalog: roughly 265,000 priced offers across ~3,900 machine types, every region and zone, spot and on-demand, with interruption-risk data — and, crucially, benchmarks. Benchmarks are keyed to the actual CPU model rather than the instance name, so a "4 vCPU" machine in one cloud can be compared honestly against a "4 vCPU" machine in another that delivers twice the compute.

When your workloads need capacity, the scheduler makes one placement decision over that whole catalog: it packs pending work into the smallest set of nodes that fits (by memory, by benchmarked compute, and by raw cores), then buys the cheapest concrete machines — in whatever cloud, region, and zone, on spot where your constraints tolerate interruption and on-demand where they don't — that satisfy the requirements, spreading across zones when resilience calls for it. Workloads can express what they need in normalized compute units, so "enough CPU" means the same thing on every cloud and every hardware generation.

The catalog normalizes what we buy; the same discipline normalizes how we act. Each cloud's API and its quirks live in a thin connector at the boundary — and everything inboard of the connectors speaks one vocabulary: a server is a server, a firewall rule is a firewall rule, a virtual disk is a virtual disk, a DNS record is a DNS record, whichever cloud it happens to live in. Every behavior in this document — placement, healing, firewall derivation, network reconciliation — is written once against that vocabulary, not once per cloud SDK. It is also why the platform treats clouds as interchangeable in practice, not just in principle: adding a cloud is one more connector, not one more platform.

The scheduler acting through per-cloud connectors, with prices and availability flowing back

The requirements and constraints are yours to set, per cluster. Want a cluster that only runs in the EU? One pinned to a single cloud — or free to roam every cloud we operate? A cluster that never exceeds $10 an hour? One that always keeps at least five nodes, with a warm spare standing by before it's needed? Nodes with a specific GPU, a memory floor, a benchmarked-compute floor — or on-demand only, because interruptions are off the table? Each of these is a constraint the scheduler honors on every placement decision — not a support ticket.

3. Self-healing: interruptions are weather, not incidents

Spot capacity is reclaimed by the cloud with seconds-to-minutes of notice. The pool treats this as routine weather:

The reclaim loop - notice, drain, replace, a fresh node in about a minute

Every node carries an agent that watches its cloud's reclaim signals. On notice, workloads are evicted in priority order, honoring your disruption budgets, inside each provider's real notice window. Replacements come from the same catalog decision as everything else — which means a reclaim in one zone is often an upgrade to cheaper capacity somewhere else. Machines that die without notice, go idle, or drift are handled by the same family of reconcilers.

Because no machine holds durable state — cluster state itself lives in a managed external database — even the loss of every node simultaneously is designed to be a re-provisioning event, not a data-loss event.

4. One network, isolated per cluster

Each cluster gets its own private network in each cloud it spans — never shared, never peered with anyone's, not even your own other clusters. A customer can run any number of clusters; every one is its own island. Within the island, three rings do the work:

The cloud's firewall — derived, not managed. The scheduler continuously reconciles each network's firewall rules from what the cluster actually runs: a port is open because a published service exists behind it, and closes when the service goes. SSH is never open to the internet. No rule is opened "temporarily" by a person, because no person is in the loop — and when a cluster is deleted, its networks are torn down with it.
An encrypted fabric — membership is a key. Across clouds, nodes join a WireGuard mesh over IPv6. Being on a cluster's network is holding a key its fabric recognizes — not a source-IP rule — and traffic without a recognized key is dropped at the first packet. Everything crossing the fabric is encrypted node-to-node: pod traffic and host traffic alike. Tunnel geometry (MTU, TCP segment sizing) is tuned for the real cross-cloud wire, where path-size discovery can't be trusted.
A modern pod network — per cluster, kernel-fast. On top of the fabric, each cluster runs its own instance of Cilium, an eBPF-based container network: one flat, encrypted, dual-stack pod network spanning providers, load-balanced in the kernel rather than by proxies, with traffic kept zone-local where possible to avoid cross-zone cost and latency.

Three rings on every node, one encrypted cross-cloud fabric, no peering to anyone

At the edge, the platform operates DNS, TLS certificates, and ingress for you: hostnames are published automatically for the services you expose, certificates are issued and renewed automatically, and every node in the pool can terminate traffic — so the edge scales with the fleet and survives any node's loss.

5. How a new node joins — no inbound management surface

A pool that replaces machines all day is only as trustworthy as its join path, so here it is, spelled out. The short version: a new node lets itself out — nothing lets itself in.

Six steps from purchase to ready, every node connection opened outbound

Three properties make this shape matter:

Configuration travels with the purchase, then never again. The boot recipe — the node's identity and the exact set of services it runs — is attached to the cloud's own provisioning call. Nothing ever pushes configuration to a running node; a node that should be configured differently is replaced, not edited. There is no drift, because there is no mutation.
The control plane never exposes itself. The rendezvous is a tunnel the node initiates, outbound and identity-gated. Your cluster's API server is never open to the internet — it doesn't even need a route back to the node.
The listening surface is enumerable. What will accept an unsolicited packet on a pool node: the fabric's WireGuard port, which is key-authenticated — without a recognized key the conversation ends at the first packet — and the public service ports (80/443) on nodes terminating traffic you chose to publish. No internet-facing SSH, no management API, no agent port. That is the complete list.

6. A real Kubernetes, batteries included

What you get is not a Kubernetes-like abstraction — it is upstream-conformant Kubernetes. On top of it, the platform runs and operates the pieces most teams end up assembling themselves:

a serverless runtime (Knative) for HTTP services with scale-to-zero,
GitOps delivery (Argo CD): you push, the platform pulls and deploys,
observability — logs, metrics, and traces collected and queryable, with cost visibility that understands per-machine spot prices rather than flat rates,
TLS, DNS, SSO, and secrets management as managed plumbing,
a per-node image cache, so a fleet spanning clouds doesn't hammer registries.

All of it is operated by control loops on our side of the line. None of it lands on your on-call.

7. Isolation and sovereignty

Customers get isolation in the tier that fits, on one shared machinery:

Workspace tier — your workloads run in their own namespace on managed shared infrastructure, walled off at the API layer: your credentials map to your workspace and nothing else. It is designed for instant provisioning and near-zero idle cost.
Dedicated cluster tier — your own Kubernetes cluster: your own control plane, API server, certificate authority, RBAC domain, network fabric, and datastore. Control planes are hosted as pods on our infrastructure (no control-plane machines for you to pay for or babysit), while worker capacity is bought from the catalog on demand — provisioned into the dedicated cloud accounts you own, every machine visible in your own console and on your own bill. Promotion from workspace to dedicated cluster is a configuration step, not a migration.

A dedicated cluster whose keys you hold — standard kubeconfig, full admin — is what we call a sovereign cluster: yours to point any tooling at, operated for you underneath, reachable only through its own authenticated endpoints.

8. Four ways in

Advisor first, then virtual node, your own cluster, or Skipper into one pool

Start with evidence — Advisor. A read-only report you install in your own cluster. It inspects nothing but resource declarations, sends nothing outside except one anonymous catalog query, and computes what your estate would cost if it were placed through the catalog — with interactive levers for right-sizing, cloud choice, regions, and spot. It quantifies; it changes nothing.

Extend your cluster (early access). Your existing cluster (EKS, GKE, AKS, or self-managed) gains one new node — a virtual node backed by your Multicloud pool. Pods you mark for it are scheduled there like anywhere else; pending demand behind it drives our autoscaler. Your control plane, your tools, and every other workload remain untouched, and everything the virtual node fronts is operated for you. When you want more than burst capacity, the same pool is promotable to a sovereign cluster.

Deploy without a cluster — Skipper (early access). For teams that just want software running: you describe an HTTP service in a short manifest (image, port, environment, secrets, scaling bounds) and the platform compiles it onto the serverless runtime — a URL, TLS, logs, and scale-to-zero included, authenticated by organization-scoped API keys.

A machine interface runs alongside all four: a CLI, client libraries, and an MCP server that lets AI assistants search and compare the live catalog directly.

9. How this differs from the alternatives

Almost everything in this market makes the cloud you are already on cheaper to use. Multicloud changes which cloud you buy from. That is a different axis — and the two multiply rather than compete.

Approach	The size of your pods	The machines in one cloud	The machines in every cloud
Cost visibility — FinOps, allocation	reports	reports	—
Right-sizing — VPA, rightsizing tools	acts	—	—
Node autopilots — Karpenter, spot autoscalers	—	acts	—
Multicloud	—	acts	acts

They compose. Asking for the right amount and packing it tightly are real savings, and you should keep doing both — we pack your pods into the smallest set of machines that fits, and the Advisor prices right-sizing for you. But once the requests are honest, one provider's price list is the floor. Ours is the whole market.

A single-cloud autopilot cannot cross the street. Inside its own cloud it is mature and effective: better SKUs, spot, tighter bin-packing. What it cannot do is notice that the same benchmarked compute is a third cheaper in another provider's region this week — its catalog is that provider's own. Making the comparison honestly takes a normalized, benchmark-keyed, continuously priced catalog spanning the clouds. That catalog is the product.

Trust runs the other way, too. To act, an autopilot needs write credentials into the accounts your production already lives in. Multicloud runs in dedicated accounts created for it (section 10), so the blast radius is bounded by construction rather than by policy.

Where the field is ahead of us: the single-cloud autopilots have years of production traction, compliance certifications, and polished dashboards, and parts of this platform are still early access. If you hold committed-use discounts, your floor on that cloud is below list — which is exactly why the front door is a read-only report computed against your numbers, not a headline percentage.

10. Your accounts: onboarding without handing over keys

The machines Multicloud runs for you live in cloud accounts you own, not ours. Onboarding is built around that separation:

Create fresh, dedicated accounts. Under your existing organization you create new accounts that exist solely for Multicloud — an AWS account, a Google Cloud project, an Azure subscription. Nothing you already run is touched, and nothing Multicloud does can reach outside them. An AI-assisted setup skill and a set of scripts we provide (early access) automate and streamline the whole process, end to end.
Grant scoped credentials. You hand the platform API credentials to those dedicated accounts — and only those. Your existing accounts, IAM, and workloads stay invisible to us.
Keep the off-switch. Everything the platform creates — machines, networks, DNS — is visible in your own console, auditable in your cloud's own logs, and billed at your own negotiated rates. Rotate or revoke the credentials and the platform is cut off completely.

Your cloud gave you credits, or a special discount? Amazing — use them. Because the machines are bought in your accounts, startup credits, enterprise discount programs, and committed-use plans all still apply — stacking on top of whatever the catalog already saved you.

This is what makes "compute at cost" literal rather than a discount promise: the machines are purchased from your cloud, in your accounts, on your bill. Multicloud operates them, and charges for the platform.

11. Security posture, summarized

Isolation is structural. Per-cluster networks with no peering — a customer's clusters are isolated even from each other; each dedicated cluster has its own CA and datastore; workspace credentials cannot address another tenant's workspace even in principle.
Control traffic is identity-gated. Cluster control planes are reached through authenticated, per-cluster tunnel endpoints — API servers are never simply open to the internet, and nothing requires inbound access into your environment.
Everything cross-cloud is encrypted node-to-node (WireGuard), for pod traffic and host traffic alike.
Least exposure by construction. SSH is never world-open; public ports exist only where a service is actually published; secrets flow from a managed external store into workloads without ever landing on machine disks.
Your cloud, your bill. Compute runs in dedicated accounts you own (section 10) — at cost, under credentials scoped to those accounts and revocable by you, with Multicloud charging for the platform, never marking up the machines.

12. What crosses the line

The entire attach surface between your world and ours is small enough to enumerate: the scoped credentials you grant to your dedicated Multicloud accounts; an outbound-initiated, identity-gated tunnel for control traffic; a git remote you push to; the key-authenticated encrypted fabric between pool nodes; and, if you use it, the virtual node's outbound connection from your cluster. Your IAM, your network policies, and your existing ingress remain exactly as they were.

This overview describes the platform's architecture. For current availability of specific capabilities and onboarding, talk to us — some surfaces described here are in early access.