Infrastructure sandboxes for template-driven development

Recommendation (13 September 2026): make isolation a capability-selected execution tier, with a receipt that records the backend, host capabilities, guest assets, and tests actually run. Keep ordinary devcontainers as the default for reproducible source and tool checks; use kind or k3d for Kubernetes API and controller behavior; select an isolated guest or dedicated test host for claims about boot, kernel behavior and host-level Ansible convergence. Firecracker, Cloud Hypervisor, QEMU, and Kata are backend options with different device and integration envelopes, not one mandatory Praetor runtime. Qualification should be measured on each supported host/backend combination rather than inferred from a template.

What each boundary proves

A devcontainer shares the host kernel. The Development Containers specification defines a portable container-oriented development contract, so it is a good Tier 0 for compilers, scanners, unit tests, and user-space tooling. A container may run systemd, but container tests do not establish a separate guest kernel, machine boot/reboot, or production host behavior. Praetor currently has template devcontainer_features and devcontainer adoption documentation, but the reviewed repository exposes no verified microVM or VM execution adapter; this document proposes tiers, not existing support.

kind’s current quick start says Kubernetes nodes run as Docker containers, with Docker, Podman, or nerdctl provider selection. k3d’s project documentation describes k3s server and agent nodes as containers and currently lists Docker as its runtime. They are Tier 1 choices for API, scheduling, image, service, and multi-node control-plane tests. Their nodes still share the container host kernel, so a passing k3s test is not a passing systemd, kernel-module, cgroup-mode, or host-network test. Port mappings, nested runtimes, and rootless provider behavior must be capabilities in the receipt.

Tier 2 is a KVM-accelerated guest VM, normally QEMU or Cloud Hypervisor, booting a pinned kernel and rootfs. QEMU’s current manual documents KVM on Linux and a broad device-emulation and passthrough model; its security guidance requires a supported machine type plus a virtualization accelerator for isolation claims (introduction, security). Cloud Hypervisor’s current README documents KVM-oriented virtio devices, memory/CPU hotplug, and VFIO passthrough. QEMU has the broader device and firmware envelope; Cloud Hypervisor is a smaller cloud workload VMM. Either can provide the guest kernel and systemd boundary needed for k3s host tests and Ansible against an isolated host, subject to a tested image, network, storage, and privilege setup.

Firecracker is a narrower Tier 2 option. Its current getting-started guide requires Linux KVM, read/write /dev/kvm, a guest kernel, and an ext4 rootfs. That means it is not AWS-only: AWS created it, but the technical prerequisite is a Linux host with KVM (nested virtualization may be needed). Its FAQ describes a minimal device model: virtio-net, virtio-balloon, virtio-block, virtio-vsock, serial console, and a minimal stop controller. Its jailer guide adds trusted path ownership, chroot/pivot-root, cgroups, namespaces, /dev/kvm, and /dev/net/tun setup. Networking therefore needs an explicit TAP/CNI/namespace design; the production host setup also says Firecracker does not filter network traffic itself. Firecracker is suitable for Linux workload isolation when this device model is enough, but is not a generic GPU or device-passthrough backend. Its current FAQ also documents guest reboot as unsupported; a VMM restart is not evidence of an in-guest reboot lifecycle. Therefore k3s or Ansible suites requiring reboot or unsupported host devices should select QEMU/Cloud Hypervisor or report unsupported. No Praetor Firecracker adapter was verified.

Kata is a Kubernetes/container-runtime integration layer, rather than a general host-test runner. Its architecture launches a VM and guest agent per sandbox, while hypervisor support currently lists GPU support for QEMU and not for Firecracker or Cloud Hypervisor. Kata’s installation requirements require hardware virtualization and accessible /dev/kvm (or the documented Hyper-V alternative). Select Kata when the test is specifically a Kubernetes pod sandbox isolation test; select a direct VM when the test needs to administer a guest host.

Memory accounting must name the boundary. A container adds runtime/image/cgroup costs while sharing the host kernel. Total VM memory includes guest RAM (containing guest kernel and workload memory) plus VMM, device and networking overhead; rootfs image storage is accounted separately. Firecracker’s FAQ and site mention a small VMM footprint, but that is process overhead, not total guest or workload memory; it is not a Praetor benchmark. No startup, throughput, or cost numbers should be recorded until measured on the target host and pinned versions. GPU/device claims must be capability probes backed by the selected VMM’s current device documentation, never template labels.

Infrastructure and configuration tests

Terraform plan is a proposed change graph and does not establish that infrastructure can be created. Terraform’s test language and provider mocking support module tests with explicit provider mocks. Every provider interaction must be mocked or admitted; an ordinary plan can still contact provider APIs. They should occupy Tier 0/1 planning tests. A separate, explicitly admitted integration tier may run real provider operations in disposable accounts/projects, with credentials, quotas, cleanup, and provider/API receipts. A successful mocked plan must never be reported as a real infrastructure qualification.

Ansible Molecule documents container-backed role tests and a create/converge/idempotence/verify/destroy workflow; the Ansible project’s current documentation also packages repeatable control nodes with Docker or Podman (ansible-builder). Container scenarios cover user-space configuration. Roles that assert systemd, kernel modules, boot, host routes, or privileged networking need a VM-capable driver or an explicitly provisioned isolated host. An explicit inventory and lifecycle playbooks can target such a host; selecting a target does not establish its isolation or cleanup authority.

OpenTofu has its own test command and provider mocks. Select and pin Terraform or OpenTofu explicitly and test their provider/lockfile behavior independently; file extensions alone do not establish engine compatibility.

For scale, the K3s requirements list a server minimum of two CPU cores and 2 GB RAM, with workload-dependent sizing. Those requirements illustrate why a small VMM does not make a Kubernetes environment a few-megabyte job; they are upstream guidance, not local measurements.

Proposed tier contract

Templates should declare required capabilities (container-runtime, kubernetes-in-container, kvm, guest-systemd, guest-network, vfio-gpu, real-provider, or isolated-ansible-host) and acceptable backends. The runner selects the cheapest backend satisfying the declaration, or returns unsupported/unknown with the missing probe. Every run records backend/version, host and guest identity, image/kernel/rootfs digests, network and device mode, command bounds, and evidence hashes. A qualification suite should cover positive, negative, and boundary cases for each tier, then replay after template or backend changes. Source links above were checked against upstream pages on 2026-09-13; where a page documents a moving main branch, the eventual adapter must pin and record a release or commit. The current repository contains no verified microVM support, so adoption must remain an explicit future adapter with this receipt contract rather than a fabricated claim.