Skip to content
Calimero docs

Ship the app.Skip the infrastructure.

Write your app once and run it sealed on Calimero Cloud. Every node proves what it runs before it gets keys, every client checks that proof before it sends anything, and nobody operating the nodes, Calimero included, can read the data inside.

Customers want their data on their terms. Delivering that usually means an on-prem edition and everything that comes with it, and the admins can still see everything. Calimero takes that off your plate.

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.
  1. 01 · WriteA Rust appState and methods, with the Calimero SDK. No database, no server.
  2. 02 · Signcargo mero bundleCompile to WASM, embed the ABI, sign it into an .mpk.
  3. 03 · PublishApp registryapps.calimero.network checks the signature on upload.
  4. 04 · DeployCalimero CloudMake the version available on a shared or dedicated cluster.
  5. 05 · RunAn instance per orgEach organization gets its own instance and starting state.
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.
01 · Use case

An on-prem edition without the on-prem work

Your largest customers want the product on their own premises.

The same signed bundle runs on Calimero Cloud and on your customer’s own cluster of the same attested nodes.

02 · Use case

Internal tools for regulated teams

Self-hosting means admins who can read everything; SaaS means a vendor who can.

Organizations, teams and access rules are enforced by every node, and auditors can check which build has access.

03 · Use case

Shared apps between companies

Whoever hosts shared live data can see all of it.

An attested app instance no single party controls; each company sees only what its group is granted.

04 · Use case

Confidential AI agents

Useful agents need your most sensitive data.

Agents act on app data through the Calimero MCP, with their own scoped API key, under the app’s own rules.

The whole path, and who can see what, is on How it works.

For the protocol in depth, running your own nodes, and contributing to Calimero itself, see the core reference.