A real official arm64 build — with the same "which file" trap as Arch

Kali Linux, maintained by Offensive Security, publishes real generic arm64 installer ISOs alongside its more numerous single-board-computer images — the file you actually want is a plain installer ISO like kali-linux-installer-arm64.iso from kali.org's official downloads page, not one of the many Raspberry Pi, Odroid, or Orange Pi-specific images on the same page. Those SBC builds carry hardware-specific kernels and won't boot correctly in a generic VM, the same trap covered in the Arch Linux ARM post for a different reason. The good news relative to Arch: Kali's generic installer boots and installs like any normal Linux ISO — no board-specific quirks once you've picked the right file.

Not in the official-image picker — the local-file path

Kali isn't part of Velo Workspaces' curated "download an official image" list the way Ubuntu, Debian, and Fedora are. Download the installer ISO from kali.org yourself, then use "choose a local OS image file" when creating the workspace instead of the one-click fetch. Everything after that — the installer itself, the resulting workspace — runs the same as any other Linux guest.

The networking caveat that matters specifically here

This is worth knowing before you build a testing workflow around it: Velo Workspaces' current networking is NAT-only — bridged networking requires an entitlement not yet part of the app. For most Linux guests that's invisible day to day. For Kali specifically, it matters more, because a meaningful share of what the toolkit is built for — scanning or testing other devices on your actual LAN — assumes the guest can see that network the way a bridged interface would, not from behind NAT. Confirm what a given tool actually needs before assuming it'll reach what you expect it to.

Where disposability earns its keep

This is a case where the disposable-workspace pattern fits especially well, for a reason specific to a testing toolkit: tool installs, scan results, and test artifacts from one engagement have no reason to persist into the next one, and a testing lab that's accumulated months of leftover state is exactly the kind of environment where "did I actually test against a clean baseline" becomes a real question. Seal a configured Kali install as a base image once, then clone a fresh disposable workspace per engagement — closing it when you're done costs nothing, and the next one starts from the identical known-good state every time. See base images as versioned infrastructure for how that half of the mechanism works.

Related reading: Arch Linux on Apple Silicon, another local-file-path distro but for a different reason; Ubuntu on Apple Silicon for the official-picker path this one skips; and what a disposable development environment actually is. Or download Velo Workspaces and try it yourself.