Objective
Evaluate adopting Gabriel Volpe’s “Private Nix flake” pattern to add a host axis (personal vs. enterprise) on top of the current architecture-only split in Nix - Home Manager, without refactoring this repo or cluttering it with inline override hooks.
Context
Current dotfiles at ~/.config only vary by system (aarch64-darwin, x86_64-darwin, aarch64-linux, x86_64-linux) via forAllSystems in nix/flake.nix. Host-level customization (personal vs. work machine on the same arch) is not supported. Two ad-hoc override hooks exist today:
nix/home-manager/modules/packages.nix:6-12— inlineoverrideAdd/overrideRemovearrays relying ongit rerereto absorb rebase conflicts.nix/home-manager/modules/coding-agents/claude/claude.nix:46-60— sidecarclaude-overrides.nixloaded viabuiltins.pathExists.
Research conducted 2026-04-24 found:
- Home-manager has no first-class host abstraction (HM FAQ just says “one top-level file per user-machine combo”).
- No native “override file” convention under flakes; legacy
~/.config/nixpkgs/overlays/is inert under pure eval. - Community canon splits into four patterns:
hosts/<hostname>/directories (Misterio77, EmergentMind), option-based feature flags (options.my.*),flake-partsper-host modules (srid, Lite-system), and composable profile stacks.
Approach
Prefer downstream-as-input over a host-axis refactor of this repo:
- Public repo (this one) stays minimal and unchanged.
- A separate private flake takes this as a flake input, layers its own
hosts/work.nix+ overlay exposingmkHomeConfigurationsper Volpe’s writeup. - “Rebase on upstream” collapses to
nix flake update <input>on the private flake. - Secrets stay out of the public repo entirely; use sops-nix or agenix in the private flake.
Alternative (rejected for current scope): refactor this repo to Misterio77/EmergentMind-style host axis with hosts/, specialArgs, options.my.*. Touches every module; high churn; only worthwhile if multiple hosts need to co-exist in one repo.
Next Actions
- Decide whether the enterprise use case is concrete enough to warrant creating a private flake yet, or whether the existing
overrideAdd/claude-overrides.nixhooks are sufficient for now. - If proceeding: scaffold a private flake with this repo as input, one host module, and a test overlay that swaps one small surface (e.g.
isTrusted, git identity, or a coding-agent API base URL). - Validate that the override-priority mechanics (
lib.mkForce,disabledModules) actually compose cleanly against this repo’s modules without per-module changes. - Consider whether the existing
claude-overrides.nixsidecar pattern should be generalized or retired once the private-flake approach is in place.
Resources
- Gabriel Volpe — “Private Nix flake” — primary reference pattern.
- Lorenz Bischof — “Manage secrets in NixOS with a private repository” — same pattern, secrets framing.
- Michael Maclean — “NixOS with private flakes” — SSH agent forwarding setup.
- Misterio77/nix-config — canonical
hosts/<hostname>/reference (rejected alternative layout). - EmergentMind/nix-config —
hosts/common/{core,optional}layered imports. - srid/nixos-config — flake-parts approach.
- NixOS Discourse — Hostname-agnostic nix-darwin configuration — endorses named configurations and git-branch-per-machine.
- Jade Lovelace — “Flakes aren’t real” — dissenting view worth reading before committing to flake-heavy layering.
Notes
Status is paused because the enterprise host isn’t yet a concrete requirement. Unblocked when: (1) a specific work machine materializes, or (2) the current overrideAdd / claude-overrides.nix hooks start causing rebase pain.
Non-obvious finding from research: disabledModules matches by path, so any upstream tree restructure would silently break a downstream consumer relying on it. That argues for keeping module paths stable in this repo once downstream consumers exist, or for preferring lib.mkForce over disabledModules in the private flake.