Extism: a WebAssembly plugin framework with SDKs in fifteen languages

The problem Extism solves: running someone else's code inside your process

Most applications that want extensions face the same choice. Either you define a scripting surface and accept that scripts can reach whatever the host process can reach, or you build a process boundary and pay for serialization, startup time and a separate deployment artifact. Extism takes a third position. The unit of extension is a WebAssembly module, loaded into your process by an SDK, and the README describes the project's primary use case plainly: "You want to be able to execute arbitrary, untrusted code from your users? Extism makes this safe and practical to do."

The audience is therefore host application developers, not plugin authors alone. The README lists plug-in systems, FaaS platforms, code generators and web applications as the things people build with it. A plugin author writes code in a language with a PDK (Plug-in Development Kit) compiled in, producing a .wasm binary. The host application imports an Extism SDK, loads that binary, and calls exported functions. The two sides do not share a language, a runtime or a build system.

What separates this from embedding a raw Wasm engine is the set of host-side utilities the README enumerates: persistent memory and module-scope variables, host-controlled HTTP without WASI, runtime limiters and timers, and simplified host function linking. Those are the parts a team would otherwise write itself on top of a bare runtime, and they are the reason to pick a framework rather than an engine.

How the runtime, the manifest and the PDK fit together

The repository is a Cargo workspace with members listed in Cargo.toml: extism-maturin, manifest, runtime, libextism, convert and convert-macros, with kernel excluded from the workspace. That layout maps onto the architecture. The runtime crate is the Rust SDK and the core implementation. libextism is the C library, and the Makefile builds it with cargo build --release --manifest-path libextism/Cargo.toml before installing runtime/extism.h alongside the shared and static libraries. The manifest crate handles the description of a plugin, and convert handles the data conversion between host and guest types.

The flow at runtime is short. The host constructs a plugin from a manifest, which points at a .wasm source. The host calls a named export with an input buffer and receives a buffer back. Inside the module, the PDK reads that input and writes a return value. Extism's own layer sits between the two, which is why the README can promise module-scope variables and HTTP that the host controls rather than the guest.

The manifest is the part worth reading before you commit. It is a separate crate with its own release cadence, and it is how the host expresses where the Wasm comes from and how it should be configured. Because the manifest is data rather than code, a host can treat plugin configuration as content it stores, versions and swaps without recompiling. That is the design decision that makes the FaaS and code-generator use cases in the README plausible.

Installing the Rust SDK and calling your first exported function

The README does not contain a step-by-step install walkthrough. It points at the documentation site for getting started and lists the package for each SDK: the Rust SDK is published on Crates.io, the C and C++ SDKs have no package and live in this repository under libextism and the cpp-sdk repository respectively. For Rust, the entry point is a dependency on the extism crate.

Add the SDK to a Rust project with cargo add, which resolves the current published version from Crates.io:

cargo add extism

For the C library, the Makefile is the documented build path. It builds the release library and then installs the header, the shared object and the pkg-config files into DEST, which defaults to /usr/local:

make build
sudo make install

On macOS the Makefile sets SOEXT to dylib and links the Security framework; on Linux it uses so. After installation, libextism.pc and extism-static.pc are placed in $(DEST)/lib/pkgconfig, so a C project can find the library through pkg-config rather than hardcoding paths.

For every other language, the README's table is the starting point: @extism/extism on NPM for JavaScript across Web, Node, Deno and Bun, extism on PyPI, github.com/extism/go-sdk as a Go module, Extism.Sdk on NuGet, org.extism.sdk:extism on Sonatype, extism on Hex, Hackage, opam, CPAN, Packagist and RubyGems. The Zig SDK is listed with no package, so it is consumed from source. What you should see after installing any of them is the same shape: create a plugin from a manifest, call an export by name, read the returned bytes.

What Extism does not do for you

