Web Assembly

WASI P3 is almost here, bringing native async support to the WebAssembly System Interface (WASI) and Component Model. In this post, we’re looking to the next big milestone: a stable, formally specified Component Model 1.0. At February’s Bytecode Alliance Plumbers Summit, Luke Wagner and Alex Crichton gave a preview of what the path to a stable 1.0 actually looks like. At Wasm I/O 2026 in Barcelona in March, Luke expanded on that vision. So let’s take a look at where the Component Model is heading.

The garden has a new nameplate! Kubewarden 1.36 renames the repository and its container images, changes how PolicyServer deletion works, adds host network support, and ships the docs on a new platform. Breaking changes Repository and container image rename We renamed the kubewarden-controller repository to adm-controller. The old name stopped making sense once the project grew beyond a single admission controller. The container images moved too: kubewarden-controller is now just controller All images live under ghcr.

Announcement: Endive begins

In September 2023, a small group of contributors set out to answer a simple question: can WebAssembly run on the JVM with zero native dependencies? The project they built, Chicory, proved it could. Within two years it was powering JRuby’s Prism parser, a pure-Java SQLite driver, an embedded PostgreSQL, a pure-Java QuickJs runtime, TrinoDB Python UDFs, and many more. What started as an experiment became infrastructure.

Today we’re announcing Endive, the next chapter for that project and community. Endive is a fork of Chicory and a Bytecode Alliance Hosted project, a vendor-neutral home where the project can grow openly.

Java developers should be able to embed Wasm modules without treating them as foreign native artifacts. They should be able to package, load, test, observe, and deploy Wasm using familiar Java workflows. That was the promise of Chicory, and it remains the promise of Endive. The community, the vision, and the code carry forward. What changes is that the project now belongs to its ecosystem.

Why the Bytecode Alliance?

Chicory was founded and incubated as a cross-company, open-source collaboration that proved WebAssembly can fit naturally into Java applications. As the project grew, the community saw an opportunity to place it under vendor-neutral stewardship.

The Bytecode Alliance is that home. Its mission is to build secure, portable, modular foundations for WebAssembly, WASI, runtimes, compilers, and language tooling. The JVM is not a niche embedding target. It is a major managed runtime ecosystem with decades of production experience. If WebAssembly is to become a durable cross-language component format, the JVM should be part of that story. Endive gives the Bytecode Alliance community a place to collaborate on that work directly.

Redline and Cranelift: performance without giving up the JVM story

The next major step is bringing the experimental Redline compiler into the mainline.

Redline uses Cranelift to compile WebAssembly to native machine code, building on the same compiler foundation used by Wasmtime. This gives Endive a path to performance that is consistently comparable with Rust/Wasmtime-class runtimes, while preserving the Java packaging and embedding experience that made Chicory valuable.

With Endive, JVM-hosted Wasm no longer means choosing between integration and performance. You get Java-native embedding and native-speed execution in the same runtime. And on Java 25+, Redline achieves this with zero additional dependencies, thanks to the Foreign Function & Memory API (Panama) becoming a standard part of the platform.

The Component Model and the JVM

Looking further ahead, Endive aims to bring full Component Model support to the JVM.

The Component Model defines typed, language-neutral interfaces between components, hosts, and libraries. Implementing it on the JVM means Java developers will be able to consume components written in Rust, Go, C, JavaScript, or other languages through explicit contracts rather than bespoke plugin APIs or native bindings.

A Java service should be able to load a component, expose only the capabilities that component needs, call it through generated typed bindings, observe it with JVM tooling, and deploy it using familiar Java packaging workflows.

As the Component Model gains traction across the ecosystem, the JVM will be one of the first managed runtimes to pursue deep integration. We hope that the lessons learned on the JVM will be useful as Component Model support reaches other managed runtimes.

What happens next

