Home / Platform
How it works · Trusted execution
One attested node, every layer built in.
A Calimero app is one signed bundle that runs on identical sealed nodes, each a trusted execution environment (TEE). The node brings the runtime, replicated state, storage, networking and keys, so the stack you would otherwise build, seal and attest piece by piece is already there.
- 1node image to measure and attest
- 8layers in every node
- 2of them you write: logic and frontend
- 1operation upgrades the app on every node
02 · Embedded frontend
The UI ships inside the app.
Your web frontend is signed with your logic, so the signature covers the UI as well as the logic. The node serves it from the signed package, at the package's own address.
- Signed with the app: the signature covers the UI as well as the logic.
- Served by the node: no frontend host, no CDN to configure.
- No remote scripts: the page only loads its own files.
Read moreShow less
cargo mero bundle --key my-key.json --frontend-dir ./dist frontend · index.html + 11 files · signed ✓ dist/com.example.my-app-1.0.0.mpk
Signed with the app
Each frontend file is recorded with its size and hash, so the signature covers the UI as well as the logic.
Served by the node
The node serves the frontend straight from the signed
.mpk, checked before a byte goes out, at the package's own origin. A sign-in there reaches only that package's app instances.No remote scripts
The served page only loads its own files, so a third-party script can't slip in.
03 · Sharded monolith
Back to the future
Scale by adding nodes, not tiers.
A Calimero app is a sharded monolith: one sealed app on identical nodes, its data split into app instances, each replicated across three or more of them. Serverless-like scaling, with no central database to run.
- Each app instance lives only on the attested nodes that replicate it.
- Its own Raft log applies calls in one order, and it keeps serving when a node is lost.
- One image to attest, one kind of node to add.
See the fleet and the stackShow less
A sharded monolith: the same sealed app on every node, app instances across the fleet
Microservices and a central database in TEEs
- To scale, grow each tier and re-attest each one.
- One outage or breach touches every customer.
Calimero: sharded monolith
- Every node runs the whole app; each app instance is replicated by its own Raft log across three or more nodes.
- An app instance keeps serving when a node is lost.
| Question | Microservices + central database in TEEs | Calimero sharded monolith |
|---|---|---|
| Where data lives | One cluster holds every customer | Each app instance only on the attested nodes that replicate it |
| How you scale | Bigger database, replicas, eventually manual sharding | More app instances and nodes; app instances are independent |
| Blast radius | One outage or breach reaches every tenant | One app instance |
| What you seal and attest | Every tier: services, database, replicas, backups | One node image |
Inside every node
- 01FrontendYou writeYour web UI, shipped inside the signed bundle
- 02Application logicYou writeYour code, in Rust
- 03RuntimeBuilt inWebAssembly sandbox
- 04Replicated stateBuilt inEach app instance replicated across attested nodes
- 05StorageBuilt inEncrypted at rest
- 06NetworkingBuilt inEncrypted node-to-node connections
- 07Identity and accessBuilt inPasskeys, organizations, teams, API keys
- 08Sealed hardwareBuilt inIntel TDX attestation on Calimero Cloud
One deployable. Every layer included. Nothing to wire.
04 · Upgrades
Ship once. Nothing to re-attest.
A node's measurements cover the node image, not the apps on it. Publish one signed bundle and one operation upgrades the app on every node. The app's owner approves it with a passkey, unless the deployment gives app upgrades to its operator.
- App upgrades don't change node measurements or keys.
- No new policies and no secrets to move.
- Each app instance migrates its own data when it is upgraded.
- Publish signed app bundle v2logic and frontend together
- One upgrade operationon Calimero Cloud or your own cluster
- Each app instance migrates when it is upgradedthe same result on every node
Node image, measurements and keys unchanged
Compare with microservices in TEEsShow less
In TEEs every microservice release is a security change; a Calimero app release is not
Microservices inside TEEsper release
Calimeroper release
- Each app instance applies calls in one order
- It keeps serving when a node is lost
| Question | Microservices / self-hosted | Calimero |
|---|---|---|
| Unit of release | Each service, and each customer install | One signed bundle: logic and frontend together |
| Rollout | Your ops team, then each on-prem customer | One upgrade operation |
| Data migration | Central database migration, often a maintenance window | Per app instance, when it is upgraded, the same result on every node |
| Attestation and keys | New measurements, policies and secrets per release | Unchanged by app upgrades |
05 · Why not DIY
Why not just put your stack in a TEE?
A confidential VM protects one machine. Your app is ten.
Put microservices, a database and a queue into enclaves and every part needs its own attested image, every hop needs attested encryption, and your disks, backups and TLS proxy still sit outside.
- One attested node instead of an image per service.
- Sealed transport end to end, not TLS at a proxy.
- Keys, replication and upgrades built in, not built by you.
See the full comparisonShow less
One attested node replaces a stack of enclaves, proxies and keys
DIY: microservices and a database in TEEs5 TEE images
Each box is its own image to measure and attest.
Dashed red: data readable outside the enclave.
Calimero: one attested node1 image
| Question | DIY: microservices + database in TEEs | Calimero |
|---|---|---|
| What gets attested | Every service, database, proxy and sidecar separately | One read-only node image; the quote can also bind your app's code hash |
| Traffic in | TLS ends at a proxy outside the enclave | Sealed transport: encrypted end to end to a key the hardware quote vouches for |
| Data at rest | Volume encryption and key release you build | Storage keys released only to nodes matching the signed release policy |
| Replication | Database replicas, failover, consensus per enclave | Built in: each app instance is replicated by its own Raft log across three or more attested nodes |
| New replicas | Provision, attest, hand over secrets by hand | Keys go only to nodes that prove their image |
| Who reads what | Database roles under one admin | Organizations, teams and scoped API keys, enforced inside the node |
| On-prem | Rebuild and run the whole stack per customer | Same app bundle on a dedicated cluster of the same attested nodes |
Calimero is not lift-and-shift: you write the app's logic against the Calimero SDK. You write the logic; we bring the stack.
06 · Next
Build one, or check our work.
- Developers
Build on Calimero
The quickstart, SDKs and tools.
cargo mero bundle --dev --no-iconStart building - Security
Don't trust us. Verify us.
The five-step attestation trail, sealed transport and what we can and can't see.
How we prove it - Products
Calimero Cloud
Sealed nodes, run for you, with every node's attestation in the console.
Explore Cloud
Your customers want control. You want to ship.
Start on Calimero Cloud, or build on the open-source runtime.