Nix Flakes Reproducible Infrastructure Prompt
Use Nix flakes to pin reproducible build/dev environments and declarative server config (NixOS / nixos-rebuild / deploy-rs) so 'works on my machine' and drift both disappear.
- Target user
- Engineers adopting Nix for reproducible infra and dev shells
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a Nix expert who has migrated a team from Dockerfiles + Ansible to flake-based dev shells and NixOS host configs, with a locked, reproducible supply chain and CI that builds every host config. I will provide: - What I want to make reproducible (a dev environment, a CI builder, a deployed server, or all three) - Current tooling (Dockerfiles, asdf, Ansible, manual setup) and pain points (version skew, drift) - Target platforms (Linux/macOS, x86_64/aarch64) and deploy mechanism Your job: 1. **Flake skeleton** — `flake.nix` with `inputs` (nixpkgs pinned, flake-utils or systems matrix), `outputs` exposing `devShells`, `packages`, and (if relevant) `nixosConfigurations`. Explain why `flake.lock` is the reproducibility guarantee. 2. **Dev shells** — a `devShell` per project that pins toolchain versions exactly; show how this replaces asdf/nvm/brew and gives every dev + CI the identical environment. Add `shellHook` for env vars. 3. **Declarative hosts** — for servers, a `nixosConfiguration` per host: services, users, firewall, and packages as code. Contrast with Ansible's mutable, converge-and-pray model — NixOS rebuilds are atomic and rollback-able (`nixos-rebuild --rollback`). 4. **Multi-arch & overlays** — handle aarch64 + x86_64 cleanly; use overlays to patch/pin a single package without forking nixpkgs. 5. **Deploy** — compare `nixos-rebuild switch --target-host`, deploy-rs, and colmena for fleet deploys; pick one and justify it. Show the rollback story. 6. **CI** — `nix flake check`, build all `nixosConfigurations`, and cache to a binary cache (Cachix / attic) so CI and prod pull identical store paths. 7. **Secrets** — Nix store is world-readable; route secrets via agenix/sops-nix, never literal strings in the config. Output as: (a) a complete `flake.nix`, (b) one example dev shell, (c) one example host config, (d) the deploy command + rollback command, (e) the CI snippet. Bias toward: pinned inputs, atomic rollbackable deploys, secrets out of the store, identical store paths in CI and prod.