FAQ
This page answers frequently asked questions about wasmCloud — how it relates to containers and Kubernetes, what makes it a useful runtime for sandboxing AI and Model Context Protocol (MCP) servers, the WebAssembly Component Model, and getting started. For wasmCloud v1 → v2 migration specifics, see the Migration to v2 guide.
WebAssembly vs. containers — positioning
Does WebAssembly replace containers?
No. WebAssembly and containers are complementary technologies that solve different problems. wasmCloud is designed to run Wasm components alongside containerized workloads in the same Kubernetes cluster, letting teams adopt Wasm where its strengths apply — deny-by-default security, scale-to-zero startup, polyglot composition — without disrupting their existing container infrastructure. The right architecture for most teams in 2026 runs Wasm components and containers side by side.
When should I choose WebAssembly over a container?
WebAssembly is the better choice when any of the following are dominant requirements: (1) deny-by-default capability-based security where every external call must be explicitly granted; (2) sub-millisecond cold start enabling true scale-to-zero economics; (3) polyglot composition across languages without trust escalation between components; (4) running untrusted or AI-generated code with bounded blast radius. Containers remain the right choice for long-running stateful services, workloads with deep OS-level dependencies, and existing applications where rewriting cost exceeds the security or efficiency gain.
How does wasmCloud compare to Docker or Kubernetes?
wasmCloud is a CNCF runtime that schedules WebAssembly components, much as Kubernetes schedules containers. They operate at different layers and work together: wasmCloud's runtime operator lets Kubernetes schedule Wasm workloads through the same declarative APIs (pods, deployments, services) operators already use for containers. Docker focuses on container packaging and runtime; wasmCloud focuses on Wasm component packaging, distribution via OCI, and runtime — and reuses Docker / OCI registry infrastructure rather than replacing it.
Security and trust
What does "deny-by-default" mean in WebAssembly?
In a deny-by-default model, a component starts with zero permissions and must be explicitly granted each capability it needs — network access, filesystem access, environment variables, and so on. This contrasts with the ambient-authority model of containers and VMs, where code inherits the permissions of its parent process by default. Deny-by-default bounds the blast radius of any vulnerability to exactly the capabilities the component was granted.
How does wasmCloud secure AI and LLM-generated code?
AI-generated code is structurally riskier than human-reviewed code because the volume outpaces review capacity and the threat model is unfamiliar. wasmCloud runs each AI-generated component in a Wasm sandbox with deny-by-default capability grants — the LLM-authored code cannot reach the network, filesystem, or other components unless the platform team explicitly grants those capabilities. This makes wasmCloud a foundation for sandboxing AI workloads, vibe-coded prototypes, and Model Context Protocol (MCP) servers without trusting the generating model.
Is wasmCloud suitable for running untrusted Model Context Protocol (MCP) servers?
Yes. MCP servers are a high-value target for sandboxing because they bridge AI models to external tools and data — a category where authorization and capability scoping are critical. wasmCloud runs MCP servers as Wasm components with explicit capability grants per protocol method, enabling least-privilege MCP server deployment without rewriting the server itself.
Architecture and developer experience
What is the WebAssembly Component Model and why does wasmCloud use it?
The Component Model is a WebAssembly specification for composing isolated components through typed interfaces (defined in WIT — WebAssembly Interface Types). It enables polyglot composition: a component written in Rust can call a component written in Python through a typed contract, without either side trusting the other's internals or sharing memory. wasmCloud uses the Component Model as its native unit of work because it preserves Wasm's isolation guarantees while enabling the cross-language composition modern applications require.
What languages can I use to build wasmCloud components?
Rust, Go (via TinyGo), Python, TypeScript / JavaScript, C#, and increasingly Java. Each language has WebAssembly toolchains that produce Component Model-compliant artifacts. The wasmCloud documentation includes language-specific quickstarts.
What is WASI Preview 3 and when does wasmCloud support it?
WASI Preview 3 is the next major revision of the WebAssembly System Interface, adding native async support, streams, and futures to the Component Model. wasmCloud is positioned to enable WASI Preview 3 by default as soon as the specification ships, with a flag to disable it during transition. Track the WASI working group at the Bytecode Alliance for the launch timeline.
How does wasmCloud integrate with Kubernetes?
wasmCloud ships a runtime operator that brings Wasm component workloads under Kubernetes scheduling. Components are distributed via OCI registries, scheduled through standard Kubernetes APIs (deployments, services, ingress), and observed through the same Prometheus / OpenTelemetry pipelines operators already use for containers. Teams can mix Wasm components and containerized pods in the same cluster without operating two control planes.
Operations and scaling
What does "scale to zero" mean for WebAssembly workloads?
Wasm components have sub-millisecond cold start times — orders of magnitude faster than container cold starts. This makes true scale-to-zero economics practical: a component can be torn down completely when idle and re-instantiated on the next request without user-visible latency. For event-driven and bursty workloads, scale-to-zero with Wasm cuts compute spend dramatically compared to keeping containers warm.
What is AIOps, and how does WebAssembly fit?
AIOps applies AI to IT operations — incident response, capacity planning, anomaly detection, runbook automation. WebAssembly provides the secure, language-agnostic execution layer that AIOps platforms need to run untrusted AI-generated remediation code, customer-supplied policy logic, and pluggable detection routines without the operational overhead of per-tenant containers. wasmCloud is a runtime for the AIOps execution layer.
How does wasmCloud observability work?
wasmCloud emits OpenTelemetry traces, metrics, and logs natively. Components annotated with OTel instrumentation flow into standard observability pipelines without per-component agent installation. Recent releases add WASI-OTel host plugin support, so observability is a host capability granted to components rather than something each component must implement.
Open source, governance, ecosystem
Is wasmCloud open source?
Yes. wasmCloud is an open-source CNCF Incubating project, licensed under Apache 2.0, with development happening publicly on GitHub. Commercial support and managed offerings are available from Cosmonic and other vendors in the ecosystem.
What is the relationship between wasmCloud, the CNCF, and the Bytecode Alliance?
wasmCloud is a CNCF Incubating project, the runtime equivalent in the Wasm ecosystem of projects like Kubernetes (CNCF) for containers. The Bytecode Alliance stewards the WebAssembly specifications themselves (Wasm core, WASI, the Component Model). wasmCloud implements those specifications and contributes back to them.
How do I get started with wasmCloud?
Start with the wasmCloud Quickstart. It walks through installing the wash CLI, running a host, deploying your first component, and seeing it serve traffic — usually in under ten minutes.
Comparisons frequently searched
wasmCloud vs. Wasmtime: are they the same thing?
No. Wasmtime is a WebAssembly engine — the layer that actually executes Wasm bytecode. wasmCloud is a runtime built on top of Wasmtime, adding scheduling, distribution, capability providers, observability, and Kubernetes integration. wasmCloud embeds Wasmtime; you can use Wasmtime standalone for embedding Wasm in your own application without wasmCloud's distributed runtime features.
wasmCloud vs. Knative or OpenFaaS for serverless workloads?
Knative and OpenFaaS schedule containers as serverless functions. wasmCloud schedules Wasm components with the same model — but cold start is sub-millisecond rather than seconds, capability grants are deny-by-default rather than container-isolation, and the same component artifact runs across cloud, edge, and Kubernetes without rebuilding for each environment. wasmCloud is appropriate when fast cold start, polyglot composition, or capability-based security are dominant requirements.
What workloads are NOT a good fit for wasmCloud?
Workloads with deep OS-level dependencies (kernel modules, OS-specific syscalls beyond the WASI surface), workloads with very large in-memory data sets (Wasm linear memory caps remain restrictive at 4GB per component pending wasm64), and existing applications where rewriting cost significantly exceeds the security or efficiency gain. These are better served by containers; pair them with wasmCloud where appropriate, don't force-fit.
General questions
Do I have to use Kubernetes with wasmCloud v2?
No. The workload API exposed by the runtime can work with any orchestrator, so you can choose or create the solution that suits your environment. You can also use the operator with a stripped-down version of Kubernetes that includes only the K8s API server, for a straightforward but lightweight Kubernetes-native approach.
In real-world implementations, wasmCloud maintainers have found that the vast majority of users are deploying wasmCloud on Kubernetes. For wasmCloud v2, we're aiming to align smoothly to this most common scenario while preserving flexibility for a variety of deployment patterns including distributed edge environments.
For now, maintainer time is focused on the prevailing Kubernetes use case, but we'd love to hear from folks who are interested in other deployment scenarios, and we strongly encourage contributors who would like to work on other scheduling implementations to get involved.
Migrating from wasmCloud v1
For a comprehensive migration guide with architecture comparisons, diagrams, and step-by-step instructions, see the Migration to v2 guide.
What happened to capability providers?
In v1, capability providers were external processes that communicated over NATS. In v2, capabilities are provided through host plugins (recommended for shared, performance-critical capabilities), service components (for workload-specific long-running functionality), or containerized providers (for minimal-change migration of existing providers).
For details and examples, see Migrating capability providers. For guidance on choosing between a plugin and a service, see Plugin or Service?.
Is wadm still a part of wasmCloud v2?
No—the runtime-operator and the Kubernetes API now manage deployments. The operator acts as a reconciler, giving hosts the appropriate instructions to match the state specified to the Kubernetes API. Though wasmCloud v2 is designed to operate in a Kubernetes-native way, it is not restricted to Kubernetes.
For more on the architectural changes, see Architecture comparison.
What happened to the "Application" abstraction?
The v1 "Application" has been replaced by the Workload, which may include one or more components that communicate over interfaces. Components in the same workload are placed on the same host and linked at runtime.
For a side-by-side manifest comparison, see Migrating applications to workloads.
How do distributed applications work in wasmCloud v2?
In v2, distributed networking is intentionally more explicit. Components within the same workload communicate in-process (~30,000 RPS). When distributed communication is needed, you'll use interfaces like wasmcloud:messaging with manual serialization/deserialization (~5,000 RPS).
For more context, see Migrating distributed networking.