Step by step, with screenshots: install NixOS with the graphical installer, then turn on SSH in configuration.nix.

Minimal or graphical, both for aarch64

NixOS publishes a minimal (terminal-only) and a graphical installer ISO for aarch64 as well as x86_64. Velo Workspaces 1.2 has both, for NixOS 26.05 and 25.05, downloaded from nixos.org and checked against the published SHA-256. For a VM the minimal ISO is usually enough, because NixOS's configuration lives in a text file whichever installer put the base system down.

NixOS's aarch64 ISO is built to boot from a CD, and Apple's Virtualization framework has no CD drive, only USB-style disks. Velo Workspaces gives its own copy of the ISO a partition table the firmware can boot from, leaving the NixOS volume and its label untouched, so the installer starts normally. Why Fedora's ARM ISO wouldn't boot tells the story of the black screen NixOS showed before this, and why the same fix covers both.

Installing: by hand, the NixOS way

The NixOS installer has no answer-file mechanism, so there's no automatic install. Create a workspace with Installer image, pick NixOS, and when it boots, partition the disk, run nixos-generate-config, edit configuration.nix and run nixos-install, following the NixOS manual. If you already keep a configuration.nix in git, you can start from that. When the installed system has booted, click Installation Complete in the banner at the top of the workspace. After a manual install the app can't tell on its own that you're done, so until you click, it keeps attaching the installer and keeps the Large Text display scaling that makes the installer readable. Stop and start the workspace once afterwards to switch to its own display setting.

For SSH, enable services.openssh and add this Mac's public key (copy it from Settings › Access) to users.users.<name>.openssh.authorizedKeys.keys. The Install Key button the built-in terminal offers after a password sign-in works too, but it writes to ~/.ssh/authorized_keys, which your configuration doesn't know about. Putting the key in the file keeps it where NixOS expects everything to be.

Two answers to "how do I get the same system back"

Velo Workspaces' own answer to reproducibility is a saved base image: a disk-level copy you clone from. It's fast, because clones are copy-on-write, but it's opaque as a description of what's inside; its name is the only record you get. NixOS's answer has the opposite shape. configuration.nix is a complete, readable, version-controlled description of the system (every package, service and setting) that nixos-rebuild reproduces the same way on any NixOS machine.

One is fast and disk-based, the other precise and text-based, and a NixOS workspace can use both. Save a configured install as a base image for quick day-to-day clones, and keep its configuration.nix as the portable record of what's in it, useful even outside Velo Workspaces.

What trips people up

The declarative model is also what surprises people coming from other distributions. Installing a package with nix-env outside configuration.nix works, but the file doesn't know about it, and the next rebuild doesn't include it. The file is the only source of truth NixOS recognizes. That's a deliberate design choice, and it catches anyone who reaches for the familiar "just install it" habit and expects it to stick the way apt install does.

Related reading: base images as versioned infrastructure, what a disposable development environment is, and Arch Linux on Apple Silicon, another distribution you install by hand. Or download Velo Workspaces and try it yourself.