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 VM that you SSH into. It is the role of the machine that matters, not its form factor.

A workstation is often used to develop network software, but its role is to serve only your local user account, for testing and development. 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.

These roles matter 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. Otherwise, you will create unenviable new breeds: Sworkstations, Desktop Infrastructure, and Production Laptops. If you let a machine become a pet-with-ports, you may lose the ability to reason clearly about where it is deployed, what it contains, and who depends on it.

NixOS

Most Linux distributions are installed in a particular moment in time.

You begin with an installer, choose some packages, adjust a few settings, add repositories, copy in configuration files, and eventually reach a system that feels correct. A month later, you install one more tool. Six months later, you have forgotten why a service is enabled, which package provided a command, or whether a file in /etc came from you, the distribution, or an application that was feeling ambitious.

The machine works, but its configuration is no longer entirely described anywhere. It lives partly in package databases, partly in configuration files, partly in shell history, and partly in your memory. This is manageable for one machine – until it is not.

NixOS takes a different approach. Rather than treating the installed system as the source of truth, NixOS asks you to describe the desired system in code. Packages, users, services, fonts, desktop settings, kernel options, and much of the operating system itself can all be declared in config files. You describe the workstation you want; NixOS builds and activates it.

This is not magic. It is more like insisting that your computer keep its receipts. NixOS makes the entire system configuration reproducible by construction. It is similar to how Rust addresses memory safety: by making it mandatory to keep track of its ownership. NixOS makes it mandatory to track all of your configuration and package sources in a git repository, so that it is reproducible completely from a particular snapshot in time.

If you’ve ever programmed in JavaScript, you might be familiar with a file named package-lock.json. This file describes the exact version numbers of your application’s dependencies, and all of their dependencies recursively. This is for the integrity of your app, to make sure that when you install your app, you install the exact versions of the dependencies you need. NixOS does that too, but for the entire operating system!

A NixOS configuration can be stored in a Git repository, reviewed, copied to another machine, and rebuilt later. A new workstation does not need to become a fresh archaeological site where you rediscover every prior decision. Instead, it can start from the same configuration as your previous machine, with only the differences that its hardware or purpose require.

This makes NixOS especially useful for workstations. A workstation is personal, and personal configurations tend to accumulate. Your editor, shell, window manager, fonts, SSH settings, development toolchains, hardware quirks, command-line utilities, and small quality-of-life preferences all matter. On a conventional system, recreating that environment often means a long sequence of remembered installation steps. On NixOS, the goal is to make it an automated rebuild.

This system is designed around generations. When you change the configuration, NixOS builds a new system generation rather than mutating the current one in place. If the new configuration turns out to be wrong, inconvenient, or merely too clever, you can boot or switch back to an earlier generation.

This does not make mistakes impossible. It simply makes them less permanent.

NixOS is therefore a good fit for the kind of workstation described in this book: one that is clearly yours, reproducible from source, and safe to experiment with. You should be able to install a new machine, apply your configuration, and arrive at a familiar environment without performing a ritual reconstruction of your past self.

sway-home

This book is built around sway-home, which is EnigmaCurry’s personal NixOS configuration, packaged as a reusable library of modules: the Sway desktop and its companion programs (waybar, foot, rofi), a curated package set, shell and editor configuration, and the home-manager dotfiles that tie them together. Every machine you install depends on sway-home as a pinned flake input, so you get its defaults for free while keeping your own per-host configuration separate.

sway-home is used here as an opinionated base, not a finished product. It makes a particular set of choices – one person’s choices – so that the install has a concrete, working desktop to point at from the start. You are not expected to keep all of those choices. The intent is that you fork sway-home into your own copy and point your machines at it, then change the colors, swap the window manager, and add or remove programs to taste. Because the whole system is reproducible from source, such changes are deliberate, reviewable, and reversible.

This book is the evolution of my Fedora workstation

This book grew out of an earlier one: my Linux Workstation book, which documented the same goal – a personal, security-minded developer workstation – but built on Fedora Atomic (Silverblue/Sericea). That book leaned on rpm-ostree for an immutable base, distrobox for mutable toolchains, and a good deal of by-hand configuration of /etc, dotfiles, and packages.

It worked, but the configuration was never fully captured in one place. The system was the source of truth, and reproducing it on a new machine meant remembering and repeating a long sequence of steps. NixOS solves exactly that: the same workstation, but described entirely in code, so that a rebuild is automatic rather than archaeological.

I have since moved my own machines to NixOS, and the Fedora book is no longer maintained. The ideas there still hold – the Solokey hardware-key chapters in particular carry straight over, and this book links back to them rather than repeating them – but if you are starting fresh, start here.

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. When a command, an option, or a whole workflow shifts, 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.