Development

Languages

Canisters are compiled to WebAssembly. Application code can be written in Motoko, Rust, JavaScript, Python and other languages that target Wasm.

Because a canister runs on the Internet Computer Protocol, the public ICP developer ecosystem applies directly: the SDK, the documentation, the libraries and the community answers are the same. An application built for the public Internet Computer runs on a Cloud Engine unchanged.

Programming model

Two properties change how software is written, and both affect effort estimates:

Orthogonal persistence. State lives in ordinary program variables and survives upgrades automatically. There is no ORM, no schema migration and no database connection. For most applications there is no database at all. Where an application does want a relational store, it embeds one inside the canister rather than connecting out to one — see Integration Patterns.

Determinism. Every node executes the same code and must produce the same result. Wall-clock time, randomness and external calls are therefore obtained through protocol mechanisms rather than from the language runtime. See Cloud Engine.

Local development and testing

The toolchain is the standard Internet Computer one, documented upstream rather than reproduced here.

• icp-cli creates projects, builds canisters and deploys them, to a local replica or to a running engine.
• PocketIC runs a replica in-process inside a test suite, with bindings for Rust, JavaScript/TypeScript and Python. This is where upgrade tests belong: install a canister, write state, upgrade it, assert the state survived.
• ICP Ninja is a browser IDE for trying something without a local setup at all.

There is no shared test engine. Testing happens against a local replica or PocketIC; anything that has to run on real engine hardware means a second engine.

See the developer tools documentation for setup and the full toolchain.

Deployment

Deployment is role-based and audit-logged, and can be shared across parties that do not trust each other. Whoever holds deployment control can change any behaviour of a canister, which makes this the platform’s most consequential permission; see Operations.

CI pipelines deploy without interactive prompts. A deployment identity is imported from a key file and selected per command, and an encrypted key is unlocked from a file rather than a prompt. The upstream guidance is to keep that key as a CI secret and give the pipeline its own identity holding only the permissions it needs — the same separation the role-based control above exists for.

Environments are project configuration, not a platform concept. A project declares its environments and selects one at deploy time, and each deploys its own canisters with their own ids. Staging and production can therefore be separate canisters on one engine, or separate engines.

Which of the two a client needs follows from the cost model below: extra canisters on an existing engine consume its capacity and nothing more, whereas a staging engine is a second engine, paid for as a unit.

Identities, environments and the deployment commands themselves are covered in the icp-cli documentation.

How capacity is paid for

On the public network, computation is metered per message in cycles. A canister holds a cycle balance, spends it as it runs, and stops when it runs out — so an application team carries an ongoing funding obligation and an unpredictable bill.

A Cloud Engine has no per-message accounting. The engine is paid for as a unit. There are no cycles to top up, no per-call charge, and no canister that halts because its balance ran dry.

Sizing is done by choosing how much of a node’s capacity the engine receives, which also decides whether it shares a machine with other engines. The hardware behind it and the rules governing how many engines fit on a machine are described in Cloud Engine. Resizing later is possible without interrupting the application.

Support services

Swiss Subnet provides architecture reviews structured against ICP best practice, scoped proof-of-value design, canister libraries and ready-made deployable modules.