The README is explicit that hosts must execute Wasm compiled with a PDK. A module built with a plain Wasm toolchain and no Extism PDK will not have the imports the runtime expects, so it will not load as an Extism plugin. This is a real constraint, not a formality: it means plugin authors cannot bring an arbitrary existing .wasm artifact and expect it to work. The extension surface is Extism's, and adopting the framework means asking your plugin authors to adopt the PDK too.

Platform coverage is narrower than the language list suggests. The README provides releases for eight targets: aarch64-apple-darwin, aarch64-unknown-linux-gnu, aarch64-unknown-linux-musl, x86_64-apple-darwin, x86_64-pc-windows-gnu, x86_64-pc-windows-msvc, x86_64-unknown-linux-gnu and x86_64-unknown-linux-musl. There is no 32-bit target and no Android target. For Android the README redirects to the Chicory SDK, a pure Java Extism runtime maintained in a separate repository. If you are shipping a mobile application, the C library in this repository is not the path the project recommends.

Versioning is the other thing to plan around. The workspace Cargo.toml sets the workspace version to 0.0.0+replaced-by-ci, meaning published versions are stamped by CI rather than by hand in the manifest. The release list shows a Development Build dated 2026-09-02 and tagged releases v1.30.0 from 2026-06-04 and v1.21.0 from 2026-03-26. Anyone pinning dependencies should pin to a tagged release rather than tracking main, because the repository's own version field does not tell you what you are building.

Extism compared with embedding a Wasm engine directly

The obvious alternative is to embed a general-purpose WebAssembly runtime yourself, such as Wasmtime or Wasmer, and define your own host functions. That approach gives you complete control over the import surface and no dependency on Extism's conventions. The difference in practice is the amount of glue you own. With a bare engine you write the input and output marshalling, decide how the guest reaches the network, implement any per-call time or memory limits, and maintain host function bindings for every language you support. Extism's runtime and convert crates exist to absorb that work, and the README lists persistent module-scope variables, host-controlled HTTP without WASI, runtime limiters and timers, and simpler host function linking as the utilities layered on top of a standard runtime.

The trade is that you inherit Extism's plugin interface. A module that runs under a bare Wasmtime host will not run under Extism without a PDK, and the reverse is also true. If your extension authors are already writing against a WASI-based interface, or if your host is written in a language with no Extism SDK, the framework adds a layer without removing much work. The SDK table covers Rust, JS, Elixir, Go, Haskell, Java, .NET, OCaml, Perl, PHP, Python, Ruby, Zig, C and C++, which is broad, but it is a fixed list. A host in a language outside it would have to bind to libextism through the C API, and the README does not describe that path.

Licence and the cost of keeping up

Extism is licensed BSD-3-Clause, stated in the README badge and in the workspace package metadata in Cargo.toml. That is a permissive licence with a standard attribution requirement and no copyleft obligation on your own code. It says nothing about the licences of the Wasm modules your users load, and it says nothing about the licence terms of the underlying runtime that Extism builds on. Those are separate questions, and the repository does not answer them.

Upgrade cost is concentrated in two places. The first is the SDK you import: the release list shows v1.21.0 in March 2026, v1.30.0 in June 2026, and a Development Build on 2026-09-02, so tagged releases arrive on a scale of months. The second is the manifest format, which lives in its own crate and is what your host uses to describe plugins. A change there reaches every stored plugin configuration, not just your code. The Makefile's FEATURES and DEFAULT_FEATURES variables also mean the C library can be built with a reduced feature set, so a host that disables default features has a build configuration to re-verify on each upgrade rather than a drop-in library swap.

Editorial conclusion

Adopt Extism if you maintain a host application in one of the supported languages and need to execute third-party or user-authored code without granting it filesystem or network access by default. Skip it if your extension points are trusted internal code, or if you need a pure-Java runtime on Android, where the README points at the separate Chicory SDK instead. Before committing, verify that a PDK exists for the language your plugin authors actually write in, and check which of the eight listed release targets matches your deployment platform, because Windows GNU, musl and Darwin builds are not interchangeable.

Frequently asked questions

Official sources

1. extism/extism on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases