Skip to main content
← Back

Blobby UI Demo, wash build/dev Project Inference & v2 Service/Component Workloads

Watch on YouTube ↗

The January 14, 2026 wasmCloud community call is anchored by Lucas Fontes' Blobby UI demo and a deep architectural change to wash build and wash dev. Blobby — the long-running Blobstore example — gets a proper web UI that uploads, downloads, copies links, and shows a recent-activity bar, with both the UI and the API served by the same WebAssembly component. Under the hood, wash build and wash dev move from implicit file-sniffing project inference to explicit build commands in config — solving the monorepo problem, enabling environment-variable interpolation in build commands, separate debug vs release commands, and direct integration with Make or any other build tool. Service-and-component co-development is now first-class through the new wash dev config that lets you bring additional Wasm files into the workload (demoed with a cron service + cron component). Bailey Hayes highlights the importance of explicit configuration as a long-term maintenance win. luk3ark asks how plugins compare to bringing in components for backend interfaces, and Lucas explains the host-plugin model. Eric introduces the new v2 Glossary and the draft Quick Start guide with a local Kubernetes deployment step. The team closes with notes on the next WASI P3 release candidate landing in Wasmtime and a refreshed Go component SDK compatible with the latest tinygo and wasm-tools.

Key Takeaways​

  • Blobby gets a UI — the long-running Blobstore example now serves its own HTML UI from the same WebAssembly component as the API; uploads (single and multiple), downloads, copy-link, and a recent-activity bar all work without curl
  • Both UI and API in one component — Blobby's web interface is a clean demonstration of hosting frontend assets and backend API in the same Wasm component
  • wash build and wash dev move from implicit to explicit — the previous approach sniffed Cargo.toml, go.mod, etc. to infer the build method, which broke for monorepos and turned into a cat-and-mouse game tracking upstream toolchain flag changes
  • Custom build commands per template — templates can ship with their own build command, and developers can override it with anything (cargo, make, custom shell scripts). The component output path is now also configurable
  • Separate dev vs build commands — wash dev can run a fast debug build, wash build can run the slower release/wit-bindgen pipeline; if you only specify one, both share it
  • Environment variable interpolation in build commands — secrets from CI and shell environment forward through to your build; you can chain commands with ; and use $VAR interpolation
  • -c flag changes to project directory before executing — paths in your build config are relative to the project root, not where you ran wash
  • Service + component co-development is first-class — the new wash dev config supports bringing additional WebAssembly files into the workload; cron service + cron component is the canonical example. The workload assembled during wash dev matches what you'd deploy
  • Plan: back in-memory dev-loop plugins with the filesystem — current in-memory Blobstore and wasi-keyvalue clear data on every rebuild, forcing re-seeding. Filesystem-backed plugins will let developers seed by copying files into a directory and persist across rebuilds
  • Host plugins are per-workload, not shared monolithic providers — each workload gets its own plugin instance, which luk3ark asked about explicitly. The platform admin picks the storage backend when they install the host (NATS, S3, etc.); the component just declares which buckets it needs
  • v2 Glossary landed with "Service" and "Workload" entries — the best quick reference for v2 concepts right now (PR #1048)
  • Draft Quick Start guide in PR — three-page guide following the v1 structure: install wash, create a component with persistent storage, deploy to local Kubernetes (PR #1049)
  • Next WASI P3 RC landed in Wasmtime — requires a newer wit-bindgen; will be in next month's Wasmtime release
  • New Go component SDK — compatible with the latest tinygo, latest Go, and latest wasm-tools

Chapters​

Meeting Notes​

Blobby UI Demo​

Lucas Fontes opened with a facelift to one of the long-running wasmCloud examples: Blobby. The API is the same as before, but now Blobby serves its own UI from the same WebAssembly component. Operations that previously required curl commands — file uploads (single or multiple), copy-link, downloads — are now available through a clean web interface, with a recent-activity bar showing what just happened.

Running cargo run -- -c examples/blobby dev from the wash repo brings up the demo. The -c flag changes wash to the project directory before running anything, so all paths in your build config are resolved relative to the project root. The UI is HTML/JavaScript served directly by Blobby; the API is identical to the old curl-driven version. Both endpoints — UI and API — live in the same WebAssembly component.

In wash dev, Blobstore data is in-memory and clears on restart. In a Kubernetes deployment, Blobstore is backed by NATS Object Store with replication configurable through standard NATS settings.

wash build and wash dev: From Implicit to Explicit​

The bulk of the call was Lucas walking through a significant architectural change to how wash build and wash dev work. The previous approach was project inference by file-sniffing: if Cargo.toml is present, it's a Rust project and we run cargo build; if go.mod is present, it's a Go project; etc.

This broke for monorepos — a Cargo.toml anywhere in the parent tree would force a Rust build, even when you wanted to build a different language inside a subdirectory. It also became a cat-and-mouse game: every new cargo flag, every new TypeScript package manager (yarn, pnpm) needed an update in wash, with everyone forced to upgrade in sync.

The new approach: wash is essentially a Makefile. Templates and projects declare their own build commands, and developers can override them with whatever they want.

  • Custom build commands — cargo build, make, custom shell scripts, anything
  • Custom component output path — tell wash where the .wasm file will land after the build
  • Separate wash dev and wash build commands — wash dev runs a fast debug build (no wit-bindgen regeneration); wash build runs the full release pipeline. If you only specify one, both share it
  • Environment variable interpolation — $VAR works inside the command, secrets and CI flags forward from your shell environment to the build
  • Command chaining — ; and && work as you'd expect

For Blobby (Rust), the config is cargo build with a component path pointing at target/wasm32-wasip2/release/blobby.wasm. For a Go example, the config uses Make so the same artifact builds identically from wash or bash.

Service + Component Co-Development​

The new wash config has a section for wash dev that lets you specify additional WebAssembly files to bring into the workload during development. This makes service-and-component co-development first-class.

Lucas demoed with the cron example — cron service + cron component:

  • When wash dev runs against the component, the config loads the cron service alongside; the component is rebuilt on changes, the service stays attached
  • When wash dev runs against the service, the config loads the component into the workload; the service is rebuilt on changes, the component is reattached

The workload assembled in wash dev matches what you'd deploy to production. There's no separate "dev rig" — what you build is what you ship.

Bailey on Explicit Configuration​

Bailey Hayes flagged this as one of the more important architectural shifts of the v2 work: moving from implicit to explicit configuration. The implicit file-sniffing logic was a continuous source of bugs and maintenance burden. Making the config explicit means fewer surprise breakages when upstream toolchains change, fewer assumptions about project layout, and a clear audit trail for what wash is doing during a build.

It also makes the "workload as a unit" story crisp: when you wash dev, you're assembling a workload — same structure as what gets deployed. The dev loop is no longer a special case.

Filesystem-Backed Plugins for Dev Loop​

Current dev-loop plugins (Blobstore, wasi-keyvalue, config) are in-memory — when you rebuild your component, the data clears. That's a problem in practice: imagine running rails db:migrate every time you save a file.

The plan: back in-memory plugins with the filesystem. A directory in your home cache becomes the storage backing Blobstore. For wasi-keyvalue, file names map one-to-one with keys, file contents are the values. Seeding a new app becomes "copy files into the directory."

This is a dev-loop-only convenience. Production hosts still use whatever the platform admin configured — NATS, S3, etc.

luk3ark Q&A: Plugins vs Components for Backend Interfaces​

luk3ark asked how this fits with the broader plugin/component architecture: when Blobby is backed by NATS in Kubernetes, is that via a host plugin or a component?

Lucas's explanation:

  • Host plugin model: the host comes with a set of capabilities (Blobstore, wasi-keyvalue, etc.) that the platform administrator configures when they install the host. The component just declares "I need access to these buckets" — it doesn't carry credentials or care about the backend implementation.
  • In production, state lives outside the host (NATS, S3, etc.) — never on the same hardware as the compute. So the storage backend is a deployment-time decision, not a component-author decision.
  • In local dev, wash is self-sufficient — it brings up the HTTP server, runtime, file watcher all in one process. In-memory state was the v1 answer, but most v1 users brought their own NATS/Postgres anyway. So the in-memory state was never really exercised. The filesystem-backed dev plugins close that gap properly.

luk3ark followed up: if you have a more complex scenario — Blobby + a vector database for chunking and embedding — do you bring multiple plugins, or do you compose components?

Lucas: multiple plugins. Each workload gets its own instance of each plugin (not a shared monolithic provider). The trade-off vs v1 wRPC providers: host plugins are native Rust code, so adding a new plugin means rebuilding the host. The upside is less complexity at runtime and per-workload isolation.

For someone who really wants the v1 wRPC dynamic-loading model, a wRPC gateway as a service is still possible — it operates as a workload service, opens a TCP socket, receives wRPC from outside, calls a component inside. It's just not the default anymore.

v2 Glossary and Quick Start Docs​

Eric introduced two doc updates:

  • v2 Glossary (PR #1048) — landed. New entries for "Service" and "Workload" plus updates for v2 architecture changes. The best quick reference for top-level v2 concepts right now.
  • Quick Start guide (PR #1049) — in PR, three pages following the v1 structure: install wash + language tooling; create a component, customize it, add persistent storage; deploy a Wasm workload to local Kubernetes. Waiting on wash RC6 to land before final polish; will incorporate the Blobby demo as a final showcase.

Eric called for documentation contributors to run through the draft and provide feedback before launch.

WASI P3 and Go SDK Updates​

Bailey closed with two ecosystem notes:

  • Next WASI P3 release candidate is now in Wasmtime — requires the newer wit-bindgen; will be in next month's Wasmtime release
  • New Go component SDK — compatible with the latest tinygo, latest Go, and latest wasm-tools. The Go side was two tinygo versions behind; this catches it up

WebAssembly News and Updates​

The shift from implicit project inference to explicit build commands in wash mirrors a broader trend in build tooling toward declarative configuration with full developer control. WASI P3 continues to converge — the new RC landing in Wasmtime brings async/native streams within reach for downstream tooling. The Go ecosystem story is getting cleaner with the refreshed Go component SDK, aligning to current tinygo, Go, and wasm-tools releases. And the component model is increasingly the lingua franca for "I want to host this thing in a sandbox with explicit capability declarations" — Blobby serving both UI and API in one component is a small example of what that unlocks.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly components across cloud, edge, and Kubernetes. The v2 architecture demoed in this call introduces services (long-running stateful WebAssembly components) alongside the existing stateless component model, with both composable into a single workload via wash dev for local development and the same shape deployed via the runtime operator in production. The new project inference model gives developers full control over build tooling, while host plugins (for Blobstore, wasi-keyvalue, etc.) keep components stateless and portable — credentials and backends are platform-admin concerns, not component-author concerns.

Topic Deep Dive: Implicit vs Explicit Configuration as a v2 Theme​

Looking across the v2 changes Lucas and Bailey have been driving, one consistent theme stands out: explicit configuration over implicit inference. In v1 (and early v2), wash sniffed your project directory for indicator files and inferred what build tool to use, what flags to pass, what to do with the output. That was convenient for the 80% case but broke catastrophically for the 20% that didn't match the assumption.

The new pattern: templates ship the right build command, developers override it freely, and wash stays a thin orchestrator that runs the command and looks at where you told it the artifact would be. This is the same lesson the broader build tooling ecosystem has learned the hard way: implicit magic is great until it isn't, and the cost of debugging implicit behavior dwarfs the cost of typing one line of config.

The same pattern is showing up in plugin configuration (the platform admin picks the storage backend at host install time, the component just declares what it needs), service definition (the workload composition is explicit in wash dev config, matching production), and OpenTelemetry plumbing (the host configures via standard OTel SDK environment variables, no special wasmCloud flags). For platform engineers evaluating wasmCloud v2 against earlier impressions of v1, this is the most important architectural shift to track.

Who Should Watch This​

wasmCloud developers tracking v2 should start with Lucas's Blobby UI demo at 07:06 and the project inference walkthrough at 12:00. Anyone managing monorepos or with non-standard build pipelines wants the custom build command discussion at 13:30. Component authors thinking about services + components together should watch the cron example at 17:00. Platform engineers asking how plugins compose want luk3ark's Q&A from 23:58. Doc contributors should check out the v2 Glossary and Quick Start PRs at 29:58.

Up Next​

wash RC6 is coming, with the project inference changes and the filesystem-backed dev-loop plugins. The Quick Start guide will fold in Blobby and the local Kubernetes deployment step once RC6 lands. The next WASI P3 RC will roll out across Wasmtime and downstream tooling. Community contributors are encouraged to test the draft Quick Start guide and provide feedback or PRs.

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 →