GO — Healthy across the board

• Last commit today
• 12 active contributors
• Distributed ownership (top contributor 36% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Kata Containers is a runtime that executes containers as lightweight VMs using hardware virtualization (Intel VT-x, AMD SVM, ARM Hyp, IBM Power) while maintaining container-like performance and API compatibility. It solves the fundamental security gap in traditional containers by providing workload isolation and kernel security without the overhead of full VMs, supporting x86_64, aarch64, ppc64le, and s390x architectures. Multi-component monorepo structured as: src/runtime/ (Go runtime), src/agent/ (Rust agent running in VM), src/dragonball/ (modular Rust hypervisor with dbs_* crates for ACPI, PCI, virtio devices), src/runtime-rs/ (emerging Rust runtime rewrite), src/libs/ (shared utilities: kata-sys-util, logging, protocols, shim-interface), src/tools/ (genpolicy, kata-ctl, trace-forwarder). Build artifacts target multiple architectures with machine-specific CI pipelines.

Platform engineers and DevOps teams deploying Kubernetes workloads requiring strong isolation boundaries; cloud providers offering multi-tenant container services; enterprises needing VM-level security with container-level performance; contributors to the open-source hypervisor and runtime ecosystems.

Production-ready. The project is actively maintained with a mature CI/CD pipeline across 10+ architectures (see .github/workflows with architecture-specific builds: amd64, arm64, ppc64le, s390x, riscv64). The codebase shows strong engineering discipline with 7.5M+ lines of Rust, 2.9M lines of Go, extensive test coverage orchestrated through GitHub Actions, and established deployment patterns (kata-deploy for Kubernetes). The 2.0+ release cycle indicates intentional versioning strategy.

Moderate complexity and scope. The monorepo spans 3+ major subsystems (src/runtime written in Go, src/agent and src/dragonball in Rust, complex hypervisor implementations), creating large surface area for bugs. Architecture-specific code paths (amd64, arm64, s390x, ppc64le, riscv64) mean platform-specific regressions are possible. CI workflow count (50+ .yaml files) suggests high maintenance burden. However, OpenSSF Scorecard badge and established security practices mitigate risk. Dependency on kernel-specific virtualization features means host OS compatibility is critical.

Active development on Rust runtime rewrite (src/runtime-rs with 6+ crates), hypervisor modularization (dbs_* components in src/dragonball), and policy tooling (genpolicy). Kubernetes integration via kata-deploy (tools/packaging/kata-deploy) showing container orchestration focus. CI expansion to newer architectures (riscv64 preview workflows) and confidential computing support (kata-coco-tests). Strong emphasis on security scanning (cargo-deny, govulncheck, osv-scanner) and linting (editorconfig-checker, shellcheck).

git clone https://github.com/kata-containers/kata-containers.git
cd kata-containers
# Check Rust and Go toolchain availability
cargo --version && go version
# For development: review docs/Developer-Guide.md and src/*/README.md
# Run container check to verify hardware support:
kara-runtime check

Daily commands:

# Build entire workspace
cargo build --release
# Architecture-specific builds (examine .github/workflows/build-checks.yaml)
cargo build -p kata-agent --target aarch64-unknown-linux-gnu --release
# Test suite
cargo test --all
# For runtime-rs specifically
cd src/runtime-rs && cargo build --release

• Cargo.toml — Root workspace configuration defining all Rust crates (agent, libs, dragonball VMM) and shared dependencies—essential for understanding project structure and build.
• src/agent — Kata agent entry point (runs inside the VM guest) and core runtime logic for container lifecycle management, process execution, and resource handling.
• src/dragonball — Dragonball VMM (virtual machine monitor) implementation, the hypervisor responsible for launching and managing lightweight VMs.
• src/libs/shim-interface — Defines the IPC protocol between the container runtime (containerd/CRI-O) and the kata-shim, the critical handshake point for VM lifecycle.
• src/libs/protocols — Protocol buffer definitions and message types for communication between runtime components (shim ↔ agent ↔ hypervisor).
• CONTRIBUTING.md — Developer guidelines, PR workflow, and code standards that every contributor must follow to maintain quality and compatibility.
• .github/workflows — CI/CD pipeline definitions (build, test, release) across multiple architectures; critical for understanding build and validation gates.

Add a new virtio device to Dragonball VMM

1. Define device structure and trait implementation in a new module under src/dragonball/dbs_device/ (src/dragonball/dbs_device)
2. Implement DeviceIo trait for MMIO/PCI register handling (src/dragonball/dbs_device)
3. Register device in the address space manager (dbs_address_space) (src/dragonball/dbs_address_space)
4. Add device creation and initialization in Dragonball main VM builder (src/dragonball)
5. Add unit and integration tests in the device module (src/dragonball/dbs_device)

Add a new container management RPC to kata-agent

1. Define new proto message in src/libs/protocols (e.g., proto/agent.proto) (src/libs/protocols)
2. Regenerate Rust bindings (cargo build in src/libs/protocols) (src/libs/protocols)
3. Implement RPC handler in src/agent/src/rpc.rs or new module (src/agent)
4. Register handler in the agent's main RPC dispatch loop (src/agent)
5. Add integration test in ci/ or src/agent tests/ (src/agent)

Add support for a new CPU architecture

1. Create new module under src/dragonball/dbs_arch (e.g., new_arch.rs) (src/dragonball/dbs_arch)
2. Implement ArchMemoryAddressWidth, ArchCpuModel, and boot logic traits (src/dragonball/dbs_arch)
3. Add architecture-specific device config (MMIO ranges, interrupt handling) (src/dragonball/dbs_arch)
4. Update dbs_boot to handle new arch-specific kernel boot parameters (src/dragonball/dbs_boot)
5. Add GitHub Actions workflow for new architecture CI (.github/workflows)

Tighten security policy / add new seccomp rules

1. Edit or extend policy JSON/configuration in src/agent/policy/ (src/agent/policy)
2. Update rustjail policy application code in src/agent/rustjail/ (src/agent/rustjail)
3. Test with kata-containers policy validation tools or live container (src/agent/policy)
4. Update CONTRIBUTING.md or docs with security rationale (CONTRIBUTING.md)

• Rust — Memory-safe systems programming for shim, agent, and VMM; prevents buffer overflows and use-after-free vulnerabilities in security-critical code.
• Protocol Buffers (protobuf) — Language-agnostic, versioned serialization for IPC between containerd (Go), kata-shim (Rust), and kata-agent (Rust) across different machines/processes.
• QEMU/Dragonball (KVM-based VMM) — Hardware-accelerated virtualization with proven isolation; Dragonball reduces footprint and startup latency vs. full QEMU, meeting container-like performance.
• vsock (virtio socket) — Efficient, secure host-guest communication without requiring network stack; lower latency and overhead than network sockets.
• Linux namespaces & cgroups (rustjail) — Standard OS-level isolation primitives (pid, ipc, network, mount, uts, user, cgroup) enforced inside VM for per-container resource limits and separation.
• seccomp — Restricts system call surface area to reduce attack surface; policy enforced at kernel level for Defense-in-Depth.

• VM per pod (or per container) instead of single shared VM

  • Why: Provides strict isolation and security; each workload has dedicated OS kernel and resources.
  • Consequence: Higher memory footprint and slower startup than process containers; managed by Dragonball's small footprint (~20-50MB) to mitigate.

• Use Dragonball instead of QEMU directly

  • Why: Tailored for Kata's use case; reduced complexity, smaller codebase, faster iteration on Kata-specific features.
  • Consequence: Less mature than QEMU; smaller ecosystem; potential device/feature gaps require custom implementation.

• Single shim process per VM, multiple containers share VM

  • Why: Amortizes VM overhead (boot, memory) across containers in a pod;
  • Consequence: undefined

Hardware requirements non-obvious: kata-runtime check must pass but succeeds silently without detailed KVM/nested virt confirmation; use --verbose to debug. Architecture-specific behavior: Code paths diverge significantly for amd64 vs s390x vs riscv64 (see src/dragonball/dbs_arch/); generic changes may fail on non-native targets. Workspace dependencies via [workspace.dependencies]: versions locked in root Cargo.toml; updating individual crate versions via member Cargo.tomls can cause workspace resolution failures. CI is expensive: 50+ workflow files mean PR validation takes 20+ minutes across matrices; local cargo test won't catch architecture-specific bugs. Rust MSRV is pinned to 1.88: older toolchains will fail silently on nightly features. vsock communication is order-sensitive: protocol defined in src/libs/shim-interface/ requires exact message sequencing between runtime and agent or deadlocks occur.

• VSock (Virtual Socket) — Inter-VM-host communication transport in Kata; src/agent/vsock-exporter/ uses this for reliable message passing between runtime and agent without network stack overhead
• Hardware Virtualization Extensions — Core requirement for Kata; src/dragonball relies on VT-x (Intel), SVM (AMD), Hyp (ARM), SIE (IBM Z) for efficient lightweight VM execution
• OCI Runtime Specification — Contract that src/runtime/ implements; defines container lifecycle hooks (create, start, stop) and JSON config format for container isolation parameters
• Namespace and Cgroup Isolation — Applied by src/agent/rustjail/ inside guest VM; creates process isolation per container even when multiple containers share hypervisor
• [Device Models (PCI, Virtio)](https://wiki.osdev.org/PCI and https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html) — src/dragonball/dbs_pci/ and dbs_virtio_devices/ implement guest-visible hardware; enables efficient block, network, serial I/O without full device emulation
• ACPI (Advanced Configuration and Power Interface) — src/dragonball/dbs_acpi/ generates guest ACPI tables for CPU/memory hotplug and power management; critical for dynamic resource adjustment
• Shim Pattern (Runtime Shim) — src/libs/shim-interface/ defines lightweight proxy between container daemon (containerd) and Kata runtime; enables socket-based IPC without process overhead

• opencontainers/runc — Reference OCI runtime implementation that Kata integrates with via shim interface; defines container lifecycle semantics Kata must support
• containerd/containerd — Container daemon that orchestrates Kata runtime; kata-deploy integrates as CRI plugin to enable Kubernetes scheduling
• firecracker-microvm/firecracker — Alternative lightweight VM runtime for containers; design competitor using different hypervisor model (Rust-based, minimal device set)
• rust-vmm/rust-vmm — Shared ecosystem of modular Rust hypervisor crates; Kata's dbs_* libraries follow this pattern and co-evolve with rust-vmm components
• kubernetes/kubernetes — Primary deployment target; kata-deploy provides native CRI integration enabling Kata as pod runtime option in K8s clusters

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive CI workflow for RISC-V release builds

The repo has a preview RISC-V CI workflow (build-checks-preview-riscv64.yaml) but lacks a complete release workflow for RISC-V like it has for amd64, arm64, ppc64le, and s390x. With RISC-V architecture gaining importance and the preview workflow in place, creating a full release-riscv64.yaml workflow would enable production-ready RISC-V builds and complete the multi-architecture release coverage.

• [ ] Review existing release workflow patterns in .github/workflows/release-amd64.yaml, release-arm64.yaml, release-ppc64le.yaml, release-s390x.yaml
• [ ] Analyze the preview RISC-V workflow in .github/workflows/build-checks-preview-riscv64.yaml to understand current limitations
• [ ] Create .github/workflows/release-riscv64.yaml with full release build steps, artifact publishing, and payload generation
• [ ] Update release.yaml to trigger the new RISC-V release workflow alongside other architectures
• [ ] Test on a RISC-V runner and document any architecture-specific considerations

Add integration tests for kata-ctl command-line interface

The repo contains src/tools/kata-ctl source code but lacks dedicated CI integration tests for the CLI tool. Given the critical role of kata-ctl in managing Kata Containers (visible in the workspace members), adding tests would ensure CLI reliability, prevent regressions, and improve user experience. This follows the existing pattern of dedicated test workflows like run-kata-deploy-tests.yaml.

• [ ] Review kata-ctl source code in src/tools/kata-ctl/ to identify key command groups and functionality
• [ ] Examine existing CLI test patterns from other tools (trace-forwarder, genpolicy) if they exist
• [ ] Create a new workflow .github/workflows/run-kata-ctl-tests.yaml that builds kata-ctl and runs integration tests
• [ ] Write tests in src/tools/kata-ctl/ covering major CLI commands (e.g., pod operations, configuration management)
• [ ] Add the workflow trigger to appropriate CI pipelines (ci.yaml, ci-on-push.yaml)

Add unit test coverage for dragonball VMM device implementations

The Dragonball VMM codebase in src/dragonball/ contains multiple device crates (dbs_legacy_devices, dbs_virtio_devices, dbs_device) but appears to lack dedicated CI coverage for device unit tests. Adding a focused test workflow would ensure device reliability across architectures, prevent regressions in critical VMM components, and follow Rust best practices for library testing.

• [ ] Audit existing unit tests in src/dragonball/dbs_device crates using 'cargo test --lib' commands
• [ ] Create .github/workflows/dragonball-device-tests.yaml that runs 'cargo test' for all device crates with architecture variations
• [ ] Add specific test targets for dbs_legacy_devices, dbs_virtio_devices, and dbs_device in the workflow
• [ ] Include coverage reporting or test output validation to catch device-specific failures early
• [ ] Integrate workflow into the basic CI checks (basic-ci-amd64.yaml, basic-ci-s390x.yaml patterns)

• idea: Add missing integration tests for src/dragonball/dbs_device/ device hot-plug scenarios; current test coverage appears limited to cold boot paths in CI workflows
• idea: Document CPU architecture differences in src/dragonball/dbs_arch/ with concrete examples for arm64 vs ppc64le vs riscv64; README stubs exist but lack decision trees
• idea: Extend cargo-deny and govulncheck coverage to member crates under src/tools/; current dependency scanning in .github/workflows/cargo-deny.yaml may miss tool-specific transitive vulnerabilities

Kata Containers demonstrates a strong security posture with comprehensive CI/CD security workflows (govulncheck.yaml, cargo-deny.yaml, osv-scanner.yaml, CodeQL, Scorecard). However, several concerns exist: (1) The codebase uses deprecated Rust 2018 edition instead of 2021, missing modern safety improvements; (2) Incomplete dependency information prevents full vulnerability assessment; (3) Workspace fragmentation with excluded directories could lead to inconsistent security updates. The project's extensive security automation (42+ security-focused workflows) is commendable. No hardcoded secrets, injection risks, or exposed infrastructure issues were identified in the provided file structure. Recommendation: Update to Rust 2021 edition and ensure all workspace members maintain synchronized, regularly-audited dependencies.

• Medium · Rust Edition 2018 - Deprecated Edition — Cargo.toml - workspace.package.edition = '2018'. The workspace is configured with Rust edition 2018, which is now deprecated. Rust 2021 edition provides improved safety features and better tooling support. This may indicate the codebase hasn't been updated to leverage modern Rust safety improvements. Fix: Update to Rust edition 2021 to benefit from modern safety features and improved compiler diagnostics. Run 'cargo fix --edition' to automatically migrate the codebase.
• Medium · Incomplete Dependency Information in Provided File — Cargo.toml - [workspace.dependencies] section. The dependency manifest provided (Cargo.toml snippet) is incomplete - it shows workspace configuration but cuts off at '[workspace.dependencies]' with incomplete entries ('kv' without version specification). This makes it impossible to perform comprehensive vulnerability scanning of direct dependencies. Fix: Provide complete Cargo.toml files for all workspace members. Run 'cargo audit' regularly to check for known vulnerabilities in dependencies. Implement automated dependency scanning in CI/CD pipelines (note: govulncheck.yaml and cargo-deny.yaml workflows are present, which is good).
• Low · Workspace Members Excluded from Root Workspace — Cargo.toml - [workspace].exclude section. The 'src/tools' directory is excluded from the root workspace, and there's a note about local builds potentially creating workspace confusion. This could lead to inconsistent dependency versions and security updates across the codebase if not carefully managed. Fix: Document the reason for exclusions clearly. Consider consolidating excluded crates into the main workspace if possible, or ensure they have synchronized dependency management. Review exclusions periodically.
• Low · Minimum Rust Version Constraint — Cargo.toml - rust-version = '1.88'. Rust version is pinned to 1.88, but this is relatively recent. Very recent version pins can cause maintenance burden and may exclude users on stable releases. However, for a security-focused project like Kata Containers, this is reasonable. Fix: Document the rationale for the minimum Rust version requirement in CONTRIBUTING.md. Consider the trade-off between security features in newer versions and broader compatibility.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/kata-containers/kata-containers shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live kata-containers/kata-containers repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/kata-containers/kata-containers.

What it runs against: a local clone of kata-containers/kata-containers — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in kata-containers/kata-containers | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of kata-containers/kata-containers. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/kata-containers/kata-containers.git
#   cd kata-containers
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of kata-containers/kata-containers and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "kata-containers/kata-containers(\\.git)?\\b" \\
  && ok "origin remote is kata-containers/kata-containers" \\
  || miss "origin remote is not kata-containers/kata-containers (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "src/agent" \\
  && ok "src/agent" \\
  || miss "missing critical file: src/agent"
test -f "src/dragonball" \\
  && ok "src/dragonball" \\
  || miss "missing critical file: src/dragonball"
test -f "src/libs/shim-interface" \\
  && ok "src/libs/shim-interface" \\
  || miss "missing critical file: src/libs/shim-interface"
test -f "src/libs/protocols" \\
  && ok "src/libs/protocols" \\
  || miss "missing critical file: src/libs/protocols"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/kata-containers/kata-containers"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.