The Endive repository is already available. The first release will prioritize strong continuity with the latest Chicory release, preserving compatibility where possible, documenting migration steps clearly, and avoiding unnecessary disruption for existing users. Before that release, we will complete the security, governance, and supply-chain diligence expected of Bytecode Alliance Hosted projects. The path forward should be obvious for current Chicory users: the project has a new name and a new home, and the technical mission becomes even more ambitious.

Looking ahead, the project’s focus areas are:

• merging the Cranelift-based Redline compiler into the mainline;
• tightening spec conformance, including WasmGC support and proposal alignment across runtimes;
• deepening WASI and Component Model support for JVM applications.

Join the next chapter

Endive starts from the foundation Chicory established, but its future is about the broader community. The project stays Apache-2.0 licensed.

The goal is to make WebAssembly on the JVM neutral, durable, secure, high-performance, and ready for the Component Model.

If you care about Java, WebAssembly, secure plugin systems, cross-language components, or the future of portable software, come build with us.

And how the splicer framework makes it tractable at any interface edge.

We are happy to announce SBOMscanner v0.11.0. This release introduces an MCP server for AI assistants, a new way to target a subset of a registry from a ScanJob, supply chain hardening with zizmor, and several fixes for race conditions in the storage controller watches. MCP server SBOMscanner now ships an MCP server that puts everything the controller knows in front of your AI assistant of choice. Instead of crafting kubectl queries across CRDs and joining the results in your head, you can ask Claude, Claude Code, GitHub Copilot, or any other MCP client questions like “which workloads in cluster prod are running an image with a critical CVE?

This Admission Controller 1.35 release is one that builds the nest properly: load-bearing branches first, then careful weaving. A moderate security vulnerability has been fixed, and rather than a quick twig stuffed in a gap, the team reinforced the whole structure. This release brings also a new policy, an expansion on our threat model, and a JavaScrypt/TypeScrypt SDK relocation. Security fix: RBAC reconnaissance and host capability calls Kubewarden makes the following security promise:

After the big blooms of 1.33, this release turns its attention to the garden fence: making sure our CI pipelines are sturdy, our supply chain is trustworthy, and a nagging bug in kwctl gets pulled out by the roots. Nothing flashy, but the kind of care that keeps the garden healthy for the long haul. Let’s take a look at what’s new! Fix for kwctl scaffold command When using kwctl command scaffold manifest with a policy URI that omits an explicit tag (e.

A new world for security-critical projects

Jco (@bytecodealliance/jco on NPM)is a “multi-tool for the JS WebAssembly ecosystem.” At the 2026 Bytecode Alliance Plumbers Summit, Technical Steering Committee member Bailey Hayes put it another way: Jco is “like five projects in one.” It’s certainly a project with many facets—five big ones, arguably! Recognizing what those facets are, and how they fit together, is the key to understanding why Jco matters beyond the JavaScript ecosystem. In this blog series, we’ll draw on Victor Adossi’s Plumbers Summit presentation to take an in-depth look at Jco from five different perspectives, in order to better grasp how you can use (and contribute to!) Jco today. There’s a lot to unpack here, so in this first post, we’ll try to get to grips with Jco as a layered architecture that brings together many pieces of the Wasm and JS ecosystem.

The Kubewarden ecosystem continues to expand its supply chain security capabilities! Hot on the heels of the Admission Controller 1.33 release, we are excited to announce SBOMscanner v0.10.0. This release introduces powerful new features and critical stability fixes. Let’s dive in! Workload Scan Until now, SBOMscanner required explicit Registry configurations to scan images. However, what usually matters most are the images actively running in your cluster. The new Workload Scan feature automatically discovers and scans container images based on live workloads.

The garden is thriving and Kubewarden 1.33 is ready to bloom! Following last release’s big repotting, this one is serious about pruning, including a security issue. It’s not all housekeeping though, fresh flowers are blooming and come with nice features: BYO-PKI landing in the policy-server, field mask filtering for context-aware calls, proxy support, and a few more treats. Let’s dig in! Security fix: Cross-namespace data access, removal of deprecated API calls In our previous post we explained how our architecture protects namespaced policy users from privilege escalations.