cloud-engine-canisters
Cloud Engine Canisters
What This Is
A cloud engine is a user-owned slice of Internet Computer capacity, administered from a web console (see the deploy-to-cloud-engine skill for getting code onto one). Engines run on a dedicated CloudEngine subnet type with a free cycles cost schedule: nothing an engine canister does is metered in cycles — execution, storage, messaging, and HTTPS outcalls all cost zero — and engine canisters hold a 0 cycles balance by design.
That model comes with protocol-enforced call rules. Code that works on a normal Application subnet can fail on an engine, and the failures look like cycles or consensus problems rather than what they are: code written for the wrong subnet type. The rules:
| Rule | On a cloud engine |
|---|---|
| 1 | Never attach cycles to any call — remove (with cycles = …) and cycle-attaching wrappers |
| 2 | Cross-subnet calls must be bounded-wait — (with timeout = N) in Motoko, Call::bounded_wait in Rust |
| 3 | HTTPS outcalls: ordinary code, zero cost — keep the standard wrapper, transform on your own canister, never through the proxy |
| 4 | Cycle-bearing cross-subnet targets (XRC, threshold signing, vetKD) go through the console proxy canister |
Rule 1 — Never attach a cycles amount you computed yourself
Engine canisters hold 0 cycles and there is nothing to pay for: under the engine's free cost schedule every fee an Application-subnet canister would pay (execution, message transmission, HTTPS outcalls, threshold signing, vetKD, storage) is charged as zero.