[matrss]

> [...] and I'd wager (naively) that most NixOS users at some point need to use an escape hatch.

I don't think that is the case. In five years of using NixOS I never needed to reach for any of them, and I don't even know what would be available to me. Probably something about activation scripts? Again, I can't think of anything you might want to do with regard to system configuration that can't be done declaratively on NixOS.

[h0l0cube]

Fair enough. It could be that good. Is this use for commercial purposes? Do you have to interface with legacy systems or unusual stacks?

[matrss]

Mostly private use, I have 2 servers and a laptop configured with this: https://github.com/matrss/nixfiles. The servers host a bunch of different services from Nextcloud to a DoT-to-ODoH proxy and some more.

I've also introduced some light NixOS usage at work (3 hosts, one is an uptime-kuma instance, two are Forgejo Actions runners). For that I had to get some proprietary scanner software to run on it, which I could by just putting the extracted deb package in an emulated FHS environment and setting up a service for it, all declaratively.

Even for interfacing with legacy systems and unusual stacks I don't think you will need the escape hatch. Anything that is buildable on and above the abstraction-level of "ensure a file is present at some path with some content" should be doable declaratively, and that includes setting up an unusual software stack and running it in systemd services to communicate with some other legacy system or whatever.

The escape hatch is there to modify how NixOS itself behaves, and modifying that should only be necessary to extend NixOS' core functionality. A quick search revealed that impermanence (https://github.com/nix-community/impermanence) and in some cases sops-nix (https://github.com/Mic92/sops-nix) use it, but those fundamentally extend NixOS with ephemeral root storage support and secrets management, respectively.