Cloud Engines

The asset canister is the clearest deployed example. The documentation describes it as the canister that serves a web frontend: it stores the built assets, serves them over HTTP, and certifies its responses so that a browser can verify them against the network's root key. It supports SPA routing through a configuration file and it does not render on the server, which is a real constraint on what a frontend can do.

The Internet Identity canister is another. It provides authentication as a service to any application that integrates it, and the documentation describes it as a system canister that applications call rather than reimplement. The Internet Identity page covers the flow.

The chain integrations are a third. The Bitcoin canister, the Ethereum integration and the chain-key token minters are services that any canister can use, and the documentation describes them as deployed infrastructure rather than as application code. The Chain Fusion page covers the architecture.

The network's public material describes a broader ambition: a full application stack that a developer can assemble from on-chain components without leaving the network. That includes storage and database services, a compute service for long-running jobs, and a frontend service that goes beyond static assets. Some of these are available in some form; others are described as direction rather than as shipped products.

This page does not enumerate a roadmap, because a roadmap is a statement about intent and it changes. What can be said with confidence is that the architecture is coherent: each engine is a canister, each is addressed through Candid, and each is subject to the network's ordinary rules. A developer evaluating the approach should check the current documentation for which engines exist rather than relying on a description of the plan.

The honest framing is that the network provides a substrate — canisters, consensus, threshold signing, cycles — and the Cloud Engine architecture is a way of composing services on top of it. The substrate is deployed and documented. The composition is partly deployed and partly in progress, and the difference matters to anyone deciding what to build on.

The framing matters because it changes what a developer has to reason about. In a conventional stack, the boundary between the application and the platform is a contract with a vendor: the database is managed, the storage is durable, the queue is eventually consistent, and the guarantees are whatever the vendor's documentation says. On the network, the boundary is a canister interface, and the guarantees are the network's.

That is a different kind of responsibility. A developer who uses a storage engine canister is depending on that canister's code and on whoever controls it, and the documentation's guidance about verifying a canister's controllers applies. The canisters page covers the control model.

The upside is composability without permission. A canister can call any other canister whose interface it knows, with no account, no API key and no vendor relationship. That is the property the Cloud Engine architecture is built to exploit, and it is a genuine difference from the cloud model rather than a rebranding of it.