Deployment

An Atoll deployment publishes an immutable Program and constructs a Store fleet for it. Redeploy creates a new Program rather than mutating code already used by running invocations. The runtime can reuse unaffected Stores and, under strict conditions, adopt quiescent Unit instances.

Artifacts

A Program contains one compiled artifact per link group. Each artifact has:

• a WebAssembly module;
• its own linear-memory and allocator contract;
• exported Unit methods and scheduler functions;
• runtime ABI and layout metadata;
• debug, cancellation, and migration metadata;
• a migration-safety flag for stored function values.

The Unit manifest maps stable program-wide UnitId values to those groups. Regrouping Units does not renumber them within the same Program contract.

Store layouts

Deployment decides which Units each Store hosts. Two useful shapes are:

all Units on every Store
Store 0: groups A, B, C
Store 1: groups A, B, C

bundle per Store
Store 0: group A
Store 1: group B
Store 2: group C

The first shape maximizes routing flexibility. The second creates a smaller replacement boundary: changing group B need not respawn a Store that only hosts A.

The runtime instantiates only the link groups required by a Store’s hosted Units.

Cutover

AtollRuntime atomically swaps the current Program and routing fleet.

• an invocation that already captured the old Program finishes against it;
• a newly routed invocation observes the new Program after cutover;
• immutable unchanged artifacts can be shared between Program versions;
• singleton pins remain only where their Store survives the cutover.

This is an in-process code cutover. It does not coordinate a distributed cluster upgrade by itself.

Group redeploy

Program::redeploy_group compiles the changed group and shares unchanged artifacts by reference. The runtime then compares artifact identity and respawns only Stores that host changed groups.

Topology determines the practical granularity. If every Store hosts every Unit, changing one group still affects the complete fleet. With bundle-per-Store placement, unchanged Store reactors and their live Unit instances can remain untouched.

Plain redeploy drains or replaces affected Stores. It does not promise to preserve their in-memory Unit state.

Preservation

redeploy_preserving attempts to adopt eligible Unit instances into the new Program. Adoption requires:

• a quiescent instance at a scheduler safepoint;
• matching layout fingerprints;
• migration-safe old and new link groups;
• no incompatible stored function identity;
• no debugger-shelved invocation;
• no unresolved arena-generation pin;
• only transferable host resources;
• successful destination allocation and resource reattachment.

An adoption failure is counted and reported, then the runtime follows the configured drain/recreation path. It does not reinterpret incompatible bytes.

Stored FunctionId values are a notable barrier because they are dense and build-local. A group that can retain such values is migration-safe only when the compiler proves a compatible mapping.

Migration

Same-version migration moves one UnitInstance between Stores:

source stops placement
  → instance reaches safepoint
  → in-flight I/O drains or cancels
  → resources detach
  → arena bytes copy
  → source cache entry is removed
  → destination resources attach
  → destination publishes instance

Removal before publication prevents two Stores from exposing the same mutable state. If preparation fails, the source remains authoritative. If destination adoption fails after exclusive removal, the operation reports failure and uses its recovery path rather than publishing two copies.

The Host I/O chapter lists currently transferable and nontransferable resource kinds.

Draining

Draining a Store changes its liveness state so new routing avoids it. The runtime first verifies that eligible peer Stores can host the affected Units, then moves each migratable instance.

Drain can fail when:

• no peer hosts the Unit’s link group;
• a singleton has no legal destination;
• an instance is busy and cannot reach the deadline;
• a debugger has shelved it;
• a host resource cannot migrate;
• its layout or arena state fails validation;
• destination capacity or initialization fails.

Operational code should treat drain as a fallible workflow, not a signal that all state has already moved.

Failure matrix

At-most-once external effects are not inferred from this table. A caller may need an idempotency key when retrying work whose result was lost.

Observability

Redeploy emits structured events that distinguish:

• compilation and cutover;
• unchanged Store reuse;
• Store respawn;
• attempted, successful, and failed instance adoption;
• drain and migration outcomes.

Operators should monitor adoption failures and reasons. A successful Program cutover with zero preserved instances can be correct but have a very different state and latency profile from a fully preserving cutover.

Compatibility

Compatibility is explicit metadata, not an optimistic byte comparison. The compiler and runtime jointly assess:

• frozen runtime ABI version;
• canonical layout fingerprints;
• Unit and method identity;
• group exports and allocator capabilities;
• debug and cancellation metadata;
• stored function-value safety;
• host-resource transfer support.

A rejection is a safety result. It prevents silent state corruption and should normally fall back to draining, durable-state reload, or a cold instance.

Boundaries

Deployment does not provide:

• durable persistence for a Unit arena;
• distributed singleton election;
• automatic data-schema migration;
• replay of external side effects;
• cluster membership bootstrap or rolling-upgrade orchestration.

Those concerns need explicit application, database, or clustering protocols.