If it gives you some confidence, wazero (the Go Wasm runtime) is used by the Go team (in CI) to test their own Go-to-Wasm compiler. So if they break wazero, th

If it gives you some confidence, wazero (the Go Wasm runtime) is used by the Go team (in CI) to test their own Go-to-Wasm compiler. So if they break wazero, they'll know pretty soon from failing tests of their own Wasm/WASI toolchain. https://go.dev/blog/wasi https://go.dev/blog/wasi https://github.com/golang/go/blob/go1.22.3/misc/wasm/go_wasip1_wasm_exec https://github.com/golang/go/blob/go1.22.3/misc/wasm/go_wasi... As for sandboxing, wazero tends to take sandboxing rather more seriously than other similar runtimes. Memory sandboxing is implemented through explicit bounds checks (rather than memory mapping and guard pages), which allows denser deployments and requires less runtime support. And, by default, the WASI implementation doesn't expose any capabilities (not even access to the system clock). You can also interject any relevant WASI host calls, and do your own filtering. And if the compiler is not your cup of tea, you can also use the (much slower) interpreter.