Overview: Confirm the host is x86 Linux on a distribution from the current lab matrix before you install. The Local Path command is the same on bare metal and on a full virtual machine. Root Lock by HeartSuite ships a 6.18 kernel for new images (uname -r is 6.18.9-hs on the fielded pin) and a 5.19 kernel only for old-glibc hosts (Debian 11, Ubuntu 20.04). Each line has its own configuration.
See the Distro Compatibility Matrix for tiers, versions, and kernel line per row. That page is the source for which bases are Supported, In lab, Experimental, or Legacy.
Supported platforms
| Component | Supported |
|---|---|
| Architecture | x86 (64-bit) |
| Distributions | Current k6 lab set: Debian 12/13, Ubuntu 22.04/24.04 (Supported). Ubuntu 26.04, Rocky 9, Fedora 42 (In lab). Alpine 3.21, CentOS Stream 9, openSUSE Tumbleweed (Experimental). Debian 11 and Ubuntu 20.04 (Legacy, 5.19 only). RHEL, AlmaLinux, SLES, and other Ubuntu-derived images: customer validation. Full notes: Distro Compatibility Matrix. |
| Kernels | 6.18 for new installs (6.18.9-hs). 5.19 only on Debian 11 / Ubuntu 20.04. |
Do not use the April 2026 v1.6.4 list (Fedora 41, Rocky 9.7, Alpine 3.21 as “validated,” Ubuntu 22.04 omitted). That table is retired.
Kernel
New Debian 12/13 and Ubuntu 22.04/24.04 installs boot the 6.18 Root Lock kernel. Debian 11 and Ubuntu 20.04 take the k5 installer and 5.19 only — they must not consume the 6.18 bundle. The Dashboard verifies kernel activation after initial setup and provides orientation on every boot.
Software compatibility notes
The Root Lock kernel omits eBPF, FUSE, OverlayFS, user namespaces, AppArmor, and KVM host-mode. Tools that need those interfaces run on another host or on the maintenance kernel.
The Root Lock kernel is installed alongside your existing kernel via GRUB — it does not replace it. Setup Mode reveals programs that would fail in Lockdown in the Dashboard review queues. Software not listed below is not automatically denied; Lockdown still requires an allowlist entry for each program.
| Workload | On the Root Lock kernel |
|---|---|
| eBPF tooling (Falco, bpftrace, bcc, Cilium, Tetragon, …) | Syscall omitted |
| FUSE (sshfs, s3fs, rclone, AppImage, gocryptfs, …) | Omitted |
| Overlay / typical container storage | Omitted. Dynamic Kubernetes after Lockdown is also a poor fit because of the mount seal. |
| AppArmor userspace (Snap, Ubuntu profiles, LXD) | Omitted |
| Unprivileged user namespaces / rootless containers | Omitted |
| KVM hypervisor host | Not a supported product role. Root Lock as a guest on KVM/VMware/cloud is supported. |
Bare metal, virtual machines, and nested VMs
The Local Path install command is the same on a physical machine and on a full virtual machine. Cloud Path is a pre-built image of that same install.
What differs is the machine you run it on: firmware and real devices on metal; virtio and a hypervisor serial console on a VM.
| Environment | Supported for install | What differs |
|---|---|---|
| Bare metal | Yes | Keyboard and monitor for the boot path. Firmware, physical disks, and physical NICs are in play. |
| Full VM with hardware virtualization (KVM, VMware, AWS/GCP/Azure and other cloud hypervisors) | Yes | The hypervisor serial console is the boot path (virsh console, AWS EC2 Serial Console, Linode LISH, Hetzner console, and similar). Devices are virtio or the cloud equivalent. |
| A VM nested inside another VM without hardware virtualization | No | The installer stops at the start. Install on the outer machine, or use a host that exposes /dev/kvm. |
Root Lock must boot its own kernel, so it runs on bare metal or a full VM. Shared-kernel container guests (OpenVZ, LXC, Docker/Podman sharing the provider kernel, systemd-nspawn) belong on a separate host. Nested guests need /dev/kvm on the outer machine.
If /dev/kvm is missing, install Root Lock on that machine itself.
See Where Root Lock is not a fit and Reduced Kernel Footprint.
When the host matches these requirements, continue to Getting Started.