go-wasmcontainersLICENSE=BSD-3-ClauseCGO_ENABLED=0 go-wasmcontainersLICENSE=BSD-3-ClauseCGO_ENABLED=0A container here is a WebAssembly module. The wctrd daemon listens on /var/run/wctr.sock and is compatible with the Docker Engine API; wctr is the command a lab teaches and the learner types; the image is an OCI image with os=wasip1 and arch=wasm, run by wazero instead of a Linux kernel. Engine v0.1.0 is released: native, no networking yet. Pure Go, CGO_ENABLED=0. BSD-3-Clause.
# engine v0.1.0, the engine's acceptance test $ wctr pull oci:./layout:hello Pulling from oci:/home/me/layout:hello f0beefb89ff1: Pull complete Digest: sha256:da3eead2a4f462a53bebdee2f9dc5fcb94cc5a97ebe1680477f0ce0328ff67f0 Status: Downloaded newer image for hello:latest $ wctr run --rm hello Hello from a WebAssembly container! $ wctr run --rm -e NAME=x greet Hello, x! $ wctr run --name failing probe exit 42 bye $ echo $? 42 $ wctr images REPOSITORY TAG IMAGE ID CREATED SIZE greet latest 068beee4f451 12 hours ago 2.45MB hello latest 85c424cd2beb 12 hours ago 735kB probe latest ae7fb9d7cefb 12 hours ago 811kB # planned, not started $ wctr exec -it <container> sh $ wctr build . $ wctr compose up
Teaching containers usually means provisioning a Linux machine per learner. WASI modules need no kernel, so the same engine that runs natively can, in the plan, run in a browser worker.
wctrd answers that API (v1.47 is the version its reference is read from) on /var/run/wctr.sock, and WCTR_HOST points wctr elsewhere. Learners type wctr commands, whose shape is the one they know from containers at work.
An image is an OCI image whose platform is os=wasip1, arch=wasm; the layer is a module. Images are meant to be apt-like, built from pkgx wasip1 bottles — a target go-pkgx is gaining now.
Containers run in wazero, a pure-Go WebAssembly runtime: no cgo, no kernel namespaces, one static binary.
The playground is a terminal running wctr against WASI containers, entirely in a page. It has not been started; it depends on the executor running in a browser worker.
engine v0.1.0 releasedThe wctrd daemon and the wctr command: a container engine for WASI (wasip1) workloads, compatible with the Docker Engine API, in pure Go. v0.1.0 (milestone M1) runs natively on Linux and macOS with a wazero executor: wctr pull, images, run, ps, logs, rm, rmi, inspect, kill and version, against an OCI image layout or a registry. No networking, exec, attach or build yet. Install with go install github.com/go-wasmcontainers/engine/cmd/wctr@v0.1.0 (and cmd/wctrd).
playground plannedAn in-browser container playground: a terminal that runs wctr against WASI containers, for cloud and container training labs. Not started: it needs the engine’s executor to run in a browser worker.
Nothing below exists yet. It is listed so a reader can tell what engine v0.1.0 does not do: no networking, exec, attach or build; no tar+zstd layers; containers are lost when wctrd restarts.
Containers that listen and connect, through the WasmEdge socket ABI.
Planned: a classroom relay with security groups. Students’ browsers reach each other’s containers through a relay on the teacher’s laptop that is also a firewall, with rules modelled on OpenStack Neutron and a gRPC control API. Design.
wctr exec and an interactive shell, through a WASIX subset.
Building an image from a Dockerfile.
Several containers described in one file.
Enough of the orchestrator’s API to teach its concepts.
The same executor model in a browser worker, which is what the playground needs.
go install github.com/go-wasmcontainers/engine/cmd/wctr@v0.1.0No cgo, no daemon written in C, no kernel to provision. Every behaviour that follows a specification — OCI image and distribution, registry token authentication, the Docker Engine API it is compatible with, the wasm OCI artifact layout, WASI preview1 — is written against the document it follows, and the engine's references page says which version was opened.
Read the source on GitHub →