extism/extism

Extism is a portable WebAssembly runtime and SDK framework that enables the execution of isolated plugins with strict security and resource controls. It provides a unified Rust core, a C shared library, and a Python binding to manage plugin lifecycles, memory, and host function interactions. The system supports rich data serialization, WASI file I/O, and network restrictions, allowing developers to safely integrate external code into their applications.

19 changes.

The project upgraded its runtime to Wasmtime 48 and restructured the codebase into a Cargo workspace, introducing a new plugin API and manifest schema. Concurrently, legacy SDKs for C++, Go, Node.js, OCaml, Python, and Ruby were removed to streamline the repository and focus on core Rust and C interfaces.

10 changes.

The project rewrote the Extism kernel in Rust and WebAssembly to improve portability and establish a robust memory management foundation. This period also focused on expanding language support by introducing the extism-convert crate for data serialization, a new C SDK, and Python wheel building capabilities, while adding comprehensive testing and benchmarking suites.

A new extism-maturin crate has been introduced to facilitate the creation of Python wheels for the Extism SDK. This crate includes a build script that preprocesses the C header file (extism.h) to handle platform-specific compatibility issues on macOS and Windows, and exposes the SDK's public API via Rust bindings for Python integration.

extism-maturin · high confidence

The new \extism-convert\ crate provides a shared interface for encoding and decoding values passed to and from Extism plugin calls, used by the Rust SDK and PDK. It introduces \ToBytes\ and \FromBytes\ traits with derive macros, supporting JSON, MessagePack, Protobuf (via \prost\ and \rust-protobuf\), Base64, and raw memory copying (via \bytemuck\). Built-in implementations cover primitive types, \Option\, and standard collections, enabling users to easily serialize/deserialize data for function inputs and outputs.

convert · high confidence

The Extism kernel runtime is now implemented in WebAssembly, providing an isolated memory space for plugins with a bump allocator, input/output handling, and error management. This change introduces the core \MemoryRoot\ and \MemoryBlock\ structures, along with functions for memory initialization, resetting, and bounds checking, establishing the foundation for plugin execution within the kernel.

kernel/src · high confidence

The \convert-macros\ crate now provides \\#\[derive(ToBytes)\]\ and \\#\[derive(FromBytes)\]\ macros, allowing users to automatically implement byte serialization and deserialization for structs by specifying an encoding via the \\#\[encoding(...)\]\ attribute. The implementation includes robust compile-time validation, providing clear error messages and suggestions when the encoding attribute is missing, malformed, or duplicated.

convert-macros · high confidence

Added four new example programs in the runtime examples directory to demonstrate key Extism capabilities. The \fs.rs\ example shows how to configure read-only allowed paths and handle file read/write operations via WASI. The \linking.rs\ example demonstrates runtime module linking, where an export from one WASM module (\upper.wasm\) is linked to an import in another (\reflect.wasm\). The \log\_callback.rs\ example illustrates how to register a custom log callback to capture tracing output from plugins. The \readme.rs\ example provides a complete implementation of the README usage pattern, showing how to define and register host functions (\kv\_read\, \kv\_write\) that interact with user data (a key-value store) inside the plugin.

runtime/examples · high confidence

The libextism location now provides a complete C SDK package. A new CMakeLists.txt enables building and installing both static and shared libraries, along with pkg-config files (extism.pc, extism-static.pc) for easy integration. The API documentation (API.md) and README.md have been added, detailing the C FFI interface (e.g., extism\_plugin\_new, extism\_plugin\_call, extism\_plugin\_reset, logging functions). An example program (example.c) demonstrates usage, including custom host functions and logging. This establishes the foundational build and documentation structure for the C SDK.

libextism · high confidence

The C++ SDK files, including the C++ wrapper header (extism.hpp), the C header (extism.h), the example application (example.cpp), and the build instructions (Makefile), have been removed from the repository. This eliminates the C++ language binding and its associated demonstration code from the project.

cpp · high confidence

The Node.js JavaScript SDK implementation (node/index.js) and its accompanying example script (node/example.js) have been removed. This deletes the previous JavaScript-based interface that relied on ffi-napi to interact with the native libextism library, effectively removing the ability to use Extism from Node.js via this specific JavaScript wrapper.

node · high confidence

The \extism\ executable and its associated \dune\ build configuration have been removed from the \ocaml/bin\ directory. This deletes the command-line tool that previously allowed users to invoke Extism functions (such as \count\_vowels\) directly via the \extism\ binary, effectively removing this specific CLI interface from the SDK distribution.

ocaml/bin · high confidence

The \extism\ OCaml library source files (\extism.ml\, \extism.mli\) and its build configuration (\dune\) have been removed from the \ocaml/lib\ directory. This deletes the OCaml bindings that previously allowed users to register plugins, call functions, and handle manifests via the \extism\ module.

