Server-side WebAssembly in 2026: revisit Wasmtime, WasmEdge and Wasmer before you run another customer plug-in

Sooner or later, many business products are asked for the same feature: “let our customers write their own rules”. A pricing formula, a validation check, a custom field calculation, a small webhook transformer. The easy way is to run the customer’s script inside your own process with an embedded scripting engine. It works on the demo day. It becomes a problem the first time a customer writes an infinite loop during your busiest hour, or the first time someone reads a file they should not see.

WebAssembly on the server is one of the better answers to this problem today. A WebAssembly module cannot call the operating system directly. It can only call the functions the host gives it, it works inside its own linear memory, and a good runtime lets you cap its CPU time and memory. This post compares three open-source runtimes that teams actually embed or run on servers: Wasmtime, WasmEdge and Wasmer. It looks at where each one stands on 26 October 2026, how they differ in licence, governance, standards and operations, and how to put one of them under a real plug-in feature.

We looked at container sandboxing with gVisor, Kata Containers and Firecracker in the previous post. That post was about running a whole untrusted program inside a stronger container. This one is about a smaller and more common job: running a small piece of untrusted logic inside your own service, many times a second, with tight limits.

A scenario to keep us honest

Take an invented Coimbatore company that sells costing and invoicing software to textile mills and garment exporters in Tamil Nadu and Karnataka. About 40 engineers. Mills price yarn and fabric in very different ways: count, blend, twist, dyeing charges, wastage percentage, freight slabs, customer-specific discounts. So the product lets each mill’s IT person write a “rate rule” that the invoicing service calls for every invoice line.

The first version looked like this:

• Rate rules were written in JavaScript and stored in the database.
• The invoicing service, a Node.js process, ran each rule with the built-in vm module, inside the same process that served other customers.
• There was a timeout on the vm call, but asynchronous code and a few library helpers had been exposed to rules over time.
• Month-end invoicing for all mills ran as a batch on the last two days of the month.

On one month-end night, a mill’s rule had a loop that never ended for one rare yarn count. The worker that picked up that batch stopped responding, the queue backed up, and invoices for other mills were late the next morning. While reviewing the incident, an engineer read the Node.js documentation, which says plainly that the node:vm module is not a security mechanism and must not be used to run untrusted code. That was the bigger finding. Nobody had abused it yet, but nothing real stood between one customer’s rule and another customer’s data in memory.

The team needed three things: a real isolation boundary between rule code and the service, hard limits on CPU time and memory for each call, and a way to let mills write rules in more than one language later. Those are exactly the jobs a WebAssembly runtime is built for.

The short version

• Wasmtime (Apache 2.0 with LLVM exception, Bytecode Alliance) is the reference implementation for the WebAssembly Component Model and WASI 0.2 and 0.3. It ships a new major version on the 20th of every month, with an LTS line every 12 releases supported for 24 months. It is the most natural choice when you embed a runtime in your own service and want standards first.
• WasmEdge (Apache 2.0, CNCF Sandbox project, started at Second State) is a C++ runtime with an interpreter, an LLVM-based AOT compiler and, since 0.18.0, a lazy JIT. It has a large plug-in ecosystem, including WASI-NN backends for AI inference, and strong presence at the edge and in containerd shims. Its Component Model support is still being completed.
• Wasmer (MIT, led by Wasmer Inc.) offers several compiler backends (Singlepass, Cranelift, LLVM), its own WASIX extension that adds POSIX-like features such as threads and sockets, a package registry, and in 2026 a strong focus on “sandboxes” for running ready-made programs such as Python. It suits running whole existing programs more than embedding small typed plug-ins.
• For the Coimbatore rate rules, the plan in this post uses Wasmtime as an embedded library, with a small typed interface for rules, fuel or epoch limits per call, a memory cap per instance, and no file or network access at all.
• WebAssembly is a strong boundary, but runtimes still have bugs. On 19 October 2026 (UTC), Wasmtime published security releases for all supported lines, including two advisories rated critical for Cranelift code generation. Patching the runtime is part of the job.

Where things stand on 26 October 2026

All times below are converted to IST.

Wasmtime

