Compilation & install
This is where Neutron stops resembling a normal app platform.
Installing an app does not deploy anything. It rebuilds your operating system: the kernel plus every app you already have plus the new one are assembled into a single Motoko actor, that actor is compiled to WebAssembly, and your canister replaces its own code with the result.
| Page | Covers |
|---|---|
| Actor assembly | How manifests become generated Motoko — wrappers, namespaces, environments, capability projections |
| Browser compilation | The compile pipeline that runs inside a browser tab |
| Install transaction | Staging, journalling, self-upgrade, verification, commit, and recovery |
| Managed memory | Immutable schemas, migration edges, retirement, and uninstall |
| Backend dependencies | Typed, acyclic composition between installed apps |
Why this design
The alternative — one canister per app — would give free isolation. Neutron gives that up on purpose, and gets three things back:
Direct typed inter-app calls. A wallet app can receive a contacts app's
lookup function as an actor-local Motoko function reference. The call itself
has no inter-canister latency or cycle transfer; the exported signature may
still be synchronous, async, or async* and keeps its authored failure
semantics.
One identity, one interface, one upgrade. The user's canister has a single Candid interface, a single cycle balance, a single asset store, and one atomic upgrade path across everything installed.
Actual integration. Apps compose at the type level. The compiler verifies that a consumer's expectation of a provider's function still matches after both have been upgraded.
The cost is that the security boundary has to be manufactured. That is what Security is about, and it is why the assembler is so opinionated about namespaces, injection, and what an app's constructor is allowed to receive.