Skip to main content
Katakate (k7) lets you run secure VM sandboxes on Kubernetes — Firecracker, QEMU + Longhorn, or k7d. This Quickstart gets you from zero to a working sandbox via CLI and Python SDK.
If you already installed k7 previously, consider running make uninstall before reinstalling to avoid stale cached files in a previous .deb.

Requirements

  • Ubuntu host with hardware virtualization (KVM)
    • Check: ls /dev/kvm should exist
    • kfd and kql: amd64 or arm64. k7d is amd64 / x86_64 only.
    • Cloud guidance: AWS .metal, GCP (enable nested virtualization), Azure D/Ev series; typical VPS often lack KVM. Hetzner: Robot dedicated only (not Cloud VPS).
  • For the kfd (Firecracker) backend: one raw, unformatted disk for the LVM thin-pool. kql and k7d do not need a spare disk.
  • Docker (the install playbook builds the k7-api:local image on the node). Compose is not required to run the API — it is a K3s Deployment.
    • Install Docker: curl -fsSL https://get.docker.com | sh
  • Ansible for the installer (Ubuntu):
  • Python 3.10+ on the client for the SDK
Tested setup: Hetzner Robot dedicated, Ubuntu 24.04, with a spare raw NVMe for the kfd thin-pool. Dual-NVMe boxes (no third drive): put Ubuntu on one disk (SWRAID 0) and leave the other raw — see Hetzner node setup. Do not pin --disk /dev/nvme1n1: NVMe names swap across reboots; the playbook auto-detects the empty non-root disk.

Install the CLI (APT)

Install the k7 CLI on the node(s) that will host the VM sandboxes:

Install K7 on your node(s)

k7 install with no flags provisions both Kata backends (kfd + kql) on localhost. Add k7d explicitly for the warm-fork microVM runtime. The playbook in k7 0.2.2+ downloads k7d 0.2.1 by default; PPA k7 0.2.1 still defaults k7d to 0.1.0, so pin the version:
That installs and wires up Kubernetes (K3s), Kata, Firecracker + Jailer + thin-pool (kfd), QEMU + Longhorn (kql), and the k7d daemon + RuntimeClass k7. Pass -v for verbose output. Two-node / HA inventories: Multi-node clusters.
You should see “Installation completed successfully!” when done. Add -v for verbose output.

The API and managing keys

k7 install deploys the K7 API automatically as a k7-api Deployment in kube-system. K3s keeps it running and reschedules it on failure — there’s no separate “start” step. If you want a CLI-only install with no API deployed, pass --no-api to k7 install.

Check API status

Get the endpoint

Generate an API key

A scoped key cannot list or mutate another namespace, and cannot run all-namespaces operations. Keys without -n keep unrestricted access (backward compatible).

Temporarily disable / re-enable the API

  • API keys are stored at /etc/k7/api_keys.json on the cluster node. Authentication accepts the X-API-Key header or Authorization: Bearer <token>.
  • The previous top-level commands k7 start-api / k7 stop-api / k7 api-status / k7 get-api-endpoint are deprecated; they still work for one release and emit a deprecation warning pointing at the new home.

Create your first sandbox via CLI

Example k7.yaml:

Create a sandbox

CLI k7 create with no --egress / --egress-open blocks all egress. An API/YAML request that omits egress_whitelist leaves egress open. Use --egress-open or omit the field in YAML when you want the internet.

Shell into your sandbox

List sandboxes

Delete a sandbox

Delete all sandboxes

Prerequisites for the SDK

Create your first sandbox via Python SDK

Install the SDK on your client machine:
Use the synchronous client:
Async variant:

Next steps

  • Explore the CLI guide: /guides/cli
  • Explore the Python SDK guide: /guides/python-sdk
  • Integrate with the REST API: /api/introduction