Guide

Running NixOS on Apple Silicon

NixOS's whole pitch is reproducibility — a system described entirely in one declarative file. That makes it an interesting counterpoint to how this blog usually talks about reproducibility, which is base images and disk clones. Here's what's actually different about the arm64 download, and where the two approaches to "reproducible" actually diverge.

The aarch64 ISO is minimal-only — a real, current gap

Worth knowing before you go looking for the wrong thing: NixOS's official downloads offer both a minimal and a graphical installer ISO for x86_64, but only the minimal (terminal-only) ISO for aarch64 — there's no official graphical installer for Apple Silicon's architecture as of this writing. That's not a bug in your download, it's the current state of NixOS's own release infrastructure. The nix-community project publishes its own aarch64 installer images that fill part of that gap, unofficially. For a VM guest specifically, the minimal ISO is genuinely fine — you're installing over a text console either way for a headless or lightly-used workspace, and NixOS's actual configuration happens in a text file regardless of which installer put the base system there.

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

Like Kali and Arch, NixOS isn't part of Velo Workspaces' curated official-image list. Download the minimal aarch64 ISO from nixos.org yourself and use "choose a local OS image file" when creating the workspace. The installer walks you through partitioning and generates an initial configuration.nix for you, or you can supply your own from the start if you already have one.

Two different answers to "how do I get the same environment back"

This is the genuinely interesting comparison, not a gotcha: Velo Workspaces' own answer to reproducibility is a sealed base image — a disk-level snapshot you clone from, fast because it's copy-on-write, but opaque as a description of what's actually inside it (a display name is the only record you get, as that post covers in depth). NixOS's answer is the opposite shape: a configuration.nix file is a complete, human-readable, version-controllable description of the system — every package, every service, every setting — that nixos-rebuild can reproduce deterministically on any NixOS machine that reads it. One is fast and disk-based; the other is precise and text-based. They're not actually competing solutions to the same problem — a NixOS guest can use both at once, sealing a configured NixOS install as a Velo base image for fast day-to-day cloning, while the same box's configuration.nix stays the portable, readable record of what's in it, useful even outside Velo entirely.

What actually trips people up

The declarative model is also the thing that surprises people coming from an imperative distro: installing a package with nix-env outside of configuration.nix works, but it's a mutation the file doesn't know about — the next time you rebuild from the file, that ad hoc install is gone, because the file is the only thing NixOS considers the actual source of truth. That's a deliberate design choice, not a bug, but it catches people who reach for the familiar "just install it" habit from Ubuntu or Debian and expect it to stick the way apt install does.

Related reading: base images as versioned infrastructure, what a disposable development environment actually is, and Arch Linux on Apple Silicon, another distro on the local-file path. Or download Velo Workspaces and try it yourself.