Skip to main content
← Back

wash: The Wasm Shell — a Plugin-Driven Wasm Component CLI

The July 16, 2025 wasmCloud community call is a ground-up rewrite of wash — "the Wasm Shell" — into a lean, plugin-driven CLI focused purely on Wasm component model development: build, run a dev loop, and push to an OCI registry, with everything wasmCloud-specific moving out into WebAssembly-component plugins. Brooks Townsend demos building and running components with no wasmcloud.toml, implementing a draft WASI interface with a component plugin, and hooking the dev loop with an Aspire dashboard plugin. The call closes with Eric Gregory's Q3 2025 roadmap recap, an issue of the week, and a new community Excalidraw room for diagrams.

Key Takeaways​

  • wash is being rebuilt from the ground up as "the Wasm Shell," a lean CLI whose core mission is WebAssembly component development — build, dev, and push to OCI — with everything wasmCloud-specific moved into plugins
  • Only eight built-in commands remain (config, doctor, update, plugin, new, build, dev, oci); other than using the wasmcloud-runtime crate, there is nothing wasmCloud-specific in the core
  • No more wasmcloud.toml required — wash build introspects the project (e.g. a Cargo.toml at the root), so you can build upstream Bytecode Alliance example components directly
  • The dev loop is fully ephemeral — wash dev runs the wasmCloud runtime (a thin wrapper over Wasmtime) rather than launching a full host, so there is no NATS, no wadm, and no providers downloading; think wasmtime serve
  • Plugins are WebAssembly components that export the wasmcloud:wash plugin interface; they can register as top-level commands or as before/after hooks, and a dev-register hook lets a component implement a missing interface such as wasi:blobstore
  • Live plugin demos: a blobstore-filesystem plugin (implementing the draft wasi:blobstore over wasi:filesystem) and an Aspire/OpenTelemetry plugin that stands up an observability dashboard for the dev session — and plugins can be written in any language that compiles to a component
  • Versioning is still open: the team is weighing whether to ship the rewrite as wash v1, or move today's CLI to v1 and release the rewrite as v2, to avoid breaking existing scripts and package-manager updates
  • Community updates: Eric's Q3 2025 roadmap recap (reducing complexity, moving away from capability providers in the dev session), an issue of the week on a wadm model.list deprecation warning, and a new shared Excalidraw room for wasmCloud diagrams

Chapters​

Meeting Notes​

Demo: Introducing wash, The Wasm Shell​

Brooks Townsend introduced a project he had been working on for several weeks: a leaner, plugin-driven rewrite of wash (now standing for "the Wasm Shell"), built to give the best possible WebAssembly component development experience whether or not you use wasmCloud. The work follows from an earlier RFC by Taylor Thomas to "plugin-ify" wash. As Brooks put it, wash was the first piece of wasmCloud he ever worked on five years ago, and this felt like the right moment to rethink it from the ground up with the right level of abstraction.

Where today's wash is a bundle of command-line tools for wasmCloud development, the new core focuses on three things: building components (detecting the project language and compiling to a component), running a dev loop, and pushing finished components to an OCI registry according to standard specs. Everything that is not core to that mission becomes a plugin.

There are only eight built-in commands:

  • config — layered configuration (global defaults, optional per-project config, then command-line overrides)
  • doctor — a sanity check that detects the project type and verifies the right toolchain is installed
  • update — self-update of the CLI from GitHub
  • plugin — plugin management
  • new — create a project from a template
  • build — compile to a WebAssembly component
  • dev — run a fast developer loop
  • oci — push the finished component to a registry

Other than using the wasmcloud-runtime crate (a light wrapper over Wasmtime) and naming the plugin interface wasmcloud:wash, Brooks noted there is nothing wasmCloud-specific left in the shell — which is why there is no need to constrain it to wasmCloud development.

Demo: Build, Dev, and Plugin Components​

Brooks walked through the core loop live. wash build now works by introspecting the project (for example, finding a Cargo.toml at the root) rather than requiring a wasmcloud.toml, so you can clone and build a Bytecode Alliance example component directly. wash dev then compiles the component and serves it over an in-memory Rust hyper HTTP server, calling the component's HTTP export directly — no provider, no NATS, no wadm, nothing downloading in the background. He compared the experience to wasmtime serve.

Trying to dev the blobby example failed, because core wash does not know about the draft wasi:blobstore interface — a deliberate choice to avoid taking on maintenance for every draft interface. The fix is a plugin component: Brooks installed a blobstore-filesystem plugin that implements wasi:blobstore on top of wasi:filesystem and exports the wasmcloud:wash plugin interface with a dev-register hook. With it installed, blobby ran end to end, storing and retrieving file blobs.

