Choosing a runtimealpha
Where to build and where to run your actors, depending on what you're making.
You always build with moxzi. What you choose is where the wasm runs. Since every runtime takes the same module, you can change your mind later without rebuilding.
By use case#
| You want to | Use | Notes |
|---|---|---|
| Ship a canister to the Internet Computer | moxzi build, then dfx or icp to deploy | The wasm installs like one built by moc |
| Develop and test an actor locally | moxzid | Starts in under a second. No replica, no dfx |
| Run actors as a backend service | moxzid | Durable state, upgrades, timers, HTTPS outcalls, a JSON API |
| Serve a website from an actor | moxzid --web <actor> | The actor's http_request method answers at the root URL |
| Run actors in a web page | moxzi-web | State persists to IndexedDB. The compiler can also run in the page |
| Add Motoko actors to an existing platform | moxzi host new <platform> | Dapr, Restate, Orleans, Akka/Pekko, Proto.Actor, Temporal, Ray, wasmCloud, Cloudflare Workers |
| Prove which source produced a wasm | the on-chain builder (moxzi build --remote) | The build runs in a canister anyone can inspect. Costs cycles |
| Write a game | moxzi-game | Game logic is Motoko actors; a shared player draws it |
What each runtime provides#
moxzid | moxzi-web | Internet Computer | |
|---|---|---|---|
| Update and query calls | Yes | Yes | Yes |
| Rollback on trap | Yes | Yes | Yes |
| Upgrades with state | Yes | Yes | Yes |
| Timers | Yes | Yes, when the page drives them (timerMs) | Yes |
| Actor-to-actor calls | Yes | Yes, within the page | Yes |
| HTTPS outcalls | Yes | Worker mode, with COOP/COEP headers | Yes |
| Durable state | Snapshot and write-ahead log | IndexedDB | Replicated |
| Instruction limits | Yes | Opt-in (meter: true) | Yes |
| Certified responses | No | No | Yes |
| Replication | Single node | Single tab | Subnet consensus |
On an actor platform, moxzi runs the actor's code and the platform provides identity, placement, durable storage and timers. Each platform page says what that platform covers.
Certified responses need a subnet's threshold signature, so only the Internet Computer can produce them. If your clients verify certificates (for example, @dfinity/agent's Actor class), they need a real canister.
Building locally or on-chain#
A local build and an on-chain build of the same source produce the same wasm. The on-chain builder is for when someone else needs to verify how a module was built: a DAO approving an upgrade, an auditor, a user of your canister.
Local moxzi build | On-chain moxzi build --remote | |
|---|---|---|
| Time | Seconds | Minutes |
| Cost | Free | Cycles, paid in advance and partly refunded |
| Verifiable by others | No | Yes, with moxzi verify |
| Source privacy | Stays on your machine | The canister's operators can read uploaded files. Builds from published mops packages upload nothing |
See On-chain builds.
Limitations#
| Limitation | What to do |
|---|---|
moxzid is a single process | Run several servers with different actors. There's no clustering |
| A browser page can't interrupt a running call | Use worker mode (worker: true), which supports deadlines |
| Deeply nested generated code can overflow the browser's stack | Compile with the CLI, or split the generated expressions |
| One compiler canister runs one build at a time | Builds queue. Deploy more canisters for parallel builds |
Next steps#
- Your first actor if you haven't done it yet.
- Running moxzid for the server.
- moxzi-web overview for the browser.