zypi run, zypi go
zypi run, zypi go
I know this probably does not mean much to anyone except for myself at the moment, but this is a demonstration of something pretty neat.
05:26:16 jm@pop-os zypi ±|jm/zero-trust-research ✗|→ python test_zypi_client.py
Health: True
Exit: 0
Stdout: Hello from Firecracker!
Stderr:
05:26:20 jm@pop-os zypi ±|jm/zero-trust-research ✗|→ source ./tools/zypi-cli.sh
Zypi CLI loaded. Type 'zypi' for help.
05:26:35 jm@pop-os zypi ±|jm/zero-trust-research ✗|→ zypi list
{
"containers": [
{
"id": "exec_09a0bf5768c1b420",
"status": "running",
"ip": "10.0.0.5",
"started_at": "2026-01-17T23:26:19.041967Z",
"image": "ubuntu:24.04",
"rootfs": "/var/lib/zypi/containers/exec_09a0bf5768c1b420/rootfs.ext4",
"created_at": "2026-01-17T23:26:18.790932Z"
}
]
}
05:26:46 jm@pop-os zypi ±|jm/zero-trust-research ✗|→ cat test_zypi_client.py
from zypi_client import ZypiClient
client = ZypiClient('http://localhost:4000', default_image='ubuntu:24.04')
# Health check
print('Health:', client.health_check())
# Run a simple command
exit_code, stdout, stderr = client.exec(['echo', 'Hello from Firecracker!'])
print(f'Exit: {exit_code}')
print(f'Stdout: {stdout}')
print(f'Stderr: {stderr}')
05:26:58 jm@pop-os zypi ±|jm/zero-trust-research ✗|→ python test_zypi_client.py
Health: True
Exit: 0
Stdout: Hello from Firecracker!
Stderr:
05:27:09 jm@pop-os zypi ±|jm/zero-trust-research ✗|→ zypi list
{
"containers": [
{
"id": "exec_09a0bf5768c1b420",
"status": "running",
"ip": "10.0.0.5",
"started_at": "2026-01-17T23:26:19.041967Z",
"image": "ubuntu:24.04",
"rootfs": "/var/lib/zypi/containers/exec_09a0bf5768c1b420/rootfs.ext4",
"created_at": "2026-01-17T23:26:18.790932Z"
},
{
"id": "exec_b83ba5f6e4a7a5d5",
"status": "running",
"ip": "10.0.0.9",
"started_at": "2026-01-17T23:27:07.966024Z",
"image": "ubuntu:24.04",
"rootfs": "/var/lib/zypi/containers/exec_b83ba5f6e4a7a5d5/rootfs.ext4",
"created_at": "2026-01-17T23:27:07.720023Z"
}
]
}
huh, what?
From the outside, this looks like I ran echo twice and
got some JSON back.
What actually happened:
- My Python client requested a computation
- The system instantiated a Firecracker microVM with Ubuntu 24.04
- The VM booted (in milliseconds, thanks to Firecracker’s optimizations)
- My command executed inside the isolated environment
- Results were returned through the API
- The VM persisted, ready for more commands or inspection
- All resources are tracked and manageable
I didn’t just write a script. I built a programmable VM factory with:
- Language bindings (Python client library)
- CLI tools
- HTTP API
- Lifecycle management
- Network isolation
- Persistent state
Why This Matters to Me (And Maybe You)
As a developer, I’ve been trained to think in containers. Docker made isolation accessible, but it’s still fundamentally shared-kernel isolation with escape vulnerabilities since that is how control groups, cgroups, runc fundamentally work.
What I’ve shown here is different: hardware isolation with the ergonomics of containers. It’s the best of both worlds:
- The security of VMs
- The speed and density of containers
- The developer experience of simple APIs
This isn’t future tech, this is what already runs massive serverless platforms. The cool kickflip here is making it this accessible, this composable, this simple to use.
So yeah, maybe it’s just:
echo "Hello from Firecracker!"today.
But the architecture it demonstrates, programmable, isolated execution environments with full management capabilities, is the foundation of the next generation of computing platforms.
And I built it on my laptop. And hey, you could build it on your laptop too.
Link
another piece
The micro vm has a guest agent binary for the time being, as negotiating ssh tunnels, and wireguards, seemed like a lot when a vsock could get us most of the way there. So, just giving that a whirl.
It’s written in golang, and it doesn’t do much, you can see it in
guest-agent/