SaaS Metrics
GitHub Issue
K8s deployment
## Summary
Zeroboot's current deployment tooling (`deploy/deploy.sh` + systemd) targets bare-metal
or standalone VM hosts. There is no documented path for running Zeroboot inside a
Kubernetes cluster, which is where most production AI workloads live today.
## The gap
To run Zeroboot in k8s, the following is needed but undocumented:
1. **Which EC2/cloud instance types expose `/dev/kvm`** — e.g. AWS `t3` (burstable) does
NOT, while `c5`/`m5`/`c6i` (Nitro non-burstable) do. This is non-obvious and a common
blocker. ...
View Raw Thread
Developer & User Discourse
congwang-mk • Apr 1, 2026
One of the reasons Kubernetes deployment is complex here is the `/dev/kvm` dependency — you need specific instance types, device plugins, and privileged access.
If the goal is sandboxing agent workloads in k8s, [sandlock](https://github.com/multikernel/sandlock) avoids this entirely. It's pure userspace (Landlock + seccomp), so it:
- Runs in any Linux container — no device plugins, no `/dev/kvm`, no privileged mode
- Installs via `pip install sandlock`
- Provides network allowlisting, resource limits, filesystem isolation, and port virtualization
The tradeoff is isolation granularity (syscall-level vs hardware-level), but for most AI agent sandboxing use cases, it's sufficient and dramatically simpler to deploy.
If the goal is sandboxing agent workloads in k8s, [sandlock](https://github.com/multikernel/sandlock) avoids this entirely. It's pure userspace (Landlock + seccomp), so it:
- Runs in any Linux container — no device plugins, no `/dev/kvm`, no privileged mode
- Installs via `pip install sandlock`
- Provides network allowlisting, resource limits, filesystem isolation, and port virtualization
The tradeoff is isolation granularity (syscall-level vs hardware-level), but for most AI agent sandboxing use cases, it's sufficient and dramatically simpler to deploy.
The PR includes:
- **Dockerfile** — multi-stage build with Firecracker bundled; vmlinux/rootfs mounted via PVC
- **deploy/k8s/** — namespace, PVC, Deployment (KVM device plugin, podAntiAffinity, health probes), Service, and HPA based on `zeroboot_concurrent_forks`
- **docker/entrypoint.sh** — handles snapshot creation on first boot, skips if already present on PVC (no more 15s re-snapshot on restart)
- **docs/KUBERNETES.md** — EC2 instance selection guide (c8i/m8i/r8i recommended for nested virt on non-metal sizes), KVM device plugin setup, autoscaling with custom metrics, Prometheus ServiceMonitor config
Happy to incorporate any feedback!