ocaml/lib · high confidence

The Python example script (example.py) has been removed from the repository. This file previously demonstrated how to instantiate an Extism Plugin, load a WebAssembly module, and invoke the count\_vowels function, providing a reference implementation for Python users.

python · high confidence

The Ruby SDK directory has been cleaned up by removing several development and scaffolding files, including the Rakefile, bin/console, bin/setup, example.rb, and the RBS type signature file (sig/extism.rbs). This change removes the local development helpers and example usage code from the repository, likely as part of a broader cleanup or restructuring of the SDK's distribution contents.

ruby · high confidence

The \ruby/lib/extism/version.rb\ file has been deleted, removing the \Extism::VERSION\ constant that previously exposed the SDK version (0.1.0). This change eliminates the programmatic access to the library's version number from the Ruby codebase.

ruby/lib/extism · high confidence

The \wasm/rust-pdk\ module has removed its previous implementation of the Extism PDK, specifically deleting \src/bindings.rs\ (which defined FFI declarations for Extism host functions and memory helpers) and \src/lib.rs\ (which provided the \Host\ struct and associated abstractions for input, output, configuration, and key-value storage). This change eliminates the old PDK code from this location, likely as part of a migration to a different PDK version or structure.

wasm/rust-pdk · high confidence

The \ocaml\ directory has removed its legacy build configuration and dependency management files, including \.ocamlformat\, \dune-project\, \extism.opam\, and \extism.opam.locked\. This cleanup eliminates the project's previous Opam package definition and pinned dependency list (which included libraries like \ctypes-foreign\, \bigstringaf\, and \yojson\), indicating a shift away from the standalone Opam-based build system for this location.

ocaml · high confidence

The legacy Python SDK module located at \python/extism\ has been removed. This deletion eliminates the previous CFFI-based implementation that handled plugin registration, library location, and WASM execution directly via \extism.py\. Users relying on this specific package path will no longer have access to the \Plugin\ and \Error\ classes defined in this module.

python/extism, ruby/lib · high confidence

The legacy WebAssembly platform development kits (PDKs) and their associated build infrastructure have been removed. This change deletes the C PDK header (\wasm/c-pdk/extism-pdk.h\), the C example (\wasm/count\_vowels.c\), the Rust PDK example (\wasm/rust-pdk/examples/count\_vowels.rs\), and the Makefiles used to compile them. Users relying on these specific C and Rust WASM examples or the old PDK headers for direct integration will need to migrate to the current runtime implementation.

wasm · high confidence

The Go example application (main.go) that demonstrated loading a plugin manifest, executing the count\_vowels function, and parsing the JSON output has been removed from the repository.

go · high confidence

The Extism C API (\extism.h\) has been significantly expanded and restructured to support richer plugin interactions. The previous simple \ExtismPlugin\ integer handle is replaced by a full struct (\ExtismPlugin\) and new opaque types like \ExtismCompiledPlugin\, \ExtismFunction\, and \ExtismCurrentPlugin\. The API now exposes detailed value handling via \ExtismVal\ and \ExtismValUnion\ enums, allowing host functions to accept and return multiple typed arguments (I32, I64, F32, F64, etc.) rather than just raw pointers. New capabilities include pre-compiling plugins (\extism\_compiled\_plugin\_new\), setting host function namespaces, retrieving plugin IDs, and accessing the current plugin's memory directly from host functions. The header also adds C++ compatibility macros (\EXTISM\_FUNCTION\, \EXTISM\_GO\_FUNCTION\) and an \EXTISM\_PTR\ alias for I64, while the build process now explicitly generates these bindings with C++ support enabled.

runtime · high confidence

The Extism runtime core has been rewritten in Rust and compiled to WebAssembly to improve portability across different WebAssembly runtimes. This change introduces a new build process for the kernel, allowing users to generate the \extism-runtime.wasm\ binary and merge it with context modules, while also providing a dedicated test script using \wasm-bindgen-test-runner\ for validation.

kernel · high confidence

The manifest crate has been refactored to introduce a formal JSON Schema (\schema.json\) and significantly expand configuration capabilities. Users can now restrict network access via \allowed\_hosts\, map local directories into the WASI environment using \allowed\_paths\, and configure memory limits more granularly (max pages, max HTTP response size, and max var bytes). The \Wasm\ module definition now supports raw binary data without base64 encoding, and the \HttpRequest\ builder provides a fluent API for setting headers and methods. These changes are accompanied by stricter serialization rules (\deny\_unknown\_fields\) and deprecation of older \ManifestMemory\ and \ManifestWasm\ types in favor of the new \MemoryOptions\ and \Wasm\ structures.

