Introduction
What is a workstation?
If a server is a machine whose role it is to serve applications to many people over a network, a workstation is a machine whose role it is to serve a local operator stationed at the computer.
A Linux workstation is therefore a personal computer that you use for “work”: development, administration, writing, research. Your workstation might be a desktop computer, a laptop, or even a headless box that you SSH into. It is the role of the machine that matters, not its form factor.
Your workstation may be connected to a broader network, but it is primarily a client: a terminal, web browser, editor, and control panel for other systems – not a server for a wider audience. That distinction is worth defending, for both security and data hygiene. The two rules are simple: never keep production data on your work machine, and never work directly in production.
Bend those rules however you like, but do so knowingly. A machine that quietly becomes a pet-with-ports costs you the ability to reason clearly about where it is deployed, what it contains, and who depends on it.
Why Arch Linux
Arch installs a base system and then stops. There is no distribution layer sitting between you and the software you run: packages are built close to upstream, defaults are upstream’s defaults, and nothing is configured on your behalf. The practical consequence is that everything you read about a piece of Linux software applies to your machine literally rather than approximately – including the Arch Wiki, which is the best operating system documentation anyone is currently writing, and which assumes exactly the system you are about to build.
It is a rolling release, so there are no version upgrades to schedule
and no six-month cliff where everything moves at once. pacman is
fast and legible, and pacman -Qe will tell you the complete list of
packages you explicitly asked for – which turns out to be most of
what you need in order to rebuild a machine.
What Arch does not give you is any guarantee that two machines built from the same instructions are the same machine. The running system is the source of truth, it drifts, and nothing but your own discipline records how it got that way. That is the real trade, and it is the one this book is organized around.
The sibling NixOS Workstation book takes the opposite position: the configuration is the source of truth and the running system is built from it, which buys reproducibility at the price of an indirection layer between you and every upstream manual. Neither answer is wrong. Pick the one whose failure mode you would rather live with.
This book is literate, not declarative
Because Arch has no mechanism that captures a machine’s configuration for you, this book supplies the next best thing: it is the install, written out in order, with the reasoning next to each step.
Every command in these pages is a copy-pasteable block. They are meant to be run as whole blocks, top to bottom, in the order they appear. Where a step can safely be run twice, it is written so that it can be. Where it cannot, the book says so.
Blocks also tell you where to run them. Three machines are in play during an install, and confusing them is the easiest way to have a bad afternoon:
| Machine | What it is |
|---|---|
| your workstation | The computer you are already sitting at, running your editor and SSH client. |
| the live system | The target machine booted from the BOOMSTICK, running in RAM. |
| the target | The system being installed, mounted under /mnt until it boots on its own. |
Configuration values that several steps need are carried between blocks in ordinary shell variables, set in their own blocks, so that you fill in a hostname or a disk path once rather than editing it into a dozen commands.
Following this book again on another machine reproduces the steps, not the bytes. Packages will have moved on, and nothing here verifies that the result matches a previous build. That is weaker than a pinned flake and considerably stronger than memory. Keep your own copy of the commands you actually ran – the ones where you chose differently than the book did – because that file is the only record of your machine that will exist.
What you end up with
The core of this book builds a minimal, headless base system: a
partitioned and formatted disk, a bootloader, networking, your user
account, SSH, sudo, and enough pacman hygiene to keep the machine
maintainable. That base is deliberately the same work on a desktop PC
as on a Raspberry Pi, and it is a perfectly good stopping point if
what you wanted was a small server.
The graphical desktop comes later, as its own optional chapter, built on top of that base.
You start from a BOOMSTICK
This book begins at the moment you have a root shell on the target machine over SSH, with no monitor or keyboard attached to it. BOOMSTICK is how I get there: an Arch live USB that joins my WiFi, brings up a WireGuard tunnel to my own server, and lets me in over SSH with my own keys – so the target machine needs nothing but power and a USB port, and the install is driven from my own desk. The appendix explains how to build one and fill it in.
BOOMSTICK is a convenience, not a requirement. If you boot the official Arch Linux ISO with a monitor and keyboard attached and work at the console, everything after this chapter is identical – the only thing BOOMSTICK changes is how you get that root shell.
Hardware this book covers
- x86_64 PCs, booting UEFI. Legacy BIOS is not covered.
- Raspberry Pi 5, which is the same work with a different bootloader and kernel. Where the two architectures diverge, the book says so in place rather than sending you to a separate chapter.
“Arch Linux” officially supports x86_64 only. On the Raspberry Pi the distribution you are actually installing is Arch Linux ARM, a separate community project that tracks Arch with its own mirrors and its own package set, and the Pi 5 runs the Raspberry Pi Foundation’s kernel rather than a generic arm64 one. It is close enough that the Arch Wiki remains useful, and far enough that some packages simply do not exist there.
Linux on Apple Silicon should work on the same aarch64 footing, but I have not tested it, and nothing in this book should be taken as a claim that it does.
Where this book sits among the others
- NixOS Workstation – the same goal, built declaratively. If you want the machine described in code and rebuilt from that description, read that one instead.
- Linux Workstation – an older, archived book covering the same ground on Fedora Atomic. It is no longer maintained, but its Solokey hardware-key chapters carry over to any distribution.
This book is written with AI
I write this book with the help of AI, and I would rather say so plainly than pretend otherwise. If that bothers you, that is fine – I am not writing for that objection.
I do it because it makes the book a malleable product. The hard part of documentation has never been producing prose; it is keeping the prose true as the system underneath it changes. On a rolling release that pressure is constant: commands, package names, and defaults move under you. AI lets me revise the affected chapters quickly and keep everything consistent, instead of letting pages quietly rot. A book that is cheap to update is one that stays correct.
What matters here is the information and the flow: that the steps are accurate, that they are in the right order, and that the reasoning behind them is clear. Hitting a particular literary tone or vibe is not the point. I review what goes in, the decisions and the setup described are genuinely mine and what I run, and the goal is simply that you can follow it and end up with a working machine.