but but why not just use kata?

but but why not just use kata?

Cause that sounds too much like work. Like I don’t want to have to go in an swap out a k8s cluster, or docker engine to just use kata.

So, wth is zippy? It’s a container runtime for Firecracker microVMs, written in Elixir. A bit Fly, a bit Heroku, but zypi.

Why

I wanted to run untrusted code safely. Docker isn’t enough, containers share a kernel. Firecracker gives you real isolation: each workload gets its own microVM and fastish boot times.

The problem is Firecracker is low-level. You’re managing kernels, root filesystems, network taps, vsocks. I wanted something that felt like Docker but ran microVMs underneath.

What it does

zypi push myapp:latest
zypi run test-app myapp:latest
zypi shell test-app

That’s it. Push a Docker image, run it in a Firecracker VM, shell in if you need to debug.

Under the hood:

Why Elixir ( cause the BEAM and Erlang is cool )

Firecracker exposes a REST API over a Unix socket. Elixir’s supervision trees are perfect for managing fleets of VMs, if one crashes, restart it. The BEAM handles thousands of concurrent connections without breaking a sweat.

Also I just wanted to learn Elixir, and Rust this year.

Use case

The immediate use case is sandboxing MCP tools. If an AI assistant wants to run code or call an untrusted API, spin up a zypi VM, run it there, tear it down. The host is never at risk.

Longer term: a self-hosted platform for running workloads. Deploy from git, scale to zero, wake on request. The Fly/Railway model but on your own hardware.

Status

Experimental. Works on my machine. The CLI exists, VMs boot, networking works, SSH works. Still rough around the edges. Git it a spin