Resource limits, and an honest account of what they do not cover.

Pass a limits map to wasm:instantiate/3, or per call. Reach for the presets when you have not measured anything yet: getting these right matters most for the people least likely to tune them.

Limits = wasm_limits:untrusted(),
{ok, Inst} = wasm:instantiate(Module, Imports, Limits).

What you get

max_memory_pages bounds what an instance can reach, not what it created. An imported memory counts, because a module that imports one can address every page of it, and it counts once however many import slots name it. A garbage collected heap counts the same way and for the same reason: linked instances share one store, so it is charged once and bounded by whichever of them was promised least. Its objects are ETS rows rather than atomics pages, and are converted at the page size purely so that one number bounds both. Growing a memory two instances share therefore needs room under both ceilings: the stricter one wins, or the more generous instance would grow a memory past what the other was promised. Refusal is the value -1 from memory.grow, as the specification requires, and an instance that cannot fit its declared memory at all fails to instantiate.

What putting it in a process does not give you

This section exists because "each instance is in a process, so it is isolated" is the most tempting wrong claim available about this design. A process is a fault and lifecycle boundary. It is not a security boundary, and these gaps are real:

• Linear memory is invisible to max_heap_size. atomics arrays are off-heap. A module can exhaust node memory without its process heap moving at all. This is why page accounting is explicit and node-wide in wasm_engine rather than left to the BEAM.
• Per-instance limits do not bound concurrency. No single instance can monopolise a scheduler, because the interpreter is preemptible. But ten thousand instances each behaving perfectly will still saturate every scheduler. To bound that you need a pool or a concurrency cap above this layer; a per-instance limit cannot see it.
• The atom table is node-wide and never reclaimed. One reachable binary_to_atom on anything a guest controls would be a permanent leak and eventually a node kill, immune to every limit here. That covers the module bytes and the strings a guest passes across the WASI boundary, and wasm_prop_SUITE asserts both: not that the count never moves, since host libraries intern atoms when they lazily load a module, but that it does not grow with the number of distinct strings a guest sends.
• Host functions are the real attack surface. Limits constrain WebAssembly, not the Erlang code you supply as an import. A host function that reads a file, allocates without bound, or blocks forever is outside all of this. Capability-based WASI (wasi_preview1) is how the standard ones get addressed; imports you write yourself are yours to bound.
• Timing and microarchitectural side channels are not addressed. Nothing here prevents a co-tenant module from measuring shared cache behaviour. A shared BEAM node is not a boundary against that class of attack; only OS-level or hardware separation is.
• fuel bounds work, not time. A host call that blocks consumes no fuel. Wall-clock bounding is timeout, and you need the two together.