A cloud engine is not a server, not a serverless runtime, and not a managed Kubernetes cluster. It is a virtual compute platform created by a sovereign network of nodes combined by a mathematically secure network protocol.
You choose the nodes: who runs them, where they run, and what class of nodes to use. The Internet Computer's autonomous governance system and the Internet Computer Protocol do the rest, combining your nodes into a symmetric replicated execution environment that your apps run on. You pay for the nodes you reserve, and there are no servers or operating systems for you to manage.
Your engine is a configuration, not a machine
Because the engine is a configuration rather than a machine, it can be changed without interrupting compute. Add new nodes, remove old ones, change operators or geographies. Your apps do not notice the substrate moving beneath them.
That is also what makes an engine portable. It floats over its underlying compute nodes, so an engine running on one hyperscaler can be moved to another, or onto sovereign hardware, without interrupting the apps it hosts.
Tamperproof execution
Cloud engines are serverless virtual execution environments hosted by mathematically secure networks. There is no vulnerable OS or server and no firewall to maintain, just apps composed from tamperproof software logic and memory running on hackproof infrastructure.
Every response from your engine is signed by the engine's key and can be checked against the NNS (Network Nervous System) root key, so you can verify which nodes ran your code rather than relying on a contractual promise. Running code cannot be changed silently, because every change is replicated and verified across the nodes.
Nodes can fail, cloud engines cannot
Cloud engines symmetrically replicate computation and data across their underlying compute nodes. Redundancy, combined with protocol math, lets an engine withstand everything from nodes going offline to nodes being compromised. A seven-node engine, for example, keeps running when two of its nodes go offline.
The program is the database
If software ran forever, there would be no need for databases, as data could live inside software variables, records, and collections. This is the orthogonal persistence of cloud engines, and it massively simplifies backend software.
A lossy update never ships
The Motoko language's serverless framework can detect when an update to software would cause data loss, perhaps because the migration logic was lossy, and it rejects the change. Your AI tries again. Your customers never notice.
Scale without system changes
Adding new nodes horizontally scales query workloads. Upgrading nodes scales up data updating workloads, and splitting a cloud engine scales those horizontally too. None of it requires changes to your system.
What a cloud engine is not
- Not a VM or container orchestrator.
- Not a serverless function platform.
- Not a managed database.
- Not a place to host legacy Node, Python, or Rails apps.
It is a new substrate for AI-built software: simpler, safer, and native to the way modern agents write code.
Getting an engine running
You create an engine by choosing a node class, then picking nodes from providers that match your geography and compliance needs. The engine provisions on its own and moves to a running state, usually within minutes. Engines run against a prepaid balance of cycles that you top up by card, so you can track burn in real time instead of waiting for an invoice. From there you operate it: deploy apps, view node health, and manage who can administer it.
Related: How do I create an engine? What am I paying for, and how is the price set? Glossary.