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 it works
End to end
Section titled “End to end”- WriteRust logic on the SDK, and a frontend
- Bundle & sign
cargo mero bundle --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
(
cargo mero bundle). The signature covers the UI too. See Build an app. - 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 & instances.
- 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.
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_org().The full table, and what stops each attack, is on the security model page.
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.