Skip to content
CalimeroCalimeroCalimero Docs

What is Calimero

Calimero is a confidential cloud for collaborative apps. You write an app in Rust and compile it to WASM. Every instance of it runs inside attested Intel TDX nodes that Calimero (or you, on a dedicated cluster) operates, and nobody operating them, Calimero included, can read the app’s data.

You don’t run a database, write sync code or manage keys. You write the app’s state and methods; the cluster stores, replicates, encrypts and serves them.

Why use it

Section titled “Why use it”
Self-hosting7 chores
  • Ship and support an on-prem edition
  • Patch the OS and dependencies
  • Manage secrets
  • Configure backups
  • Staff on-call
  • Sit through long security reviews
  • Admins and vendors can still see the data

Your customers have to trust whoever runs the box.

Calimero1 bundle
my-app.mpkfrontend and app logic, signed
  • SandboxApps run as sandboxed WebAssembly and only reach their own state through the node.
  • SecurityRead-only images with no SSH. Keys are released only to nodes that prove their image.
  • MaintenanceSigned, versioned bundles. On Calimero Cloud, Calimero runs the nodes and their upgrades.
  • PrivacyNobody, including Calimero, can read data inside a sealed node. Storage is encrypted at rest.
  • ServerlessInstall a bundle, not a server.

Your customers check the node's proof themselves.

Today, control means hosting. With Calimero you ship one signed bundle, and every sealed node proves which image it runs before it gets any keys.

The pieces

Section titled “The pieces”
Term What it is
Cluster A set of merod nodes, each in an Intel TDX VM, that share one system state and one storage key. Calimero runs shared clusters, where many developers’ apps run side by side, and dedicated clusters, which belong to one customer.
Package Your app as a signed .mpk: one or more WASM services, an optional frontend, and a manifest naming the package and version. Published to the app registry.
App instance One running copy of a package, with its own state, its owner and an access rule. Each instance is replicated by its own Raft log on (by default) three nodes. Its init runs once, when it is created.
Account A person. Their passkeys are their devices; they sign in with one and get a short session token. Machines act for an account with an API key.
Organization Members with a role (guest, member, admin, owner) and nested teams. An instance created in an organization is reachable by its members, or by one team’s.
Operator Whoever runs the machines. It sees counts and replication status, never app data.

How a request is served

Section titled “How a request is served”
A request on a Calimero clusterA client verifies the node's TDX attestation and opens a sealed channel to it. The node checks the caller against the cluster's system group and forwards the call to the app's leader, which runs the WASM and replicates the result to the app's other replicas. Nodes get their storage key from mero-kms only after proving their image.Clientmero-js · PythonRust · meroctl1 · verify2 · sealCluster · attested Intel TDX nodesAny nodechecks caller andaccess against thesystem group3 · forwardApp group · its own Raft logLeaderruns the WASM callReplicaapplies diffReplicaapplies diff4 · replicatemero-kmsstorage key after proof
The client trusts nothing on the network: it checks the node's quote against a signed mero-tee release before it sends anything. Nobody operating the nodes can read the app's state.
  1. Verify. The client fetches the node’s attestation: a TDX quote that binds the node’s transport key and names the signed mero-tee release it runs. It checks the quote against Intel’s collateral and the release’s published measurements.
  2. Seal. Only then does it open a sealed channel (Noise NK) to that key. Every request travels inside it, so a proxy, a load balancer or the host sees sizes and timing, nothing else.
  3. Check. Any node takes any request. It checks the caller’s credential and the instance’s access rule against fresh cluster state, and forwards the call to the instance’s leader over an attested peer channel.
  4. Run. The leader runs the call against the app’s WASM, appends it with its state change to the instance’s log, and answers with a receipt signed by an attested key. The other replicas apply the change.

Each node gets its storage key from mero-kms only after proving its image, and keeps everything on disk sealed under that key.

What this gives you

Section titled “What this gives you”
  • Nobody sees the data. The host, the network and the operator see encrypted traffic, sealed disks and counts.
  • Users can check it. Any client can verify every replica of an instance and the rules the cluster runs under, and every answer carries a receipt. See Verify a cluster.
  • Calls are ordered. Calls to one instance apply in one order, and strong reads go through the leader. An instance keeps serving while a majority of its replicas run.
  • One model, two places. The same app runs on Calimero Cloud’s shared clusters, on a dedicated cluster, or on nodes you run yourself.

Next: see the whole path on How it works, run it locally in the Quickstart, or start building an app.