> but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.?
That is not true in the case of NixOS.
NixOS is an ordinary distribution: it has a release (which seems to be maintained for a year, receiving security patches) and an unstable branch.
So if you want to maintain your whole system in Nix, my recommendation is something like:
(1) use nix flakes. Flakes basically means you expressly specify the versions of your inputs, following the well known pattern of a human-edited but loosely specify source specification and a lockfile.
(2) One of your inputs will be github:NixOS/nixpkgs/release-21.05, which means the release-21.05 branch of github.com/NixOS/nixpkgs. The lockfile will ensure this follows the latest version
(3) In your flake, include your system configuration: it should build the whole system (systemd jobs, your reverse proxy, whatever it is you want each machine/class of machines in your network to do), not merely your application.
(4) In your flake, include your system tests. They can run on a virtual machine (or a network of virtual machines) whose configurations are derived from the configurations you created in (3).
If you've done that, you can now be reasonable confident that you can automatically receive security updates, run your tests against them, and deploy them.
That is not true in the case of NixOS.
NixOS is an ordinary distribution: it has a release (which seems to be maintained for a year, receiving security patches) and an unstable branch.
So if you want to maintain your whole system in Nix, my recommendation is something like:
(1) use nix flakes. Flakes basically means you expressly specify the versions of your inputs, following the well known pattern of a human-edited but loosely specify source specification and a lockfile.
(2) One of your inputs will be github:NixOS/nixpkgs/release-21.05, which means the release-21.05 branch of github.com/NixOS/nixpkgs. The lockfile will ensure this follows the latest version
(3) In your flake, include your system configuration: it should build the whole system (systemd jobs, your reverse proxy, whatever it is you want each machine/class of machines in your network to do), not merely your application.
(4) In your flake, include your system tests. They can run on a virtual machine (or a network of virtual machines) whose configurations are derived from the configurations you created in (3).
If you've done that, you can now be reasonable confident that you can automatically receive security updates, run your tests against them, and deploy them.