Katakate/k7

k7 – Self‑hosted secure VM sandboxes for AI compute

What it is

• An open‑source platform (Apache‑2.0) that lets you spin up lightweight, isolated virtual‑machine sandboxes at scale. It is aimed at AI agents that need to run arbitrary code safely, but it can also be used for custom serverless workloads, hardened CI/CD runners, or blockchain execution layers.

Key components

Piece	Role
Kubernetes (K3s)	Orchestrates the sandboxes across one or many nodes.
Kata Containers	Turns a container into a tiny VM for strong isolation.
Firecracker	Super‑fast micro‑VM boot (used via the kfd backend).
QEMU	Full‑featured VM option (kql backend) with Longhorn‑backed disks.
Longhorn	Replicated PVC storage for QEMU‑based sandboxes, enabling snapshots and cross‑node mobility.
k7d	Katakate’s own micro‑VM runtime daemon that provides a custom KVM‑based VMM with ultra‑fast copy‑on‑write (CoW) fork (≈5 ms).
Devmapper thin‑pool	Efficient block‑device storage for the Firecracker backend.
Cilium (optional)	Network policy enforcement and optional Hubble observability.

Backends – you pick one when installing or creating a sandbox:

• kfd – Kata + Firecracker + devmapper (fast boot, no persistent storage).
• kql – Kata + QEMU + Longhorn (persistent, snapshot‑able disks).
• k7d – Katakate’s custom KVM runtime (fast CoW fork, in‑VM Docker support).
• k7d-fc – k7d plus Firecracker jailer.

Performance highlights (median on a Hetzner AX41 node):

• Create → Ready: 2.1 s for k7d/k7d-fc, 17.1 s for kql.
• Warm fork (disk + memory CoW): ~5 ms at the VMM level, ~2 s end‑to‑end for k7d.
• Pause / resume: sub‑second for k7d (memory retained), a few seconds for kql.

How you interact

• CLI (k7) – installable via an APT package (apt install k7). Commands include install, create, list, delete, fork, pause, snapshot, and API control (api enable/disable).
• HTTP API – automatically deployed as a k7-api service on the cluster (NodePort 31007 by default). TLS is set up with a self‑signed CA; you can plug in real certs or use Let’s Encrypt via a Caddy sidecar.
• Python SDK (k7-sdk) – pip‑installable client for synchronous or asynchronous use. It mirrors the CLI actions (create, exec, fork, list, delete).

Typical workflow

1. Prepare a node – Ubuntu 24.04, KVM access, a spare raw disk for the thin‑pool, Ansible, Docker.
2. Run k7 install --backend kfd,kql,k7d – the playbook provisions K3s, Kata, Firecracker, QEMU, Longhorn, and the k7d daemon.
3. Configure the CLI – copy the generated CA cert, set the API URL and key.
4. Create a sandbox – supply a k7.yaml (image, resources, optional egress whitelist, before‑script, env file) and run k7 create.
5. Execute code – k7 exec <sandbox> -- '<cmd>' or use the SDK’s exec method.
6. Fork / snapshot – warm CoW fork (k7 fork) for rapid branching, or disk‑only snapshots with the QEMU backend.

Security posture

• Each sandbox runs inside a hardware‑isolated VM (Kata or custom k7d).
• Firecracker sandboxes are further chroot‑jailered; Kata applies seccomp and drops all Linux capabilities by default.
• Network egress can be whitelisted per sandbox; optional Cilium policies add another layer.
• The platform is in beta and undergoing a security review—use caution for highly sensitive workloads.

Roadmap highlights (from ROADMAP.md)

• GPU passthrough support for ML workloads.
• HA mode for the k7d-fc backend.
• More fine‑grained policy tooling and observability integrations.

Who might use it

• Developers of AI agents (e.g., LangChain ReAct) that need to run untrusted code safely.
• Teams building private serverless platforms without relying on cloud providers.
• Organizations requiring hardened CI/CD runners that avoid Docker‑in‑Docker risks.
• Blockchain projects that need an execution layer for AI‑driven dApps.

---

All details above are taken directly from the repository’s README; no additional features have been inferred.