Can NixOS Modules Be Tested In‑Place Without Production Secrets?

Direct Answer

Yes. A NixOS module can be applied and validated in a sandbox that references only local configuration files, provided you import only the module under test, supply dummy values for any secret‑backed options, and avoid importing /etc/nixos/secrets or external secret backends.

Minimal Local configuration.nix Snippet

{ config, pkgs, ... }:
{
  imports = [ ./module-under-test.nix ];

  # Required boilerplate so the evaluator does not fall back to host config
  networking.hostName = "test-host";
  networking.hostId = "00000000";
  boot.loader.grub.enable = false;
  fileSystems."/" = { device = "none"; fsType = "tmpfs"; };

  # Enable the module and stub every option that would read a secret file
  services.myModule = {
    enable = true;
    # Replace secret‑backed options with inline dummy values
    configFile = "";
    apiKey = "test-key";
    # If the module expects a path, point it at a local stub file
    secretPath = ./stubs/secret.txt;
  };
}

Place this file alongside module-under-test.nix and a stubs/ directory containing any placeholder files the module reads at evaluation time. Do not copy production secrets into the stub directory; doing so would violate the no‑production‑secrets constraint and could leak credentials into the Nix store.

Service Activation and Reboot Reality

nixos-rebuild switch builds the new system generation, updates the bootloader (if enabled), and activates systemd units via systemctl daemon-reload plus start/restart for changed units. It does not guarantee that every service reflects the new configuration without a reboot when:

• The module modifies kernel parameters, initrd, or early‑boot units.
• A service’s systemd unit definition changes in a way that systemd cannot hot‑reload (e.g., ExecStartPre scripts, Type=notify changes).
• Long‑running processes hold open file descriptors to old configuration files.

For modules that only manage user‑space daemons with standard systemd reload semantics, switch is usually sufficient. When in doubt, run systemctl status <unit> and journalctl -u <unit> after the switch; if the unit shows stale state, restart it manually or reboot.

Flake vs. Classic Evaluation

Aspect	Classic (nixos-rebuild switch)	Flake (nixos-rebuild switch --flake .#host)
Input source	Channel or NIX_PATH (mutable)	Locked flake.lock (immutable)
Determinism	Can drift when channels update	Reproducible as long as lockfile is unchanged
Secret handling	Same risk: any import /etc/nixos/secrets pulls production data	Same risk: flakes do not auto‑sanitize secret imports
CLI availability	All NixOS versions	Requires Nix 2.4+ with nix-command and flakes experimental features enabled

For test determinism, prefer the flake path with a pinned nixpkgs input. If the target environment lacks flake support, pin a specific channel revision (e.g., nixos-24.11) via NIX_PATH to achieve comparable stability.

Verification Checklist

1. grep -r "/etc/nixos/secrets" . — confirm no production secret references exist in the test tree.
2. Run nixos-rebuild build --flake .#test-host (or classic nixos-rebuild build) and inspect the generated unit files under ./result/systemd-units/ or /run/current-system/system/ after activation.
3. Activate with switch, then systemctl status <your-module-service> and journalctl -u <your-module-service> -n 50.
4. If the service shows stale configuration, systemctl restart <your-module-service>; reboot only if the module touches bootloader, kernel, initrd, or early‑boot units.
5. Repeat the build with and without --flake (using a pinned nixpkgs for classic) and compare nix show-derivation outputs to confirm deterministic results.

One Missing Diagnostic Detail

Does the module under test read secret files at evaluation time (inside the Nix expression) or only at runtime (via a systemd EnvironmentFile or similar)? Evaluation‑time reads will cause the build to fail unless you provide stub files; runtime reads can be satisfied with dummy unit overrides. This distinction changes whether you need stub files in ./stubs/ or can rely solely on inline option overrides.