• Latest release: 50.0.0, published on 20 October 2026 at about 9:52 PM IST.
• Security releases 36.0.19, 48.0.7 and 49.0.4 came out in the early hours of 20 October 2026 IST, fixing five advisories the project published on 19 October 2026 (UTC), including “Bit-packing in Cranelift compiler causes silent overflow and miscompilation” and an aarch64 br_table jump issue, both rated critical by the project.
• Release policy, from the project’s own documentation: a new major version on the 20th of each month, release branch cut on the 5th; every release that is a multiple of 12 is LTS and supported for 24 months, others for 2 months; security fixes are backported to all supported releases. Wasmtime 36.0.0 (20 August 2025) and 48.0.0 (20 August 2026) are the LTS lines under that rule.
• Licence: Apache 2.0 with the LLVM exception. Governance: the Bytecode Alliance, a non-profit formed in 2019 by Mozilla, Fastly, Intel and Red Hat. The repository dates back to August 2017.
• Notable in 50.0.0: the wasmtime CLI no longer enables the oldest WASI version (wasi_unstable, also called WASIp0) by default, and wasmtime serve can now take a listening socket from systemd and exit when idle.

WasmEdge

• Latest release: 0.18.1, published on 23 October 2026 at about 2:35 AM IST. It fixed, among others, a validator issue where a crafted array.new_fixed could make validation allocate gigabytes, and a hang in wasmedge parse on malformed name sections.
• 0.18.0, published on 5 October 2026, was a big release: the standard WebAssembly C API (wasm.h), exception handling in AOT and JIT modes, a new lazy JIT mode, a default call stack limit that traps deep recursion instead of crashing, and progress on the Component Model (loading and validation of the MVP and async features, and the synchronous canonical ABI). It also bumped the AOT binary format, so older AOT artefacts must be recompiled, and removed the wasmedge_process plug-in.
• Licence: Apache 2.0. Governance: CNCF Sandbox project. The project started at Second State (it was first called SSVM) and the repository dates from November 2019.
• Its README calls it “the fastest Wasm VM”, citing an IEEE paper. Treat that as the project’s own claim from a specific study, not a general result for your workload.

Wasmer

• Latest release: 7.5.0, published on 1 October 2026 at about 5:02 PM IST. Changes include a hint for transparent huge pages on linear memory, a Cranelift bump, environment file support for WASI programs, and dropping version 1 of its WebC package format.
• Licence: MIT. Governance: a company project led by Wasmer Inc. The repository dates from October 2018.
• Its README in October 2026 describes Wasmer as “lightweight sandboxes for your apps and AI agents” and puts the Wasmer SDK (JavaScript, Python, Rust, Swift) and ready-made registry packages such as Python and Bash in front.

Standards and tooling around them

• WASI 0.3.0 was ratified by the WASI Subgroup and released on 11 June 2026. It rebases WASI on native async in the Component Model: futures and streams replace the pollables and stream resources of WASI 0.2. WASI 0.3.2 followed on 13 October 2026.
• The containerd project’s runwasi shims for Wasmtime, WasmEdge and Wasmer are at 0.6.1 (12 June 2026). These let Kubernetes run WebAssembly workloads through a RuntimeClass.
• Spin, the application framework built on Wasmtime, is at 4.2.5 (23 October 2026).

First question: what exactly are you running?

Before comparing runtimes, be clear about the shape of the code.

• Small, typed plug-ins called many times. A rate rule, a filter, a validation. Input and output are small and well defined. You want fast instantiation, strict limits and no access to anything except what you pass in. This is the embedding case.
• Whole programs written for Linux. A Python script with its standard library, a command-line tool, a student’s C program. They expect files, environment variables, maybe threads and sockets. This is closer to the container sandboxing case, and you should compare WebAssembly against gVisor or a microVM, not only against other runtimes.
• Network services. HTTP handlers deployed as WebAssembly components, for example with Spin or wasmtime serve. Here the runtime is your application server, and the question is the framework and its operations.

The Coimbatore rules are clearly the first case. Most of this post is written for it, with notes where the other cases change the answer.

What each runtime is

Wasmtime

Wasmtime is written in Rust and uses Cranelift, a code generator also developed in the Bytecode Alliance, to compile WebAssembly to native code before running it. It also has Winch, a faster baseline compiler for cases where compile time matters more than peak speed, and the Pulley interpreter for platforms without a native backend. It can compile modules ahead of time with wasmtime compile into .cwasm files and load them later, which removes compile time from the request path.

