The fact that changes everything else in this post

Arch Linux's own official port targets x86_64 only — there is no official arm64 build of Arch Linux itself. What runs on aarch64, including on Apple Silicon, comes from Arch Linux ARM, a separate, community-run project at archlinuxarm.org with its own maintainers and its own build infrastructure, closely affiliated with Arch but not the same project shipping the same official artifact the way Ubuntu, Debian, and Fedora's arm64 builds are. This isn't a knock on Arch Linux ARM's quality — it's a real, actively maintained project, and in July 2026 Collabora even used it as the base for an official Arch-derived arm64 port for Valve's Steam Frame headset. It's an accuracy point worth having going in: what most people mean by "Arch Linux on Apple Silicon" is Arch Linux ARM specifically, a related but distinct project from the one you'd be thinking of on x86.

Rolling release removes one question, and raises another

Ubuntu, Debian, and Fedora all made this series answer "which release is current." Arch sidesteps that entirely — there's no version number, just a continuously updated package set, so "which release" isn't a question you have to think about. The tradeoff it introduces instead is well documented on Arch's own wiki: a partial upgrade — installing or updating an individual package without fully syncing the system first — is explicitly unsupported and a real source of breakage, because Arch doesn't maintain compatibility between arbitrarily-old and arbitrarily-new package versions the way a point-release distro does between patch levels. Not a reason to avoid it, just the specific discipline rolling release actually asks of you in exchange for always-current packages.

Picking the right image is a bigger deal here than for the other three

Ubuntu, Debian, and Fedora each publish one obvious generic cloud/VM image. Arch Linux ARM's downloads are organized by target hardware platform instead — plenty of them built for specific single-board computers with SBC-specific kernels and bootloaders that won't boot correctly in a generic VM at all. The one that's actually meant for this use case is specifically the "Generic AArch64" build, not any of the Raspberry Pi or other board-specific images on the same downloads page. Grab the wrong one and you won't get a subtly-different environment — you'll get a kernel built for hardware you don't have, and it won't boot.

No official-image picker here — you're on the local-file path

Unlike Ubuntu, Debian, and Fedora, Arch Linux ARM isn't in Velo Workspaces' curated "download an official image" list, consistent with it not being a first-party arm64 build of a major distro the way the other three are. The workflow is still straightforward, just one step less automated: download the Generic AArch64 image from archlinuxarm.org yourself, then use "choose a local OS image file" (or "boot from an existing virtual disk") when creating the workspace, instead of the one-click fetch-and-convert flow the other three posts in this series describe. You lose the automatic download step; you don't lose anything about how the workspace itself runs once it's booted.

Nothing is configured for you, starting with networking

This is the real, practical difference from every other distro in this series, and it's worth knowing before you're staring at a workspace with no network rather than debugging a specific gotcha. Arch's minimal install profile has no network management dependencies at all — no NetworkManager, no systemd-networkd enabled, nothing — by design, on the philosophy that Arch configures as little as possible for you and leaves the choice explicit. Fedora surprises people with something unexpected turned on (SELinux enforcing); Arch is the opposite failure mode — nothing is turned on, including the thing you need most immediately to do anything else. Enable a network stack yourself before you do anything that needs the internet:

sudo systemctl enable --now systemd-networkd systemd-resolved

That's the minimal, sufficient choice for a VM guest specifically — no wifi to manage, no need for NetworkManager's broader feature set, just a wired virtio-net interface that needs a DHCP lease.

When Arch actually makes sense for this kind of workspace

Reach for it when you specifically want the newest possible packages and kernel with no distro-imposed release cadence, and you're genuinely comfortable configuring a minimal base yourself — that's real time cost, not a one-time inconvenience, since a fresh install gives you close to nothing pre-set. Every setting in the guest OS performance tuning post — scheduler, TRIM, swap, filesystem mount options — is entirely on you here, with no distro defaults to start from either direction. If you want a distro's own official, tested arm64 build with a foundation or company actually standing behind that specific artifact, Ubuntu, Debian, or Fedora are the steadier choice, specifically because they're the primary project's own port rather than a satellite one.

Related reading: Ubuntu, Debian, and Fedora on Apple Silicon, the first three in this series; the disposable VM workflow for QA and DevOps; and guest OS performance tuning once you're up and running. Or download Velo Workspaces and try it yourself.