Arch vs NixOS as a Workstation: Professional and Personal Use

TL;DR I’ve run Arch and NixOS as my daily machine, and today it’s Arch on both desktops and NixOS on the servers. Arch’s reputation for breaking is mostly a missing snapshot. With btrfs, Snapper, dotfiles in git and a package list, a rollback takes 2 minutes and the fear of updates goes away. NixOS earns its learning curve when several machines have to stay identical, and on a server I wouldn’t run anything else.

The question I get most from people who already run Linux is which distro to put on the machine they work on. Arch or NixOS. They want a workstation they understand from top to bottom, and they’ve had enough of one that updates itself on someone else’s schedule.

I’ve run both as my real machine. Not in a VM, not for a weekend. As the laptop I do DevOps and platform engineering work on, and as the desktop I do everything else on. So you may as well know where I landed before you read on, because you’d have worked it out by the second table anyway. Arch on both desktops, NixOS on the servers. I’ve got reasons, and they’re more specific than “Arch is nicer”, so I’ll walk through them. The reasons are the useful part.

Both are good. Both have trade-offs I’ve felt on my own machine. Which one fits depends on your life more than on the software, and my life changed. I have kids now, so the Saturday afternoons I used to spend on a broken Xorg config don’t exist anymore. The machine has to work every time I open the lid. What surprised me is that Arch’s reputation for instability turned out to be mostly a skill issue, and that changed the whole comparison.

The one difference everything else hangs off

Arch is a blank canvas. You build the system piece by piece and you own every piece. It’s mutable, so you edit files, install packages, and the system drifts and grows over the years. Rolling release means you’re always on the current version of everything.

NixOS is declarative. You describe what the system should be in config files, and Nix builds exactly that. It’s mostly immutable. You don’t poke at the running system, you change the config and rebuild, and every change is reproducible.

That difference changes how you think about the machine. On Arch the system is something you tend. On NixOS it’s the output of a file you can read from top to bottom.

What I’m comparing on

For a working engineer with not much free time, four things decide this. Does an update land without breaking something. How fast do you get the package you need. How steep is the learning curve. And what it’s like to live in, day to day. I’ll split it into work and personal use, because the same trade-off comes out with the opposite sign depending on which machine you’re sitting at.

Arch at work

Standard Linux, first of all. Everything works the way the documentation says and your muscle memory from servers carries straight over. The packages are current. Need the latest kubectl, terraform or Go? It’s in the repos or in the AUR, usually within days of the release. And the AUR covers nearly everything else. yay -S slack-desktop spotify and you’re done. The Arch Wiki is the best Linux documentation I know, for any distro. And there are no abstraction layers. What you install is what runs.

Then the other side. Rolling release means things break now and then. A kernel update knocks out your WiFi driver. A library bump breaks one app. It happens. Nothing is reproducible, so “works on my machine” is a real sentence and your colleague can’t easily replicate your setup. It drifts. After a year you’ve installed so much that you’ve forgotten what’s there or why. And there’s no rollback unless you set one up yourself, so an update that breaks something gets fixed by hand.

I ran Arch for work for years. Early on I lost time to breakage every few months. Then I worked out that most “Arch is unstable” complaints, mine included, came from running it without a safety net. With the right setup it has held up for me since. The next section is that setup.

Making Arch survive an update

Since the kids arrived I have zero tolerance for a broken laptop during work hours. My answer was to treat Arch as semi-ephemeral. The machine is allowed to die at any moment, and I should be productive again within minutes. It’s the same resilience thinking I apply to infrastructure, pointed at my own laptop. I stopped trying to prevent failure and made recovery cheap instead.

The stack:

• Btrfs with Snapper. A snapshot before every pacman transaction. Something breaks? snapper rollback and reboot. Done.
• Timeshift with rsync if you’re not on btrfs. Similar protection, less elegant.
• Dotfiles in git. My whole config lives in a chezmoi repo. Fresh install? chezmoi init --apply and my environment is back.
• A package list in the same repo. pacman -Qqe > pkglist.txt going out, pacman -S --needed - < pkglist.txt coming back.
• A separate /home. It survives a reinstall, so my data does too.
• Full backups. Borg to my NAS, daily. Worst case, I restore everything.

That gives me three recovery options:

1. Minor issue. Snapper rollback, 2 minutes.
2. Major issue. Fresh install, then dotfiles, then the package list, 30 minutes.
3. Dead hardware. New machine plus a backup restore, 1 hour.

I stopped fighting the rolling release model and leaned into it. Updates might break things, so I made breaking things cheap. Once a rollback takes 2 minutes, an update stops being scary. I update weekly now. If something breaks I roll back and wait for the fix. No debugging session, no awkward message to a client about why I’m late.

NixOS at work

Your configuration.nix describes the whole system. Clone the repo, run nixos-rebuild, get the same machine. Every generation is kept, so a bad update means booting the previous one from the boot menu. Two seconds. Installed packages are in the config, so there’s no drift and you always know what’s on the box. nix-shell and devenv give every project its own dependencies without touching the system. And experimenting costs nothing, because whatever you break, you roll back.