Its main strength for embedding is the Component Model. You describe the plug-in interface in WIT, a small interface language, and Wasmtime generates typed host bindings in Rust. The guest can be written in any language that can produce a component. Its embedding API also gives you the limits you need: fuel (a count of executed instructions), epoch interruption (a cheap timer-based deadline), store limiters for memory and table growth, and a pooling allocator that keeps pre-reserved memory slots for fast instantiation. Embedding APIs exist for Rust, C and C++, with community and Bytecode Alliance bindings for Python, Go, .NET and others.

WasmEdge

WasmEdge is written in C++. It can run in an interpreter, compile ahead of time with LLVM using wasmedge compile, or use JIT and the new lazy JIT that compiles each function on first call. Its plug-in system is a big part of its identity: WASI-NN backends for running AI models (the LlamaEdge project builds on it), WASI crypto, and others. It has its own JavaScript runtime built on QuickJS. It is used in edge devices and was one of the earliest runtimes integrated with containerd and Kubernetes.

For limits, the CLI has --time-limit in milliseconds, --gas-limit for instruction cost metering and --memory-page-limit in 64 KiB pages, and the C API exposes the same controls. In 0.18.0 the call stack is also limited by default.

Wasmer

Wasmer is written in Rust. It lets you choose a compiler backend: Singlepass for fast, predictable compile times, Cranelift as a balance, and LLVM for the best generated code at a higher compile cost. Its distinctive pieces are WASIX, its own extension of WASI preview 1 that adds threads, sockets, process spawning and other POSIX-like features so more existing software can compile and run, and its package registry, from which wasmer run python/python downloads and runs a WebAssembly build of Python.

Wasmer’s 2026 direction is clear from its README and SDK: create a sandbox, choose packages, run commands. That is useful when you want to run real programs, for example code written by an AI agent, without installing interpreters on the host. Its documentation and release notes centre on WASI preview 1 and WASIX. If your plan depends on the Component Model or WASI 0.2 and 0.3 interfaces, check Wasmer’s current status for those yourself before you commit.

Side by side

Standards

• Wasmtime: Component Model, WASI 0.2 and WASI 0.3 are first-class. Many of the people who write these standards also maintain Wasmtime, and new proposals often land there first, behind flags.
• WasmEdge: strong core WebAssembly support (it removed the CLI flags for tail calls, GC, multi-memory and others in 0.18.0 because the WebAssembly 3.0 standard includes them). Component Model support is in progress: loading and validation are done, and the synchronous canonical ABI is in.
• Wasmer: WASI preview 1 plus WASIX. WASIX is Wasmer’s own specification. It is practical, but it is not a W3C WebAssembly group standard, so code that depends on it is tied more closely to Wasmer.

Execution and compilation

• Wasmtime: Cranelift (optimising), Winch (baseline), Pulley (interpreter). Ahead-of-time compilation to .cwasm files that must match the Wasmtime version and settings that load them.
• WasmEdge: interpreter, LLVM AOT, JIT and lazy JIT. AOT artefacts are versioned; 0.18.0 moved to AOT format version 3, so rebuild artefacts on upgrade.
• Wasmer: Singlepass, Cranelift and LLVM backends, plus the ability to precompile modules.

The common lesson: a precompiled artefact belongs to one runtime version. Treat it as a build output you regenerate on every runtime upgrade, never as a file you copy forward.

Limits on untrusted code

• Wasmtime: fuel, epoch deadlines, memory and table limiters, stack size limits, and the pooling allocator’s per-slot caps. In the CLI these appear as -W fuel=..., -W timeout=... and -W max-memory-size=....
• WasmEdge: time limit, gas limit (cost metering), memory page limit and, from 0.18.0, a call stack limit by default.
• Wasmer: metering middleware for instruction counting and limits on memory through its tunables and configuration. Check the exact API for your version and backend.

Embedding languages

• Wasmtime: Rust first, C and C++ API, and bindings for Python, Go, .NET, Ruby and others with varying maturity.
• WasmEdge: C API (now also the standard wasm.h API), with Rust, Go, Python and Java bindings.
• Wasmer: Rust first, C API, and the Wasmer SDK for JavaScript, Python, Rust and Swift for its sandbox model.

Governance and licence

• Wasmtime: Apache 2.0 with LLVM exception, foundation-governed (Bytecode Alliance), monthly releases with a written LTS and security backport policy.
• WasmEdge: Apache 2.0, CNCF Sandbox. Releases are frequent but not on a fixed calendar.
• Wasmer: MIT, company-led. Releases are frequent; the company also runs a commercial hosting platform and the package registry.

