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.
How Calimero works
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”- 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.
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.
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. |
End to end
Section titled “End to end”- WriteRust logic on the SDK, and a frontend
- Bundle & sign
meroctl app pack --key - Publishto the app registry, private to your org or public
- Deployfrom the Cloud console: shared or dedicated cluster
Every node checks the package signature before it runs it.
Org · acmenotesown state · init {"title": "Acme"}
Org · globexnotesown state · init {"title": "Globex"}
Each instance is replicated by its own Raft log across three nodes.
mero-kmsreleases a node's storage key only after its quote matches the signed release
Governance · fixed at genesis, attested
- Node images approved by the app's owner or the operator
- App upgrades approved by the app's owner or the operator
- Outbound hosts the manifest declares, approved before any call leaves
- Verifythe node's quote against the signed release
- Sealopen an encrypted channel to the key the quote binds
- Sign ina passkey for people, a scoped API key for agents
- Calltheir org's instance; every answer carries a receipt
mero-js · Python · Rust · meroctl · the Calimero MCP
- Build. You write the app’s logic in Rust and bundle it with its frontend into one signed package
(
meroctl app pack). The signature covers the UI too. See the example. - Publish. You publish the package to the app registry, private to your Cloud organization or public. The registry checks the signature on upload. See Package & publish.
- Deploy. From the Cloud console you make a version available on a shared cluster (pay per request) or a dedicated one (a flat fee). Every node that installs it checks the publisher’s signature. See Deploy & install.
- An instance per organization. Each organization that uses the app gets its own instance, with its own state and its own init arguments, replicated by its own Raft log across three attested nodes. Your frontend can create them as customers sign up.
- Keys only after proof. A node gets its storage key from mero-kms only after its quote matches the signed release. Everything it writes to disk is sealed under that key.
- Verify, then talk. People and agents verify a node’s quote against the signed release before sending anything, open a sealed channel to the key the quote binds, and sign in: a passkey for a person, a scoped API key for an agent. Every answer carries a receipt. See Verify a cluster.
- Decisions with a name on them. Who approves new node images, app upgrades and outbound hosts is fixed when the cluster is created, and attested with every receipt: the app’s owner, or the operator.
How a request is served
Section titled “How a request is served”- 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.
- 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.
- 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.
- 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.
Who can see what
Section titled “Who can see what”| Who | Read app data | Change the app’s code | Manage members | Verify the build |
|---|---|---|---|---|
| Network, host, cloud providerbetween the client and the VM | ○ NoSees sizes and timing | ○ No | ○ No | ● YesLike anyone |
| Calimero, as operatorruns the nodes | ○ NoCounts and status only | ◐ DependsOnly where the cluster’s rules make it the upgrade approver | ○ No | ● YesLike anyone |
| App developerpublishes the package | ◐ DependsOnly in instances they are a member of | ◐ DependsPublishes versions; each instance’s approver applies them | ◐ DependsOnly in orgs they administer | ● Yes |
| Org owner or adminof the instance’s organization | ◐ DependsWhat the access rule and the app allow | ◐ DependsThe owner approves upgrades where the rules say owner | ● YesRoles below owner, teams, invites | ● Yes |
| Memberreaches the instance | ◐ DependsWhat the access rule and the app allow | ○ No | ○ No | ● Yes |
| Publicnot signed in | ◐ DependsOnly an instance whose access is public | ○ No | ○ No | ● Yes |
env::caller(), env::org_role() and env::in_team().The full table, and what stops each attack, is on the security model page.
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.
Who it’s for
Section titled “Who it’s for”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.
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.
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.
More on each in the use cases on calimero.network.