We're thrilled to announce the 1.0 release of wasmCloud, the universal application platform hosted by the Cloud Native Computing Foundation (CNCF) that helps you build and run globally distributed WebAssembly applications on any cloud and any edge.

You can try it right now—download the wasmCloud Shell (wash) and dive in to our quickstart.

The 1.0 release is a grand culmination of effort from the 2024 Q1 roadmap which focused primarily on standardization of host control interface and RPC protocols, events, and WebAssembly component support.

When we set down our goals for wasmCloud 1.0, we identified five top features for the project—key promises that we want wasmCloud to fulfill:

1. Declarative WebAssembly Orchestration
2. Seamless Distributed Networking
3. Vendorless Application Components
4. Completely OTEL Observable
5. Defense-In-Depth Security By Default

Now that we've reached 1.0, let's check in on each of those features.

Declarative WebAssembly orchestration​

Orchestrating WebAssembly components across distributed environments poses two big challenges:

1. Orchestrators like Kubernetes aren't particularly well-suited to distributed, heterogenous environments.
2. Container orchestrators expect everything to act like a container—but components are something fundmentally new.

To leverage the composability and flexibility of components and distribute them across, say, multi-region clusters and edge nodes, wasmCloud needed an orchestrator built from the ground up for the WebAssembly ecosystem and for distributed computing.

That's what we've done with the wasmCloud Application Deployment Manager (Wadm). Wadm delivers the declarative application management experience that cloud engineers expect and automatic, out-of-the-box load balancing, service discovery, and failover for distributed applications. All of this uses the community standard Open Application Model (OAM): if you know how to use a YAML manifest with Kubernetes, you're 99% of the way to using one with Wadm.

Better yet, wasmCloud and Kubernetes integrate seamlessly through the open source wasmCloud-operator, which uses a Kubernetes controller and custom resource definitions (CRDs) to run wasmCloud hosts on Kubernetes. The operator enables you to deploy wasmCloud applications from within your cluster using the Kubernetes tooling you're already using. This way, Kubernetes focuses on what it's good at—infrastructure management—while wasmCloud handles the orchestration of distributed components, throwing the WebAssembly toolbox wide open for developers.

• Check out our wasmCloud with Kubernetes page to learn more about the wasmCloud-operator project and how to get started running wasmCloud with Kubernetes.

• Learn more about Wadm in the Toolchain section of the wasmCloud docs.

Seamless distributed networking​

wasmCloud hosts can be clustered together with the CNCF project NATS to form a distributed mesh network called a lattice, allowing you to seamlessly distribute applications on any architecture, operating system, virtual or physical machine and communicate like it was running on a single computer.

Whether a component is a serverless function or a microservice, it communicates over common WebAssembly Interface Type (WIT) definitions. Components speak a common language, so combining (or "composing") them is easy. With the 1.0 release, wasmCloud implements a new RPC protocol called wRPC to take this flexibility a step further, delivering the composability of the Component Model—dynamically and at runtime—across the lattice. This will be especially powerful for use-cases like apps comprised of many different services, or apps requiring explicit control over data location.

• Read our primer on the four ways components are linked in wasmCloud, including an in-depth breakdown of runtime linking between distributed components over the network.

Vendorless application components​

The WebAssembly ecosystem is bringing us to a world where we can write code once and run it anywhere. The WebAssembly System Interface (WASI) and the Component Model extend the power of Wasm with standard APIs and a spec for compiling WebAssembly code as portable, interoperable, composable components.

The 1.0 release of wasmCloud commits to and standardizes around the Component Model to make your application code truly vendor-neutral. Components built for wasmCloud 1.0 run anywhere that supports WASI 0.2, and any component you've built to target WASI 0.2 is ready to run across distributed environments with wasmCloud.

Since wasmCloud supports custom interfaces written with the community-standard interface description language (IDL) of WIT, your interfaces are vendorless, too: wasmCloud gives developers and platform engineers a stable, vendor-neutral environment to use the WebAssembly ecosystem to the fullest.

• For more on WASI 0.2 and our approach to vendor-neutrality, check out our blog, Vendor-neutral apps with wasmCloud 1.0 and WASI 0.2.

• You might also want to see our blog on why WASI 0.2 is such a big deal.

• If you're new to components, WASI, and the wider WebAssembly ecosystem, check out our Concepts documention to get up to speed—the Components page is a great place to start.

Completely OTEL observable​

If you want to use a distributed system like wasmCloud in production, robust observability is essential. The 1.0 release brings the trifecta of traces, logs, and metrics to wasmCloud hosts using the industry-standard OpenTelemetry (OTEL) specification.

Our approach to observability aims to be simple, flexible, and compatible with your existing cloud native tooling. With OTEL as a common standard, observing hosts is a simple matter of connecting to Grafana, Honeycomb, or another backend.

• Find out more about observability and wasmCloud in our blog, Complete OpenTelemetry Observability with wasmCloud.

• See the Observability with OpenTelemetry page in the wasmCloud docs for more information on metrics, logs, and traces, along with an example observability ecosystem that you can launch with just a few commands.

Defense-in-depth security by default​

WebAssembly provides excellent sandboxing by default, and wasmCloud has a strong track record with a successful October 2023 audit from OSTIF and Trail of Bits.

Using components helps us build on this foundation for best-in-class zero-trust security. Components can only use interfaces defined in their WIT, and in wasmCloud, they must be explicitly linked with another component or provider to communicate. Even then, communication is mediated by the wasmCloud RPC protocol.

Finally, wasmCloud 1.0 is committed to extensibility with a policy service API enabling complex policy evaluation using standard cloud native tools like Open Policy Agent.

• Learn more about how wasmCloud 1.0 extends security and conforms to cloud native policy standards in our blog, Extending Security with wasmCloud 1.0 and Open Policy Agent.

• For more details on using Open Policy Agent with wasmCloud, including request and response schemas and an example policy service, check out the Policy service documentation.

Migration and compatibility​

For users, 1.0 represents a stable foundation to build on with confidence—and as usual with a major release that means some breaking changes from what came before.

Smithy-generated actors and providers were deprecated in v0.82, and support is officially removed in v1.0.0. If you need help migrating from Smithy interfaces, just reach out on the wasmCloud Slack or on GitHub. We've also dropped the term "actor" itself in favor of "component"—we're building WebAssembly components here, after all, and we want it to be absolutely clear that these are standard WebAssembly components you could pick up and run with any other system that runs components.

The v1.0.0 release of wasmCloud is not compatible over the lattice with previous versions of wasmCloud, wash, or Wadm, owing to the shift to components, WIT interfaces, and a new RPC protocol. For these reasons, it's recommended to update all wasmCloud hosts that you run to v1.0.0 at the same time. Associated tooling like Wadm should update to at least version v0.11.0 as well in order to match the protocol versions.

Finally, the model for Wadm manifests has changed slightly—see the guide to Migrating from v0.82 for complete instructions.

Next steps​

We couldn't be more excited to see what you build with wasmCloud 1.0. If you want to show off your project, ask questions, or just chat about WebAssembly and wasmCloud, join us on the wasmCloud Slack!