WASI, the WebAssembly System Interface, gives WebAssembly programs a controlled way to communicate with external capabilities. In Fluent Bit, the exec-wasi plugin uses WASI to invoke WebAssembly solutions without depending on a shell or OS features that may be unavailable in distroless containers. section 3.8.2 section 9.6
WASI supports a tightly controlled boundary between an extension and its host. That boundary resembles browser sandboxing: WebAssembly can run as a packaged binary, while WASI governs how it reaches beyond the WebAssembly environment. This model supports small, secure, quickly starting server-side functionality, especially in cloud-native deployments. section 9.6
Using WASI in an extension introduces practical trade-offs:
- Choose exec-wasi when a WebAssembly-based solution avoids shell dependencies or missing operating-system features. section 3.8.2
- Expect a steeper development path: developers must define, build, and debug WebAssembly assemblies. section 9.6
- Account for runtime overhead, harder debugging, weaker direct connection to the Fluent Bit codebase, and difficult network access for HTTP or TCP. section 9.6.2
Replacing shell execution in a constrained container
A Fluent Bit deployment running in a distroless container can use exec-wasi to invoke a WebAssembly data-capture solution when exec cannot rely on the required operating-system features or Bash. section 3.8.2
