smolvm is a microVM .kern is plain OS-level isolation

The meaning of un‑cached can vary. The two un‑cached answers are very different. I will give both.

When the image has already been pulled the container takes 3.7 milliseconds. Adding a command does not add any time. I ran /bin/sh -c 'echo hi' inside an alpine image. Over 100 runs the time was 3.73 milliseconds. Running /bin/ in the container gave 3.71 milliseconds. Python is a number because it is CPython that is starting not the isolation. Running python3 -c 'print(1)' inside a python:3.12-slim container takes 15.6 milliseconds. Twelve milliseconds of that time is spent starting the interpreter. The same delay exists on metal.

If the image is not, in the cache then pulling the image dominates the time. Pulling is limited by the network not by runtime. On my connection pulling alpine took 2.7 seconds. Pulling python:3.12-slim took 9.0 seconds for 41 megabytes of layers. This happens once; after the image is cached the times above apply again. The command 'kern pull' pulls the image in advance if you want to pick when this happens.

I measured these times on the desktop described in the README. The system has an i7‑14700KF processor running Linux 7.0.

Image already pulled: 3.7 ms for the box, and a shell command adds nothing on top (3.73 vs 3.71 over 100 runs, alpine).

Python is 15.6 ms in a python:3.12-slim box, but ~12 of that is CPython starting, which you pay on bare metal too.

Cold cache is a different order: the pull dominates and is network bound. Alpine 2.7 s, python:3.12-slim 9.0 s for 41 MB, once.

Fair, and it's not CRI. The README's limits section says "Not a Kubernetes runtime. No CRI. Use containerd or CRI-O." I meant runtime in the docker/podman sense, pull and build and lifecycle in one binary, and you're right that the word is overloaded enough that the title doesn't carry that by itself.

Since you're building it, two things you'll hit before you hit the docs. cargo install needs the package name, because it searches the whole repo and finds three packages with binaries (the CLI, the fuzz harness, the Windows shim):

cargo install --git https://github.com/getkern/kern getkern --locked

And a source build is 1.91 MB, not the 1.5 in the title. The release binary is smaller because CI builds it with a pinned nightly, build-std and optimize_for_size, on an opt-level="z" profile; the source stays plain stable Rust on purpose, so building doesn't need nightly.

Interested in what breaks.

thanks.. let me know how it goes or if you hit any issues