None of the three has a licence problem for normal commercial embedding. The governance difference matters more for long-lived products: a written support window, like Wasmtime’s LTS, makes upgrade planning simpler.

Performance

Do not choose on someone else’s benchmark. Startup time, compile time and steady-state speed all depend on the backend, whether you precompile, how big the module is, how often you instantiate and how much data crosses the host boundary. For small plug-ins, the cost is usually dominated by instantiation and by copying data in and out, not by the arithmetic inside the rule. Measure with your own rules and your own call pattern. Any benchmark a project publishes about itself, including WasmEdge’s “fastest” claim, is that project’s own run.

How a sandboxed call actually works

For the embedding case, the flow in Wasmtime looks like this, and the other runtimes have equivalents:

1. Engine. One per process, created with a configuration: compiler choice, fuel or epoch interruption on, pooling allocator settings.
2. Compile once. Each customer’s rule component is compiled when it is saved (or loaded from a precompiled artefact), not on each call.
3. Linker. You decide exactly which host functions the guest can import. For rate rules, that might be nothing at all except the input record and a logging function.
4. Store per call or per batch. A store holds the instance’s state. You set its fuel or epoch deadline and its memory limiter here. Data from one customer’s call never lives in another customer’s store.
5. Instantiate and call. The host calls the typed export, for example rate(line) -> result<price, error>. If fuel runs out or the deadline passes, the call traps and the host gets an error. The process keeps running.
6. Throw it away. Drop the store. With the pooling allocator, the memory slot is reset and reused.

The important shift from the vm approach is step 3. A WebAssembly guest has no ambient access to files, the network, the clock or environment variables. It only has what you link. In the Node.js design, the rule ran with whatever the process could reach, minus whatever someone remembered to hide.

A worked plan for the Coimbatore team

Step 1: write the plug-in contract first

Describe what a rule receives and returns in WIT, before choosing guest languages. Keep it small and boring:

package mills:rates@1.0.0;

interface rate-rule {
  record line {
    yarn-count: u32,
    blend: string,
    quantity-kg: f64,
    base-rate-paise: u64,
    customer-code: string,
  }

  variant rate-error {
    unsupported(string),
    invalid-input(string),
  }

  rate: func(input: line) -> result<u64, rate-error>;
}

world rate-plugin {
  export rate-rule;
}

Note what is missing: no file system, no HTTP, no clock, no environment. If a rule later needs a lookup table, pass the table in as data or provide one narrow host function for it. Prices are in paise as integers, so rounding is decided once by the host and not by each customer’s floating point code.

Step 2: give mills a supported way to build rules

Most mill IT teams will want JavaScript or Python. Options in October 2026 include the Bytecode Alliance’s ComponentizeJS for JavaScript, componentize-py for Python, cargo component or the standard Rust wasm32-wasip2 target for Rust, and TinyGo or Go for Go. Interpreted languages produce large components, because the interpreter is inside the component. Decide whether you build rules for customers on your side (a small build service with a pinned toolchain) or accept uploaded components. Building on your side is easier to support and lets you scan and version what you build.

Step 3: embed Wasmtime with limits on every call

The core of the host, in prose:

• Enable epoch interruption in the engine configuration, and run one background thread that increments the epoch every 10 milliseconds. Set each store’s epoch deadline so a call that runs more than, say, 50 milliseconds traps. Epochs are cheaper than fuel and good for wall-clock limits.
• If you also want a deterministic limit that does not depend on machine load, enable fuel and give each call a fixed budget. Fuel costs a little more at runtime but gives the same result on every machine, which helps when a mill says “it worked yesterday”.
• Attach a store limiter that caps linear memory per instance, for example 32 MiB, and set a modest maximum stack size.
• Use the pooling allocator, with the number of slots set to your real concurrency, so instantiation is fast and memory use is bounded.
• Link nothing except what the WIT world needs.
• Map a trap to a clear invoice error for that line (“rate rule exceeded time limit”), log the customer, rule version and input, and continue with the batch.

The exact numbers above are starting points to measure, not recommendations. Find the slowest legitimate rule and set the limit with headroom over it.

Step 4: run rules in a separate worker process anyway

WebAssembly isolation is in-process. A runtime bug, like the Cranelift miscompilation fixed on 19 October 2026 (UTC), could in theory turn a guest into a host compromise. So add a layer that costs little: run the rule engine as its own small service or worker process, with no database credentials, no cloud tokens and no outbound network, talking to the invoicing service over a local socket or queue. If something does go wrong in the runtime, the attacker lands in a process that has nothing useful. This is the same idea as the previous post on container sandboxing: shrink what the code can reach first, then add boundaries.

