Cloud Engine
Properties
Section titled “Properties”An engine provides five properties.
| Property | What it means |
|---|---|
| Replicated | All storage and compute are replicated across every node in the engine |
| Fault tolerant | Up to f of 3f + 1 nodes may fail or act maliciously without the engine losing correctness or availability |
| Tamper-evident | An adversary controlling up to f machines cannot corrupt stored data or alter execution results |
| Verifiable | Every response is threshold-signed and can be checked by the client against a single public key |
| Single tenant | One operator holds the full capacity of the engine and decides who may deploy to it |
Deployment unit: the canister
Section titled “Deployment unit: the canister”Applications are deployed as canisters. A canister is a unit of code plus its own persistent state, replicated across every node in the engine.
Two things distinguish it from a container:
- State lives inside the program. Data is held in program variables and persists across upgrades automatically, as if the process had run forever without restarting. There is no external database to attach, and for most applications, none to operate.
- It is replicated. Every node runs the same canister over the same state. No single node can alter it, and there is no primary instance to fail over from.
Canisters are compiled to WebAssembly. Source languages include Motoko, Rust, JavaScript and Python; see Development.
Capabilities other smart contract platforms lack
Section titled “Capabilities other smart contract platforms lack”Most smart contract platforms constrain contract code severely: it executes only when something outside calls it, it cannot reach any system beyond its own ledger, it holds no secret, and it cannot serve anything to a browser. The Internet Computer Protocol lifts each of those constraints.
| Capability | What a canister can do | Served by |
|---|---|---|
| Timers | Schedule its own future execution, with no external caller | The engine |
| HTTPS outcalls | Call an external HTTP API directly, with no oracle | The engine |
| On-chain randomness | Obtain verifiable randomness, with no trusted source | The engine |
| Web serving | Serve its own frontend, with no separate web hosting | The engine |
| Chain-key signatures | Hold and use Bitcoin and Ethereum keys, with no bridge | ICP mainnet |
| vetKeys | Derive and manage encryption keys no node can learn | ICP mainnet |
Each row also removes a component that a conventional stack would otherwise have to run alongside the application: a scheduler, an oracle, a key management service, a web tier. What the capabilities imply for connecting to existing systems is covered in Integration Patterns.
The two that depend on ICP mainnet
Section titled “The two that depend on ICP mainnet”All seven capabilities are available on a Cloud Engine today, but the last two are not served by the engine itself. No key material for them is held inside the engine, so a canister obtains a signature or a key by calling ICP mainnet and awaiting the reply.
This is the same dependency described in Swiss Subnet and Cloud Engines for engine creation. Chain-key signing inside an engine is planned; see Limitations.
Two different things are called threshold signatures, and only one of them depends on mainnet:
| Mechanism | What it signs | Served by |
|---|---|---|
| State certification | Every response the engine returns to a caller | The engine |
| Chain-key signing (tECDSA, tSchnorr) | Payloads a canister signs as its own external identity | ICP mainnet |
State certification is what makes a response verifiable against the engine’s public key, and it works today on every engine — see Trust and Security Model. Chain-key signing is what lets a canister hold a key on another blockchain, and that is the one served by mainnet.
Isolation between customers
Section titled “Isolation between customers”An engine is single tenant: one client holds its full capacity and decides who may deploy to it. Isolation is therefore a property of the deployment model rather than a mechanism that has to hold under adversarial multi-tenancy.
One qualification matters. An engine can be sized so that several engines fit on one physical machine, in which case machine-level co-tenancy exists even though engine-level tenancy does not. An engine can instead be sized to occupy whole machines, and then no sharing occurs.
The distinction decides two things: whether another workload runs on the same hardware, and whether the engine’s memory is encrypted against the machine’s operator. A client who requires either should specify an engine that occupies whole nodes.
What separates two engines on one machine
Section titled “What separates two engines on one machine”Virtual machine isolation: each engine on a shared node runs in its own VM under the node’s hypervisor. That boundary holds between the engines. It does not hold against the operator of the machine, who controls the hypervisor and can therefore read guest memory — the limitation set out in Trust and Security Model.
An engine alone on its node does not have this exposure: its memory is encrypted under SEV-SNP and unreadable to the host. Work in progress: the same for several engines on one node. Implementation is underway at the DFINITY Foundation, so the date is not Swiss Subnet’s to give. It addresses the second boundary rather than the first — memory encryption makes an engine’s memory unreadable to the operator while engines continue to share hardware. See Limitations.
Scaling
Section titled “Scaling”Read and write capacity scale by different mechanisms.
| Axis | Mechanism | Limit |
|---|---|---|
| Query capacity and resilience | Add nodes to the engine; nodes can be placed near demand | Each added node adds a full replica, so cost grows linearly |
| Write capacity and storage | Migrate the engine to the next size up | Bounded by the largest engine a single node can carry |
| Beyond that | Split the engine in two | Requires a multi-canister application design |
Scaling a single canister’s write throughput beyond the capacity of one engine is not possible by adding hardware. It requires the application to be split across several canisters, which is a design decision that is expensive to retrofit. Teams should decide early whether their write path will ever need this.
Because an engine is a network configuration rather than a fixed set of machines, node additions and hardware class changes happen without interrupting hosted applications.
Engine sizing and hardware
Section titled “Engine sizing and hardware”An engine is sized by how much of a node’s capacity it receives, which also determines how many engines fit on one physical machine. The sizes available and the capacity each one carries are established per engagement.
Two consequences of sizing are platform properties rather than commercial ones: whether the engine shares a machine with other engines (isolation), and whether its memory is encrypted against the machine’s operator (Trust and Security Model).
A physical node carries engines of one size at a time. Mixing differently sized engines on a single machine is not supported today.
Node hardware
Section titled “Node hardware”Current generation-2 node specification:
| Property | Value |
|---|---|
| RAM, physical | 512 GB |
| RAM, usable by engines | 480 GiB — the remainder is reserved for the host |
| CPU | 2 sockets × 16 cores × 2 threads = 64 vCPU |
| Physical disk | ~30 TB |
CPU and RAM map 1:1 onto what the engine requires — there is no virtualisation overhead layer between the engine and the machine. vCPU counts are threads, and core count determines how many query and update calls can be processed concurrently. Its main effect is on throughput rather than on latency: more cores do not make an update call faster, because that floor is set by consensus.
Storage does not map 1:1. Only around 10% of a node’s physical disk is currently usable by the engine. This ratio is a protocol-side constraint that the DFINITY Foundation is working to improve; when it does, existing hardware yields more usable storage without replacement.
Resource limits
Section titled “Resource limits”These figures come from the Internet Computer Protocol and are published by the DFINITY Foundation. Any engine is created with the mainnet defaults, and they could in principle be adjusted per engine in future.
| Limit | Value |
|---|---|
| Stable memory per canister | 500 GiB |
| Wasm heap, wasm32 | 4 GiB |
| Wasm heap, wasm64 | 6 GiB |
| Wasm module, total size | 100 MiB |
| Wasm module, code section | 10 MiB |
| Ingress message payload | 2 MiB |
| Inter-canister payload, cross-subnet | 2 MiB |
| Inter-canister request, same subnet | 10 MiB |
| Response size, replicated | 2 MiB |
| Response size, query | 3 MiB |
| Queue between a canister pair | 500 messages |
| Instructions per update call, heartbeat or timer | 40 billion |
| Instructions per query call | 5 billion |
| Instructions per install or upgrade | 300 billion |
| Stable memory read per replicated message | 2 GiB |
| Stable memory written per replicated message | 2 GiB |
Source: Resource limits, ICP developer documentation, retrieved 2026-08-19.
Engine-level limits
Section titled “Engine-level limits”Three limits are set by the engine’s deployment rather than by the protocol.
| Limit | Value |
|---|---|
| Total memory per engine | Determined by the engine’s size |
| Usable share of a node’s physical disk | ~10% today |
| Modifiable state per execution round | ~1/3 of the engine’s RAM — see below |
The 2 TiB per-subnet memory figure published for the public Internet Computer is a mainnet capacity number and does not describe a Cloud Engine. Storage actually available to an engine is determined by its size and by the disk ratio above.
The modification limit per round
Section titled “The modification limit per round”A canister may hold up to 500 GiB of state, but only about the equivalent of one third of the Cloud Engine’s RAM may be modified in a single execution round. More may be read; the limit is on what changes. The reason is checkpointing: a round that modifies more than that takes too long to checkpoint safely.
For application design this means bulk rewrites of large state have to be spread across rounds. A migration routine that rewrites an entire dataset in one call will not complete, and the failure appears at the scale of production data rather than during development against a small test set.
No per-message accounting
Section titled “No per-message accounting”On the public Internet Computer, computation is paid for per message in cycles, and a canister that runs out of cycles stops. A Cloud Engine does not work this way: the engine is paid for as a unit, and there is no per-message accounting for the client to manage or fund.
For an organisation used to consumption billing, the practical consequence is that capacity is fixed and predictable rather than elastic and metered — the engine does not grow to absorb a traffic spike, and it does not bill for one either. See Development.