Home / Platform
How it works
One attested node, every layer built in.
A Calimero app is one signed bundle that runs on identical sealed nodes. The node brings the runtime, state and sync, 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 and served by the node from the app's own address. No separate site to host, cache or secure.
- 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 --frontend-dir ./dist frontend · index.html + 11 files · signed ✓ my-app.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 from the app's own origin. No frontend host, no CDN to configure.
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 replicated across identical nodes, its data split into contexts placed across them. Serverless-like scaling, with no central database to run.
- Each context lives only on its nodes, under its own key.
- A new node syncs its contexts from peers.
- 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, contexts 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 holds only the contexts placed on it, each under its own key.
- A new node syncs its contexts from peers.
| Question | Microservices + central database in TEEs | Calimero sharded monolith |
|---|---|---|
| Where data lives | One cluster holds every customer | Each context only on its member nodes, under its own key |
| How you scale | Bigger database, replicas, eventually manual sharding | More contexts and nodes; contexts are independent |
| Blast radius | One outage or breach reaches every tenant | One context |
| 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
- 04State and syncBuilt inShared state that merges across nodes on its own
- 05StorageBuilt inEncrypted at rest
- 06NetworkingBuilt inEncrypted node-to-node connections
- 07Identity and accessBuilt inMembers, permissions, 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.
- App upgrades don't change node measurements or keys.
- No new policies and no secrets to move.
- Each context migrates its own data the next time it is used.
- Publish signed app bundle v2logic and frontend together
- One upgrade operation for the groupour cloud and your nodes
- Each context migrates on first usethe 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
- Offline nodes catch up one version at a time
- Writes from older nodes are held, then replayed
| 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 for the whole group |
| Data migration | Central database migration, often a maintenance window | Per context, on first use, the same result on every node |
| Mixed versions | API compatibility code, feature flags | Writes from older nodes held and replayed; offline nodes replay versions in order |
| 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: state syncs as signed operations that converge, no leader |
| New replicas | Provision, attest, hand over secrets by hand | Attested nodes admit themselves when they match the group's policy |
| Who reads what | Database roles under one admin | Group keys and capabilities enforced by every node |
| On-prem | Rebuild and run the whole stack per customer | Same app bundle on any Calimero node |
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.