The price is the learning curve. The Nix language is its own thing, the documentation is famously thin, and the first weeks are rough. Nixpkgs is huge but more conservative than Arch, so you can wait weeks for the latest version of something. The mental model is different too. You can’t apt install and move on, you have to think declaratively. All those generations take disk space, and /nix/store gets big. And some things are plain harder. Proprietary software, anything with a non-standard layout, anything that assumes FHS, all of it needs extra work.

I switched to NixOS for work after one Arch breakage too many. The first month hurt. Learning Nix, rewriting my config, fighting odd package issues. After that it held. Updates never broke anything, and I could run nixos-rebuild switch on a Friday afternoon without thinking about it. When I got a new laptop, my complete environment was running in under an hour.

What I’d say for work

Where a broken machine costs real money, NixOS’s reliability is hard to argue with. The catch is the learning time. If you need to be productive tomorrow and can’t spend a week on Nix, Arch gets you working sooner.

So the question is what downtime costs you. If a broken system means a missed client meeting or a late deploy, the Nix learning curve pays for itself. If you can absorb the occasional troubleshooting hour, Arch’s familiarity wins. And here’s what complicates the clean answer. Once I had the snapshot and backup discipline above, my Arch downtime dropped to about what NixOS gave me, without the week of learning Nix. That’s what tipped me back.

Arch at home

Here the trade-off comes out the other way.

On a personal machine, tinkering is the point. Arch makes you understand your system because you built it. Gaming wants the newest Mesa drivers and creative work wants the newest GIMP, and Arch has them first. The AUR has the obscure Japanese rhythm game and the weird hardware tool, because Arch users package everything. The forums are active and helpful, once you’ve learned to read the wiki first. And it’s fun. There’s real satisfaction in a system built exactly how you want it.

The cons are the same as at work. They sting less when it’s your own machine and nobody’s waiting on you.

NixOS at home

Home-manager gives you declarative dotfiles, so your whole user environment sits in config files. Flakes make those configs reproducible and composable. Your NixOS config can be a public repo that other people learn from and send patches to. And if you’ve got a laptop and a desktop, one config keeps them identical.

What you give up is the tinkering. Everything goes through Nix. You can’t grab a binary and run it, which is great for reliability and rough on the “let me just try this” itch. Gaming is more work. Proton and Steam run, but Lutris and the various launchers all want Nix wrappers. And there’s the rabbit hole. You’ll spend more evenings perfecting configuration.nix than using the computer.

What I’d say for home

For personal use I prefer Arch, and here I don’t have to argue with myself. The tinkering is the hobby. The occasional breakage is part of the fun. For gaming and random software, Arch’s flexibility beats Nix’s purity.

If you run the same config across several personal machines, or want your personal and work setups identical, the declarative model is strong enough to change that. For me, with one desktop, it doesn’t.

What I run today

The work laptop is Arch with btrfs and Snapper. With the snapshot discipline it has been solid, I get current tools without waiting on nixpkgs, and recovery from anything is minutes away. The personal desktop is also Arch, same setup. Gaming works better than it did on NixOS, and the AUR has everything I want. The homelab servers are NixOS. For a server, declarative config wins outright. I rebuild any of them from git, and nothing drifts because nothing can.

So the pattern is Arch for the machines I sit at, NixOS for the ones I don’t. On a desktop I want the familiar Linux, the package the day it’s released, and the freedom to download something and run it. Snapshots and backups take care of the instability. On a server I want reproducibility and infrastructure as code, and a server doesn’t need the newest packages or the gaming support that make Arch worth it on a desktop.

Side by side

Package availability

System administration

Development workflows

Who should pick what

Pick Arch if:

• You want to learn Linux deeply
• You value simplicity and transparency
• You don’t mind occasional troubleshooting
• Gaming is important
• You prefer imperative “just do it” workflows

Pick NixOS if:

• Reliability is critical (work machine)
• You manage multiple machines
• You want reproducible environments
• You like declarative configuration
• You’re willing to invest learning time upfront

Pick both if:

• You have multiple machines with different purposes
• You want stability for work and freedom for personal

Where I landed

There’s no universal answer, and I’ve been happy on both for different reasons.

Arch taught me how Linux works, because I had to set up every component and every config file myself. NixOS taught me to think declaratively, with every change in a file and every experiment reversible. Both lessons stuck.

The one that changed my workstation choice is simpler. Arch’s instability is solvable. The people who say Arch breaks constantly are usually running it without snapshots and without a recovery plan, and I did that for years. Give it that safety net and it’s as reliable as anything I’ve run, with current packages and familiar tooling on top.

Having kids gave me less time to tinker. I expected that to push me onto NixOS for everything. Instead it pushed me to make recovery cheap. Snapshots, dotfiles in git, a package list and backups are what made the rolling-release fear go away.

If you’re eyeing Arch but worried about stability, build the recovery setup first. Btrfs and Snapper take an afternoon, and mine has paid for itself several times over. Then update. And for servers I’d still pick NixOS every time, because a server should be rebuildable from git and from nothing else.

• Linux
• NixOS
• DevOps
• Desktop