manifest · high confidence

A new \libextism\ crate has been added to facilitate the generation of the \libextism\ shared library by re-exporting the SDK from the \extism\ crate. This change consolidates the build process, allowing the runtime and SDK to be unified under a single entry point for library generation, while including a basic test to verify the version string is correctly populated.

libextism/src · high confidence

Added DEVELOPING.md to document the release process, including branching strategies, tagging, and CI workflows for publishing artifacts. Updated the Makefile to support static library builds (installing libextism.a), pkg-config files, and cross-compilation via RUST\_TARGET. Added a new example-schema.yaml for XTP Bindgen and updated .gitignore to exclude generated files from various SDKs. Removed the legacy extism.go and libextism.pc files, and refreshed README.md with current SDK support graphics and links.

(repo-wide) · high confidence

The NuGet packaging configuration for the Extism runtime has been restored, enabling the distribution of the library as a NuGet package. This change re-introduces the necessary build assets, including \Directory.Build.props\ for standardizing build properties (targeting .NET Standard 2.1) and versioning via MinVer, alongside the \Extism.runtime.all.nuspec\ manifest which aggregates platform-specific native dependencies (Linux, macOS, Windows) into a single internal implementation package. A \.gitignore\ and \README.md\ are also included to support the packaging workflow.

nuget · high confidence

The runtime has been upgraded to Wasmtime 48 (LTS) and restructured to use a new \CurrentPlugin\ context instead of the previous global plugin registry. This change introduces a \PluginBuilder\ for configuring plugins (including WASI, fuel limits, and caching), a thread-safe \Pool\ for managing plugin instances, and a new \UserData\ system for host functions. The old \export.rs\ and \memory.rs\ modules have been removed in favor of the new \pdk.rs\ and \current\_plugin.rs\ implementations, and logging now uses the \tracing\ crate with a configurable callback.

runtime/src · high confidence

The Rust SDK has removed the \Makefile\, \build.rs\, and \src/bindings.rs\ files that previously handled building and binding to the C library (\libextism.so\/\.dylib\). This change eliminates the manual C-FFI layer and build-time dependency on the external C shared library for the Rust crate, simplifying the build process and removing the generated bindings code.

rust · high confidence

Add benchmarking suite for plugin creation and data throughput; Added runtime test suite for kernel, plugin pooling, and issue regression.

The Extism runtime has been upgraded to Wasmtime version 48, bringing support for new features such as the GC proposal, coredumps, and parallel compilation. The project structure has been reorganized into a Cargo workspace, centralizing version management and dependencies across the \extism\, \extism-convert\, \extism-manifest\, and \libextism\ crates. This update also introduces \tracing\ for logging, adds \extism-convert\ for type serialization, and updates build tools like \cbindgen\ to version 0.29. Additionally, the old Node.js, Python, Ruby, and Go SDK directories have been removed, with the Python SDK now built via \extism-maturin\ for CFFI bindings.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 57 → 54 (-3.3)
• Rubric changed (rubric-2026.09.10 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 85 → 60 (-24.2)
• Architecture 93 → 67 (-26.8)
• Maturity 70 → 71 (+0.9)
• Readiness 73 → 76 (+3.3)
• Security 35 → 41 (+6.2)

• Documentation: no contributor guidance (README.md)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)

• Ambiguous naming convention for length retrieval. One method is explicitly marked 'unsafe' while the other is not, but both take a pointer/handle and return length. It is unclear if 'unsafe' refers to memory safety (bounds checking) or API stability, and the parameter types (Handle vs Pointer) are inconsistent.
• Dependency hygiene PARTLY measured — Cargo dependencies read, no committed lock to grade for currency
• End-of-life runtime: Rust 1.95
• Inconsistent parameter naming. input_load_* methods take offset: u64, while load_u8/p and store_u8/p methods take p: Pointer or p: Handle. The distinction between 'offset' (relative to input) and 'pointer' (absolute or relative to memory) is not reflected in the parameter name consistency.
• Inconsistent parameter/return types for error handling. error_set takes a Handle (likely an error handle), while error_get returns a Handle. While symmetric, the naming error_set vs error_get is less descriptive than set_error/get_error used in CurrentPlugin.
• Inconsistent return types for offset retrieval. input_offset returns a Handle while output_offset returns a Pointer. This forces the caller to handle different types for symmetric operations.
• Off the main sequence: extism-manifest
• Orphaned knowledge (kernel/src/lib.rs)
• Redundant naming pattern for mutable vs immutable access. While common, the suffix _mut is inconsistent with the rest of the API which often uses distinct method names or traits for mutation. More critically, memory_bytes_mut and memory_bytes follow this, but memory_get_val and memory_set_val do not.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

extism/extism was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.