Leave the next person a configuration.
Sometimes the next person is you, six months later.
Put the services a machine should run into its NixOS configuration. Keep host-specific settings separate from shared modules. Review a change before it becomes another unexplained difference between servers.
Upstream references (1)
A home server is a reasonable place to begin.
Choose one service you understand and one machine you can recover. Write down its configuration, data locations and backup procedure. Rebuild it in a test environment before relying on it.
The goal is a setup you can explain, not the largest possible collection of modules.
Test the system, not only the package.
The NixOS test framework can boot virtual machines and check how services behave together. A test can verify that a service starts and that another machine can reach it.
Use that before a deployment. It is more useful than discovering a missing dependency on the live host.
Upstream references (1)
The same approach fits a VM or a cloud host.
NixOS has VM and image-building workflows, and official images for Amazon EC2. The configuration model carries over; networking, storage and the provider’s recovery tools still need attention.
Upstream references (2)
Data is still your responsibility.
A system rollback does not undo a database migration. Keep backups and practise restoring them. Keep credentials out of ordinary Nix expressions that could place them in the store. Do not make remote changes without a recovery route.
NixOS gives you useful building blocks. Deployment approval, staged rollout and monitoring are policies you add, not promises that appear when you install it.