The current state of WASI in containers space WebAssembly is gaining a lot of traction in the container space. I wondered if I could use it in my daily work, and I found out that it was not that easy. Here is a summary of my findings. WASI lets you run WebAssembly outside of the browser. Technically, it’s a standard that defines a system interface for WebAssembly. It is also designed to be sandboxed, so it is a good fit for containers. The advantage of using WASI is that you can run the same binary on any platform that that standard. Some of these platforms are described below. It is also a good fit for serverless, as you can run the same binary on any serverless platform that supports WASI. It’s the case for AWS, Azure, Fastly, Cloudflare, GCP should have support for it too, but I didn’t find any documentation about it. For containers, a WASI program doesn’t need to include an operating system, so it makes the image smaller and more secure. Small containers are also faster to start than containers with an operating system. WASI is sandboxed, so it adds a security layer to your application. Docker has technical preview of WASI support since July 2022. It is available in the experimental version of Docker Desktop only. You can enable it in the settings: Then you can run a WASI binary: It works well, but you need to use experimental features. It is not a big deal for local development, but it is not usable in production. Furthermore, Docker Desktop is not available for servers, so you really can’t use it in production. One of the advantages of Docker Desktop is also one of its disadvantages: it runs on a virtual machine. If you have Docker Engine and Docker Desktop, images are not shared between them as Docker Desktop runs on a virtual machine. Wasmtime is a WebAssembly runtime that supports WASI. It is written in Rust and open source. The development and maintenance are now supported by the Bytecode Alliance. Wasmtime was created by Fastly and Mozilla. Wasmtime can...