Misterio77/Foundry: A Personal NixOS Infrastructure Monorepo

What Foundry Consolidates Across Personal Machines

Misterio77/Foundry solves a configuration ownership problem for one infrastructure operator whose computers and servers have accumulated related Nix definitions. Instead of separating operating-system configuration, user configuration, reusable modules, packages, and deployed applications into unrelated repositories, it keeps them in one public monorepo. The intended audience is a technically experienced reader studying how NixOS, Home Manager, self-hosted services, secrets, and continuous integration can be organized as one declarative system.

The scope is unusually broad. Per-machine NixOS configurations live under `hosts/nixos/`, Ubuntu system-manager configurations live under `hosts/ubuntu/`, and shared settings live under `hosts/common/`. Home Manager is represented under `home/` and configured through feature flags. Reusable NixOS and Home Manager modules are separated into `modules/`, while `overlays/` and `pkgs/` contain custom packages and overlays. Public applications that the configuration deploys are kept under `projects/`. The `lib/` directory is described as a pure-Nix Material You color engine.

This design reduces the number of places an operator has to discover when changing a host, but it also makes the repository personal. Host names such as `atlas` and `alcyone` appear in the documented layout, and the README describes the author's own hardware layout and services. There is no general configuration schema, compatibility matrix, or migration guide. Treating Foundry as a ready-made baseline would ignore its main limitation: it is a public working archive, not a generalized distribution.

Host Modules, Packages, and Projects Form One Nix Boundary

Foundry is best understood as a layered Nix configuration rather than a single executable tool. Machine definitions sit at the top, shared host configuration provides common inputs, and modules or packages can be composed underneath. Projects have their own source directory because they are deployed by the infrastructure. This separation keeps an application such as the `m7.rs` website from being conflated with the desktop or server configuration that builds and runs it.

The repository requires Nix flakes, and the presence of `flake.nix`, `flake.lock`, `shell.nix`, and `hydra.nix` places the build and CI definitions alongside the configurations. The README says that Hydra builds every host, serves a binary cache, and handles auto-upgrade through pull deployment. That is a substantial operational choice. A pull deployment can detect a changed configuration and pull it into the infrastructure, but the README does not document rollback behavior, failure handling, or the exact commands used by `deploy.sh`, so those operational details cannot be assumed.

The `overlays/` and `pkgs/` directories also indicate that Foundry is not limited to stock package selection. Custom packages include wallpapers, according to the repository description, and the color engine in `lib/` supplies declarative theming. This is useful for an operator who treats appearance and system configuration as one concern. It also raises the review burden: changes can span package definitions, modules, host imports, projects, and CI. An engineer considering adoption needs to inspect those dependency boundaries rather than copying a small set of highlighted applications.

Impermanence Changes the BTRFS Installation Contract

Foundry's installation model is built around a specific BTRFS filesystem layout. The README describes a single BTRFS partition with subvolumes for `/nix`, a `/persist` directory, a swap file, and a root subvolume. `disko` handles declarative partitioning, while `impermanence` and blank snapshotting support opt-in persistence. On desktop and laptop systems, the partition is encrypted. `lanzaboote` provides Secure Boot support.

This is not a cosmetic configuration choice. Root is cleared on every boot, so state that must survive a restart has to fit the intended persistence model. The README says persistence is opt-in through `impermanence`, but it does not provide a host-independent recipe showing exactly which paths are selected or how a new machine is added. Encryption is also qualified by system type: it applies to the author's computers except headless systems. Anyone transferring the configuration must verify whether their deployment target follows the same assumptions.

For an experienced NixOS operator already using BTRFS, declarative disks, impermanence, and Secure Boot, this structure puts the major storage choices in source control. For a new user, it is a poor first flakes configuration. The README explicitly points readers seeking something simpler to `nix-starter-config`, which is a clearer choice based on the project's own positioning.

Secrets and Home Manager Are Operator-Specific

Deployment secrets are handled with `sops-nix`. The README states that deployment secrets, including user passwords and server service secrets, are encrypted with the author's personal PGP key stored on a YubiKey. Relevant SSH host keys are handled with the same encryption approach. Desktop and laptop passwords are instead managed through `pass`, with encryption tied to the same PGP identity, which is also used for mail signing and SSH access.

This setup is consistent across personal machines, but it is not self-contained onboarding documentation for another operator. The documentation does not explain key generation, recipient configuration, age alternatives, key rotation, emergency recovery, or the steps required to replace the author's identity. The `.sops.yaml` file is present at the repository root, but its contents are not available here, so no configuration details should be inferred from its name.