Step 5: plan upgrades like a dependency, not a platform

• Pick a line. For a product the size of the Coimbatore one, the Wasmtime LTS line (48.x as of today) is a reasonable default. Move to the next LTS once a year, and apply every patch release on your line promptly.
• Subscribe to the runtime’s security advisories. On 19 October 2026 (UTC) Wasmtime published fixes for all supported lines at once; you want to hear about such a release the same day.
• Rebuild precompiled artefacts on each upgrade. Keep a test suite of real rules with real inputs and expected prices, and run it against the new runtime before rolling out.
• If you prefer WasmEdge or Wasmer, write down your own support window, because neither publishes an LTS policy like Wasmtime’s.

Step 6: replay last month-end

Before switching, run last month’s full invoice batch through both the old vm engine and the new WebAssembly engine, and compare every line price. Differences are usually floating point rounding, string handling or date logic in the old rules. Fix them with the mill before cutover, not after an invoice reaches a buyer.

When WasmEdge or Wasmer is the better choice

• Choose WasmEdge if your host is written in C or C++ and you want a C API first; if you need its WASI-NN plug-ins for running AI models next to your code; if you deploy on edge devices where its AOT mode and small footprint have been used widely; or if you already run WebAssembly workloads through containerd with its shim. Check that the Component Model features you need are complete in your version.
• Choose Wasmer if your real need is to run existing programs, such as Python scripts or command-line tools, in a sandbox without installing them on the host; if WASIX features like threads, sockets and process spawning are what make your software compile at all; or if its SDK for JavaScript, Python or Swift fits your product. Accept that WASIX ties you more closely to Wasmer, and that governance rests with one company.
• Choose Wasmtime for embedding typed plug-ins, for following the Component Model and WASI standards closely, and when a written LTS and security policy matters to your customers.

When WebAssembly is not the right tool

• The code needs a full Linux environment. If plug-ins are really whole programs that expect a real file system, native libraries, fork and arbitrary system calls, a container sandbox such as gVisor or Kata Containers is a better fit.
• Rules are simple enough for a restricted expression language. Many pricing rules are formulas with conditions. An expression language such as CEL (Common Expression Language), with no loops and bounded cost, may be enough and is easier for mill users to read. WebAssembly is worth it when customers truly need general-purpose code.
• You need heavy native libraries. Machine learning frameworks, image libraries with native code and database drivers often do not build for WebAssembly, or need a lot of work.
• The team cannot own the toolchain. Someone must maintain the guest build pipeline, the WIT contract and runtime upgrades. If nobody will, a hosted function service or a separate container per customer may be cheaper overall.

A short history, so the choices make sense

WebAssembly started in browsers. Its first version became a W3C Recommendation in December 2019, the same year WASI was announced as a system interface for running WebAssembly outside the browser and the Bytecode Alliance was formed. Wasmtime grew from Mozilla’s work on Cranelift and WASI. WasmEdge grew from Second State’s work on running WebAssembly on servers and blockchain nodes. Wasmer was founded as a company around a runtime and later a package registry.

The early server-side years were based on WASI preview 1, which looked like a small subset of POSIX. The standards path then moved to the Component Model and WASI 0.2, which describe interfaces in WIT instead of POSIX calls, and in June 2026 to WASI 0.3 with native async. Wasmer took a different path with WASIX, extending preview 1 to look more like POSIX. That split explains much of the difference between the runtimes today: one road is typed components and interfaces, the other is “make existing programs run”.

Operational costs to plan for

• Toolchains for guests. Each guest language has its own way to produce a component, and those tools move fast. Pin versions.
• Module size and memory. Components that carry a JavaScript or Python interpreter can be several megabytes. Precompile them and watch resident memory with many tenants.
• Debugging. Traps arrive as WebAssembly backtraces. Keep debug names in builds you test with, and log the rule version with every trap.
• Observability. Count calls, traps by reason (fuel, timeout, memory, guest error) and time per call, per customer. A sudden rise in timeouts for one mill is usually a rule change, not a runtime problem.
• Patching. Runtime security releases come several times a year. Treat them like you treat a TLS library.

A decision guide