He then showed two more plugin styles: an Aspire/OpenTelemetry plugin that uses before/after hooks to stand up an observability dashboard for the dev session (and tear it down on exit), and an aspirational wadm plugin registered as both a top-level command and an after-dev hook. Because plugins are just WebAssembly components, Brooks emphasized they can be written in any language that compiles to a component.

Discussion: Q&A, Config, and Versioning​

  • Multiple plugins for the same interface? Not supported yet — you pick one to install. Taylor suggested a future prompt to choose between implementations; Brooks agreed wash should at least warn at install time.
  • What is lost by dropping wasmcloud.toml? Brooks wants to carry forward valuable pieces (extended overrides, dev configuration, wadm/wasmcloud.lock interpretation) into the new layered config, and is not strongly opinionated about JSON vs TOML vs YAML.
  • Reducing friction: ossfellow (Massoud) noted that requiring a wasmcloud.toml has been a point of friction for newcomers; the new wash generates a sensible config for you on first build and lets you override it.
  • From the stream: a viewer observed that wash has effectively been "ejected" from Docker/NATS to run as a generic Wasm component dev compiler and server on localhost — like cutting-edge JavaScript frameworks. Brooks credited inspiration from clig.dev, npm, and tools like kubectl, and stressed that wash is a developer tool, not a production/observability tool.
  • Versioning: Brooks released the rewrite as a cheeky v0.50 and plans to bring it into the main wasmCloud repo once the community is happy; whether it ships as wash v1 or as v2 depends on confirming it won't break existing scripts and package-manager updates.

Brooks closed by thanking everyone who has contributed to wash over the years, stressing this rewrite builds on that work rather than discarding it.

Community Updates: Roadmap, Issue, and Docs of the Week​

  • Q3 2025 Roadmap Recap: Eric Gregory's recap of the prior week's community roadmapping session — reducing complexity and moving away from capability providers in the dev session — directly informs the new wash direction.
  • Issue of the week: wash uses model.list, which gives a wadm deprecation warning — a good first issue (switch to model.get); community member arujjwal picked it up on the call.
  • Documentation of the week: a new shared community Excalidraw room for creating and sharing wasmCloud diagrams, contributed under the project's contributing guide.

WebAssembly News and Updates​

This call captures a clear trend in the broader WebAssembly ecosystem: tooling is converging on the component model as the unit of development, and runtimes are getting thin enough to make a local dev loop feel like wasmtime serve. The new wash leans entirely into WebAssembly components — both for the artifacts you build and for the plugins that extend the tool itself — so a draft interface like wasi:blobstore can be satisfied by a swappable component rather than baked into the host. It also reflects a shift the wasmCloud maintainers have signaled for a while: separate the developer experience from the production runtime, and make the orchestration layer pluggable. For more on the underlying runtime, see Wasmtime: a standardized runtime for wasmCloud, and follow the Bytecode Alliance for component-model and WASI updates.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and more) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, and tools like wash handle the developer workflow — creating, building, and running components locally before they are pushed to an OCI registry and scheduled in production. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Almost every design choice in the new wash traces back to the Wasm component model. Because a component declares its imports and exports as typed interfaces, wash build can introspect a project and wash dev can inspect exactly what a component needs to run — and bail cleanly when it sees an import it doesn't know about. That same model is what makes plugins possible: a plugin is just another WebAssembly component that exports a known interface (wasmcloud:wash), so it can register a top-level command, hook a built-in, or even implement a missing capability like wasi:blobstore over wasi:filesystem. The result is a tool that is itself composed of components, demonstrating the "write a component once, run it anywhere" promise inside the development workflow. As the component model matures, this is the bet wasmCloud is making: keep the core small and let typed, swappable components — for capabilities, for host plugins, and now for CLI functionality — do the rest.

Who Should Watch This​

This call is especially valuable for WebAssembly component developers who want a faster, simpler local loop without standing up a full host (start with the build/dev demos at 15:50), tool and platform builders interested in extending a CLI through Wasm-component plugins and hooks (the plugin deep dive at 25:30), and wasmCloud users and maintainers tracking how the developer experience is being separated from the production runtime (the Q&A and versioning discussion at 35:09).

Up Next​

The next community calls follow the new wash from experiment to adoption: bringing the rewrite into the main wasmCloud repository, settling the v1-vs-v2 versioning question, carrying forward the valuable wasmcloud.toml configuration, and curating a set of recommended core plugins (likely in the wasmCloud contrib repo). Expect more on the Q3 2025 roadmap themes — reducing complexity and a pluggable orchestration layer — and additions to the new community Excalidraw room for diagrams.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →