Skip to content
Calimero CoreCalimero CoreCalimero Core

Calimero Cloud

Calimero is a confidential cloud for collaborative apps. An app is Rust or JavaScript compiled to WASM; every instance of it runs inside attested Intel TDX nodes that Calimero (or a customer, for a dedicated cluster) operates, and nobody operating them — Calimero included — can read the app’s data.

The architecture

Section titled “The architecture”
Clientmeroctl · mero-jsPython · Rust clientpasskey sessionor API keycluster: attested Intel TDX nodes (merod)every node holds the system group; an app's group lives on its replicas1 verify quote(release, profile)GET /attestation2 sealedrequestany nodeopens the envelopecredential + access onfresh system statesigns the receipt3 forwardpeer sealedchannelthe app's leader4 runs the WASM call, appends{ call, outcome { result, diff } }5 Raftfollowerapplies the difffollowerapplies the diffusually 3 replicas per app; nobody re-executes6 result + receipt(sealed)mero-kmskey for the cluster, only to anattested TD → storage key K_roperator (mdma)Ops API: counts, ids, Raft status;no read path into app data

A client never trusts the network. It fetches the node’s attestation, checks that the TDX quote binds the node’s transport key and that its measurements match a signed mero-tee release it trusts, and only then opens the sealed channel every request travels in. Any node takes any request: it checks the caller’s credential and access against fresh system state, forwards the call over an attested peer channel to the app’s leader, and returns the result with a receipt signed by an attested key. The nodes got their storage key from mero-kms only after proving their image, and the operator’s API reports counts, never data.

One cluster, many small groups

Section titled “One cluster, many small groups”
one cluster, many small groupsnode 1node 2node 3node 4node 5system groupgroup 1, every nodevoter ★votervoterlearnerlearnerapp Agroup 12leader ★replicareplicaapp Bgroup 13replicaleader ★replicaapp Cgroup 14replicaleader ★replica… one group per app★ leader · voters decide commits · a learner receives entries, does not votean app's data lives only on its replicas; leaders spread across nodes

A cluster runs one system group, a Raft log on every node: nodes, accounts, passkeys, sessions and API keys, organizations and teams, installed packages and the directory of app instances. Its voters are the nodes the cluster was bootstrapped with — a cluster started smaller is grown to three by promoting caught-up nodes — and every further node is a learner that receives the log but does not vote. Each app instance gets a Raft group of its own on a few replicas (three by default), so apps progress in parallel and an app’s data lives only on the nodes placed to hold it. See Concepts and Replication.

What runs where

Section titled “What runs where”
  • A node is one merod process in a TDX VM. It takes its storage key from mero-kms only after proving its image, and keeps everything on disk sealed under that key.
  • The system group decides who may do what. Commands carry their actor and are authorized when they apply, so every node reaches the same verdict.
  • An app group’s leader runs a call against the app’s WASM and appends the call with its resulting state diff; followers apply the diff. Calls are linearized, strong reads go through the leader, stale reads any replica, and the app keeps serving while a majority of its replicas run.
  • Two runtimes. A core module built with the Rust SDK (calimero-sdk) runs on wasmer; a calimero:app component runs on wasmtime. Which one is decided from the WASM when the instance is created.
  • Packages are signed .mpk releases, installed from a registry or uploaded, and verified on every node that runs them. A package’s frontend is served from its own origin.

Trust

Section titled “Trust”
  • Clients verify before they send (mero-js, Python, Rust, meroctl), and nodes verify each other the same way before any Raft traffic, adding a cluster secret on internal routes.
  • People sign in with passkeys; services use scoped API keys (cal_…). Sessions are short tokens any node verifies. A method marked #[app::confirm] needs a fresh passkey assertion over the exact call, which is logged as consent.
  • Governance. Who approves new node images, who upgrades apps and who approves outbound hosts is fixed when the cluster is created — each app’s owner, or the operator — and attested with every receipt key, so a user can check it (Deployment governance).
  • Operators see counts. The Ops API reports Raft status and counts, sets quotas, registers nodes, moves replicas and triggers sealed backups. It has no read path into app state.

Shared and dedicated clusters

Section titled “Shared and dedicated clusters”
shared cluster eu-shared-1nodes Calimero runs · default for new customersorg acme · its appsorg globex · its appspersonal accounts' appsone plan's quotas per account(POST /ops/quotas)another shared clusterits own system group and K_rorg initech · its appsorg umbrella · its appsan organization lives on onecluster and stays therededicated clusterone customer's nodes and planthe customer's orgsand their appsgovernance may give the operatorrelease approvals, upgrades oroutbound (fixed at genesis)every cluster is self-containedaccounts, passkeys, sessions, organizations and the app directory live in its system group;xcalls, aliases and API keys reach only apps on the same cluster

Calimero runs shared clusters, onto which many developers’ apps are deployed side by side under one plan’s per-account quotas, and dedicated clusters, which belong to one customer. Every cluster is self-contained: its own system group, its own storage key, its own accounts and organizations. An organization lives on one cluster, and an xcall, an alias or an API key reaches only apps on that cluster. A shared cluster may start with a single node and grow (Growing a cluster). Which cluster a customer lands on, and the plans, are mdma’s (Calimero’s cluster manager), not the node’s.

The pieces

Section titled “The pieces”
Crate / package What it is
merod The node binary: init, run, config, local, inspect, kms, attest
calimero-node The node’s inside: system group, app groups, API, Ops API
calimero-log Multi-group Raft engine (openraft) over a sealed RocksDB store
calimero-sealed The sealed HTTP transport, server and client
calimero-identity Passkeys (WebAuthn), sessions, API keys, confirm challenges
meroctl The command line: packages, app instances, organizations, teams, blobs, accounts, ops
calimero-client Rust client (attestation, sealed channel, passkeys)
mero-js CalimeroClient Browser / Node client
calimero-client-py CloudClient Python client (binds the Rust client)
mero-kms (mero-tee) Releases storage keys to attested nodes
mdma Calimero’s cluster manager: VMs, placement of nodes, the Ops API client, the rebalancer

Next: Quickstart, Writing apps, and the Operate section for running a cluster.