• Embedding small typed plug-ins in your own service, standards first: Wasmtime, on an LTS line.
• C or C++ host, AI inference plug-ins, or edge devices: WasmEdge.
• Running existing Linux programs or interpreters in a sandbox from your app: Wasmer, or a container sandbox if the programs need full Linux.
• Simple formulas with conditions: a restricted expression language may be enough.
• Code that needs arbitrary system calls and native libraries: a container sandbox, not WebAssembly.

Checklist before you ship a plug-in feature

• A written plug-in contract (WIT or equivalent) with only the inputs and outputs a rule needs.
• No file system, network, clock or environment access linked unless a rule truly needs it, and then only through a narrow host function.
• A CPU limit (fuel or epoch deadline) and a memory limit on every call.
• The rule engine in its own process with no credentials and no outbound network.
• Precompiled artefacts rebuilt on every runtime upgrade.
• A replay suite of real rules and real inputs with expected outputs.
• Someone subscribed to the runtime’s security advisories and releases.
• Clear error messages for customers when their rule traps, with the rule version and input logged.

Common mistakes

• Trusting an in-process script sandbox that was never meant to be one. Node.js says its vm module is not a security mechanism. Many embedded scripting engines are similar.
• Setting a timeout but no memory limit. A rule can allocate until the host runs out of memory long before it runs out of time.
• Linking WASI by default “for convenience”. Giving a rule full WASI means giving it whatever directories, environment variables and sockets you preopened. Start with nothing.
• Copying precompiled artefacts across runtime upgrades. They are tied to the runtime version and settings.
• Treating the runtime as a perfect boundary. It is a strong one, and it still gets security fixes. Keep a second layer.
• Choosing on a vendor benchmark. Your cost is mostly instantiation and data copying for small rules. Measure that.
• Depending on a non-standard extension without noticing. WASIX is useful, but it is Wasmer’s own interface.

A small hands-on drill

We ran a small local drill on 26 October 2026, around 6:30 PM IST, with the official Wasmtime 50.0.0 Linux x86_64 binary on a Linux 6.12 test machine. No network was used by the guest code. Only Wasmtime was tested; WasmEdge and Wasmer were not run.

Two tiny text-format modules were used. The first is a function that loops forever:

(module
  (func (export "_start")
    (loop $l (br $l))))

The second grows its memory by 1 MiB at a time until growth fails, then hits unreachable:

(module
  (memory 1)
  (func (export "_start")
    (loop $l
      (br_if $l (i32.ne (memory.grow (i32.const 16)) (i32.const -1))))
    unreachable))

What we saw:

• wasmtime run -W fuel=100000000 loop.wat stopped with “wasm trap: all fuel consumed by WebAssembly” in about 0.06 seconds.
• wasmtime run -W timeout=2s loop.wat stopped with “wasm trap: interrupt” after about 2.0 seconds.
• wasmtime run -W max-memory-size=10485760 grow.wat made memory.grow return failure at the 10 MiB cap, and the guest then reached unreachable. With -W trap-on-grow-failure=y added, the host itself stopped the guest with “forcing trap when growing memory to 10551296 bytes”.

This is not a benchmark. It only shows the shape of the limits: an infinite loop and runaway memory end as errors the host can handle, not as a hung or out-of-memory process. In an embedded host, you set the same limits through the API on each store.

Unlearn, re-learn

Unlearn the idea that running customer code inside your process with a scripting engine and a timeout is a sandbox. It is a convenience, and the Coimbatore month-end night showed both of its weak points: a loop that blocks the worker, and no real wall between tenants. Unlearn, too, the idea that WebAssembly makes code safe by itself. It gives you a guest that can only do what you link, and limits you must actually set. Re-learn plug-ins as a contract: a small typed interface, nothing linked by default, hard limits on every call, a separate process with nothing worth stealing, and a runtime you patch like any other security-critical library. With that in place, Wasmtime, WasmEdge and Wasmer are all workable; the choice comes down to standards, your host language and whether you are running small rules or whole programs.

Sources

• Wasmtime repository, releases, 50.0.0 release notes and release process and LTS policy
• Wasmtime security documentation and security advisories
• WasmEdge repository, 0.18.0 release notes, 0.18.1 release notes and CLI documentation
• Wasmer repository, 7.5.0 release, changelog and WASIX
• WASI repository, WASI 0.3.0 release notes and WASI 0.3.2
• Component Model documentation
• containerd runwasi and Spin
• CNCF landscape for project maturity levels
• Node.js documentation: VM module