Native arm64, and only arm64 now

Fedora on an Apple Silicon Mac runs the same way Ubuntu and Debian do — natively on arm64, no emulation. Fedora Linux 44, the current release as of this writing, ships for two architectures: x86_64 and aarch64. Fedora dropped 32-bit ARM (armhfp) support entirely some releases back, so on ARM specifically it's aarch64 or nothing — one fewer variable to get wrong when picking an image, at least.

The default that actually surprises people: SELinux, enforcing, out of the box

This is the one worth leading with, because it's genuinely different from both Ubuntu and Debian and it's the kind of thing that costs someone an hour of confused debugging the first time they hit it. Fedora ships SELinux in enforcing mode with the targeted policy by default — not installed-but-inactive, actually enforcing. A service that binds to a nonstandard port, reads from an unexpected directory, or gets restarted by a script in a way its policy doesn't anticipate can fail with what looks like a permissions error, on a system where the file permissions are completely correct. Neither Ubuntu nor a typical minimal Debian install puts you in that situation by default in the same way.

The practical implication isn't "turn SELinux off" — it's "know it's there before something fails mysteriously." When a service misbehaves on Fedora for no visible reason, checking journalctl for an AVC denial, or running sealert against the audit log, is a genuinely different first debugging step than the one Ubuntu or Debian would usually call for, and it's worth having in mind specifically because it doesn't come up on the other two distros in this series.

Two networking stacks, depending which image you actually start from

Fedora doesn't have one networking default — it has two, and which one you get depends on which edition's image you pick. The Fedora Cloud Base image uses systemd-networkd: minimal, no extra package weight, straightforward config files, the kind of setup you'd expect from an image built specifically for booting fast in a VM. Fedora Server Edition, by contrast, persists its network configuration through NetworkManager, consistent with Fedora's other editions and with more features for things like VPN tunnels you're unlikely to need in a disposable workspace. For a fast-booting, disposable base image — the pattern this blog has covered for QA and DevOps workflows — Cloud Base's systemd-networkd setup is the more natural starting point. Neither of Fedora's two stacks hits the specific Netplan/MAC-address clone bug documented for Ubuntu Server — that failure mode is genuinely Netplan-specific — but it's still worth knowing which of the two you're on before you go looking for a config file, since the two use different ones.

Rosetta: a different mechanism, not just different commands

This is a real architectural difference, not a cosmetic one. Debian and Ubuntu both register Rosetta as a binary-format handler through update-binfmts, a management tool that wraps the underlying kernel mechanism. Fedora doesn't ship update-binfmts at all — it uses systemd-binfmt instead, which reads the exact same kernel binfmt_misc registration directly from a config file you write yourself, rather than through a tool that manages entries for you. Same end result — the kernel recognizes and hands off x86-64 binaries to Rosetta the same way either path — but the mechanism you're actually interacting with is different, and the support FAQ has Fedora's exact steps (mount the rosetta VirtioFS share, write /etc/binfmt.d/rosetta.conf, restart systemd-binfmt) separately from Debian's, because the two really don't share tooling here despite doing the same job.

The cloud image, briefly

Same value proposition as the other two posts in this series, so briefly: Fedora's official cloud images ship as qcow2 and still need converting to raw for Apple's Virtualization framework, the same tax as Ubuntu's and Debian's images carry. One small additional Fedora-specific detail worth knowing — recent Fedora Cloud images default to Btrfs rather than ext4, with a dedicated subvolume for /home, which is a different assumption than either of the other two distros in this series ship by default. "Download an official image" in Velo Workspaces handles the fetch and the conversion either way, so this is background rather than something you need to plan around.

When Fedora actually makes sense for this kind of workspace

Fedora tracks upstream far more closely than Ubuntu or Debian — newer kernel, newer package versions, features landing here well before they reach either of the other two. The tradeoff is a support window measured in roughly a year per release rather than Ubuntu's multi-year LTS window or Debian's conservative stable cycle, which matters less for a disposable workspace you rebuild from a base image regularly than it would for a server you patch in place for years. Reach for Fedora specifically when you need to test against genuinely current upstream package versions or kernel features; reach for Debian when you want the base image itself to be the boring, unsurprising part of the workflow for months at a time; reach for Ubuntu when you're following tooling or CI configuration that specifically assumes it.

Related reading: Ubuntu on Apple Silicon and Debian on Apple Silicon, the first two in this series; the disposable VM workflow for QA and DevOps; and why VMs on Apple Silicon perform the way they do architecturally. Or download Velo Workspaces and try it yourself.