Home Manager is integrated as a NixOS module through `home-manager.users`, rather than installed as an entirely separate workstation configuration. Feature flags make it possible to opt into user-level components. This can reduce configuration fragmentation, but users should inspect `home/` and `modules/` to identify which features are author-specific. A reviewer should treat feature availability as repository structure to verify, not as a guaranteed setup wizard for every account.

A First Repository Inspection Instead of a Generic Install

The README does not give an installation command, release artifact, or generic setup sequence for Foundry. It states that Nix flakes are required and identifies the starter repository for readers who want a simpler introduction. The documented repository URL is the starting point for obtaining the source, but the README does not specify a supported deployment command.

A practical first step is to obtain the repository and inspect the files that define the host boundary. The following command clones the public source; it does not activate a host or apply the author's configuration:

git clone https://github.com/Misterio77/Foundry.git

After cloning, inspect `flake.nix` to see how host evaluation is exposed, then inspect the machine-specific directories under `hosts/nixos/` and `hosts/ubuntu/`. Follow their imports into `hosts/common/`, `home/`, and `modules/`. Review `flake.lock` for pinned inputs, `hydra.nix` for the documented build and cache scope, and `deploy.sh` for the actual pull deployment path. The `.sops.yaml`, overlays, and package definitions also need review before any real host is rebuilt.

The README's Hydra badge points to a job for `hosts.atlas`, which confirms that host naming is part of the build configuration. A prospective user should not expect that job to correspond to their own hostname. Nor does the repository have GitHub releases, so there is no documented release artifact or upgrade series to select. Foundry is designed to be changed and evaluated as source, which makes repository understanding part of installation rather than a separate preliminary step.

Hydra, Pull Deployment, and Upgrading Carry Operational Weight

The documented maintenance arrangement has two parts. Hydra builds every host and serves a binary cache, while pull deployment performs auto-upgrade. This can keep evaluation, binary distribution, and configuration rollout within the same declarative system. The repository is not archived, and its last push was on 2026-10-15, so there is no repository-level maintenance warning based on those facts.

The upgrade model is still broad. A host build may include its operating system, user configuration, services, secrets setup, and references to deployed projects. The README does not state how failed deployments are surfaced, whether hosts retain their previous generation, or how an operator cancels an automatic update. It also does not document migration of state between the author's machine names and a new fleet. The absence of GitHub releases means upgrades come from repository history and changed inputs rather than a separate release channel.

The MIT license permits use, modification, distribution, and sublicensing under its conditions, including preservation of the copyright and license notice. That is a permissive license, but it does not transfer the author's infrastructure identity, PGP keys, host names, or deployment credentials. Reusers still need to replace operator-specific data and decide how their own secrets and machine layout will work.

The Wrong Fit for Simple or Unmanaged Machines

Foundry is the wrong tool for a user who wants a conventional installer, a small set of optional features, or a portable desktop configuration. Its BTRFS subvolume layout, blank root, opt-in impermanence, encrypted partition assumptions, `lanzaboote`, `disko`, Home Manager integration, self-hosted services, personal PGP workflow, and Hydra deployment form a coupled operational environment. The README's recommendation of `nix-starter-config` for a simpler start confirms this distinction.

The alternative approach described by Foundry itself is not another competitor with similar branding. `nix-starter-config` starts from a simpler flakes-oriented configuration, while Foundry shows how one operator expanded that foundation into a personal infrastructure monorepo with disk management, secret encryption, services, custom packages, and CI. The practical difference is scope. A new user can learn flakes through the smaller configuration first, then use Foundry as a reference for advanced declarations. Existing NixOS users should instead evaluate whether Foundry's impermanence and storage conventions match their machines before importing pieces.

The repository's public nature is valuable as an example of how the pieces relate, but it should not be treated as proof that the author's hardware model, security boundary, or service catalog will fit another environment. That judgement is based on the explicit personal scope, host-specific names, and storage assumptions documented by the project.

Editorial conclusion

Adopt Foundry as a reference or starting point if you understand Nix flakes and can adapt its BTRFS, encryption, Home Manager, and Hydra assumptions. Do not adopt it unchanged if you need a portable installer, documented migration path, or a simpler first flakes configuration. Check the host-specific encryption assumptions, machine names, secret-management setup, and meaning of the Hydra pull deployment before applying it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Misterio77/Foundry on GitHub
4. README