Same CPU story, different distro defaults

Debian on an Apple Silicon Mac runs the same way Ubuntu does: natively on arm64, not emulated. Debian 13 "Trixie," the current stable release, ships arm64 as one of its full, officially supported architectures — alongside amd64, armhf, armel, ppc64el, riscv64, and s390x — not a secondary or best-effort build. One thing worth disambiguating up front: Debian 13 also added real driver support for Apple Silicon MacBook hardware specifically (trackpad/keyboard controllers, for projects like Asahi Linux that install Debian directly on the bare metal). That's a different thing entirely from what this post and Velo Workspaces are about — Debian running as a guest inside a VM on the Mac, where none of that bare-metal driver work is relevant, because the guest never touches the physical trackpad or keyboard controller at all.

The cloud image variant that skips cloud-init entirely

This is the most useful thing to know about Debian specifically, and it's genuinely different from Ubuntu's situation. Debian publishes several official cloud image variants: genericcloud (a trimmed hardware-driver set meant for any virtualized environment) and nocloud — which, as the name says, skips cloud-init entirely and boots straight to a usable system rather than waiting on a datasource that was never going to show up. Ubuntu's cloud images assume cloud-init by default, which means wiring up a NoCloud datasource by hand (boot arguments, a seed server) if you're setting things up yourself outside a tool that automates it. Debian's nocloud variant is built for exactly the plain-local-VM case this sidesteps — there's no datasource dance to get wrong in the first place.

The one piece that doesn't go away: Debian's cloud images ship as qcow2, and Apple's Virtualization framework — like the vfkit tooling built on top of it — can't boot a qcow2 file directly, so it still needs converting to raw format first. That conversion step is the same tax Ubuntu's images carry; the cloud-init wiring is the part Debian's nocloud variant specifically removes.

What "download an official image" does here

Same value proposition as the Ubuntu image picker, applied to Debian's specific set of tradeoffs: choose "download an official image," pick Debian, and Velo Workspaces fetches it directly from Debian's own source, picks a variant suited to running as a local guest, handles the qcow2-to-raw conversion, and gets you to a running, logged-in workspace — rather than a choice between cloud image variants and a manual conversion step.

Networking: no Netplan, so the Ubuntu clone gotcha doesn't apply the same way

The Ubuntu post covers a specific, documented gotcha: a workspace cloned from a saved Ubuntu Server base image can come up without an IP address, because Ubuntu Server's Netplan configuration binds to the base image's original MAC address rather than matching by interface name, and every cloned workspace gets a fresh MAC. That failure mode is a Netplan-specific interaction, not a general "cloning a Linux VM" problem — and Debian doesn't default to Netplan. Debian's traditional networking still runs through ifupdown and /etc/network/interfaces, which identifies interfaces by name (eth0, ens3), not by MAC address, so the specific mismatch that traps a cloned Ubuntu Server workspace isn't the same trap here. Worth being precise rather than overclaiming: this makes that particular bug unlikely by default on Debian, not a guarantee that a cloned VM's networking can never need attention for other reasons — it's one specific, well-understood interaction that doesn't carry over, not a blanket "Debian doesn't have networking gotchas."

Rosetta, briefly

Debian uses the same apt and update-binfmts tooling as Ubuntu for registering Rosetta as a binary format handler, so the process is effectively identical between the two — mount the rosetta VirtioFS share, install binfmt-support, then register it with Apple's published magic bytes and mask. The exact commands are in the support FAQ; the same real-world caveat from the Ubuntu piece applies here too — Rosetta translates a single dynamically-linked binary well, but it doesn't conjure up x86-64 packages that were never built for arm64 in the first place.

Debian or Ubuntu, for this kind of workspace

Neither is a wrong choice for a disposable dev, QA, or DevOps workspace, and the differences are more about what you're optimizing for than any hard requirement. Debian's release cadence is more conservative — packages change less often, which is exactly what you want when the point of a base image is that it stays a known-good, unsurprising starting point for months. Ubuntu tends to have newer packages and broader out-of-the-box hardware/driver enablement work upstream, which matters more when you're following a guide or a CI config that specifically assumes Ubuntu's package versions. If you don't have a specific reason to need one, Debian's smaller default footprint and more conservative base make it a reasonable default for a workspace you're going to seal as a long-lived base image and reuse for months.

Related reading: the Ubuntu piece this one is paired with, Fedora on Apple Silicon — SELinux enforcing by default is the one to know about before it surprises you — the disposable VM workflow for QA and DevOps, and why VMs on Apple Silicon perform the way they do. Or download Velo Workspaces and try it yourself.