NixOS (1): Why I Chose NixOS Again Now

I first tried NixOS about four or five years ago. The idea sounded useful: write the software and system settings in configuration files, keep them in Git, reuse them on another computer, and return to an older system when an update goes wrong.

Writing the configuration took a fair amount of time. Nix differed from the configuration formats I had used before, and services, drivers and user settings required looking up the relevant options and examples. Online tutorials could also use syntax from a different version. Since I was spending too much time on configuration, I stopped using NixOS and continued using Fedora on my main computers.

Recently I started using NixOS again, mainly because AI can now help with the configuration. Coding assistants such as Codex and OpenCode can read the repository, edit Nix files and run checks. I can ask the assistant to look up an option and propose a change, then review what it found.

AI-generated configuration still needs checking. With NixOS, the changes are stored in files: I can review the diff, build the configuration and then apply it. This makes it convenient to check which packages and settings a change affects.

I therefore moved several computers from Fedora to NixOS. This series records the configuration methods I developed during the migration and everyday use, for future reference and for friends who would like to try NixOS.

Main Uses of NixOS
#

Configuration management across computers
#

With one computer, installing packages and editing configuration files by hand is usually manageable. With several, it becomes easier for the settings to drift apart. I might finish setting up the shell on one computer and then need to repeat it on another. After a setting has worked for months, it can also be difficult to remember how it was configured when reinstalling the system.

I already kept some configuration in Git, such as my shell setup. That covered part of the work, but packages, system services and firewall settings still needed separate attention.

NixOS lets me describe those too. The common parts can be shared, while hardware and other differences stay in each computer’s configuration. A shared change then only needs to be written once. Post 3 will explain how to arrange the files.

System updates and rollback
#

After using Linux for a while, you will probably encounter an update that breaks a program or a driver. NixOS keeps system generations. As long as an older generation is retained, you can select it at boot or roll back to its configuration.

This is useful when testing configuration and updating software. However, it restores system software and configuration; it does not restore earlier versions of databases, downloaded files or documents in your home directory. Data backups are still needed.

Configuration and change records
#

With configuration in Git, I can see what changed and why. A few notes alongside it make it easier to set up another computer or return to something I last worked on months ago.

This also helps the AI assistant. A new conversation does not automatically remember the previous work, but the assistant can read the repository and its documentation again. It is much easier to continue when the configuration, changes and actual results have been recorded.

Using AI to Help Maintain Configuration
#

During the migration, AI helped find configuration options, organize repeated settings, explain build errors and update instructions from the files already in the repository. I need to specify the required functionality and which computers need those settings.

For example, “add remote desktop” could mean sharing a desktop that is already logged in, or being able to use a computer without a monitor. Those are different requirements. Along with the software name, I therefore need to explain how it will be used.

After the configuration passes its checks, its behavior also needs to be verified: for example, whether the service starts, clients can connect, and the feature works after a reboot. Post 4 explains how I put those requirements into maintenance instructions; post 5 follows a change through to a running system.

Migration Scope
#

The first group of computers was migrated in August and early September 2026: a daily-use laptop, a desktop for local AI and gaming, and a computer running self-hosted services. I will use these experiences as examples, but most of the series does not depend on a particular model.

Besides the operating system, the work included:

Managing the user environment with Home Manager, including the shell, editor, input method and some desktop settings;
Keeping several computers’ configurations in one flake;
Managing service passwords and keys without putting plaintext in Git or the Nix store;
Configuring native services and Docker containers, including their networking and storage;
Updating systems, checking the results and recovering when something goes wrong.

The examples use generic names and paths rather than publishing private configuration. Basic Linux commands and Git are enough to get started; I will introduce the NixOS concepts as they come up.

Series Contents
#

The series mainly introduces configuration methods that can be used across computers. The current outline has thirteen topics; individual posts may be combined or split as the material develops.

Why I chose NixOS again now (this post)
Core concepts: declarations, the Nix store, flakes, locked inputs and generations
Repository architecture: common settings, each computer’s configuration and where to keep the files
Maintaining configuration with AI: explaining the task, checking changes and recording results
The lifecycle of a change: evaluation, build, test, switch, boot, rollback and garbage collection
Understanding NixOS modules: imports, options, defaults, priorities and overrides
Choosing where software belongs: system packages, Home Manager, temporary shells and project development environments
Managing the user environment: dotfiles, desktop preferences, existing files and mutable settings
Secrets and trust boundaries: store visibility, runtime secrets and decryption identities
State, backups and recovery: what configuration can reproduce, what needs a backup and how to test restoration
Services, containers and networking: native modules, container boundaries, dependencies, storage and access
Updates and deployment across computers: input review, build resources, staged rollout and remote verification
Lessons from maintaining NixOS with AI: useful assistance, recurring mistakes and the checks that made the results trustworthy

Hardware support, local AI deployment and individual service migrations can become optional companion articles. Within the main series, experience provides examples for the concepts. Public examples are purpose-written and omit private configuration details.

Continue to post 5: the lifecycle of a NixOS change for a practical walkthrough.

Motivation#

Main Uses of NixOS#

Configuration management across computers#

System updates and rollback#

Configuration and change records#

Using AI to Help Maintain Configuration#

Migration Scope#

Series Contents#

Related Posts#

Motivation
#