srid's nixos-config: one flake for a Linux box, a Mac and a home directory

A personal configuration that is meant to be forked

This is a Nix and NixOS configuration for all of the author's systems, described as a KISS configuration based on Flakes and flake-parts, and it supports macOS as well as Linux.

The author is explicit about the intended use, which is the most useful paragraph in the README. If you want to create your own configuration from scratch, you should look at nixos-unified and specifically the nixos-unified-template, and this repository is presented as a working example rather than as a product to depend on. That framing matters, because a configuration is not a library: there is no upgrade path, and the only version you can have is the one you edited yourself.

If you do use it as a starting template, there are three initial steps, and they are all edits rather than commands. You edit config.nix in the repository root to set your primary user information, namely username, fullname, email and sshKey. You replace the SSH keys in secrets/secrets.nix with your own, or you delete that file if you do not use agenix. And you delete the files in configurations/ that you do not need, creating and renaming files to match your own hostnames.

That third step is the one that tells you how the configuration is organised. A configuration is a set of per-host files, and a host that is not in your fleet should not be in your fork. The rest of the repository is the machinery that turns those files into a system.

Getting a machine onto the configuration

The install paths are the part of a NixOS setup that usually goes wrong, and the README lists them per platform with links rather than inventing a single path.

For a NixOS server, the modern route is nixos-anywhere, run from a Linux system and targeting root@<ip>, with the README pointing at a Hetzner dedicated server installed from the Linux Rescue system, and a blog post about single command server bootstrap. The workflow is to copy from an existing configuration such as ax41.nix, make the networking configuration changes, run nixos-anywhere, wait for the reboot and then ssh in. A pull request in the repository is given as an example of the networking step that had to be handled manually.

DigitalOcean has two documented approaches, a legacy and manual one using nixos-infect, and a modern automated one using a custom image with colerama, with a link to how Zulip does it and to another example. There is a dedicated link for the X1 Carbon machine type and one for Windows through WSL.

After the machine exists, the configuration itself is three steps on both platforms: clone the repository anywhere, run nix run, and re-open your terminal. The macOS path differs only in the first step, which is installing Nix, and it carries a footnote that you might have to remove /etc/nix/nix.conf so that the flake in the repository can do its thing.

The reason for the footnote is worth understanding. A system wide nix.conf can conflict with the settings a flake wants, and the configuration's own file wins once the conflict is gone.

The directory layout is the module system

The architecture starts from flake.nix, and flake-parts is used as the module system. The interesting part is that the output wiring is derived from the directory structure, which the README points at in flake-module.nix.

The mapping is short enough to state in full. A file at configurations/{nixos,darwin,home}/foo.nix produces the output {nixos,darwin,home}Configurations.foo, and a file at modules/{nixos,darwin,home,flake-parts}/foo.nix produces {nixos,darwin,home,flake}Modules.foo. The secrets directory produces no output at all, because it holds agenix data rather than a module.

Two things follow from that. The first is that the three configuration types are peers, so a Linux system, a Mac and a home environment are described in the same place and in the same style, and a person reading the repository can see all three in one directory. The second is that the file names are the output names, which means the tree is the interface: adding a host is adding a file with the right name in the right directory, and there is no central list to update.

That is a genuine simplification for a personal configuration, and it is also the design decision most worth arguing about before you adopt it. Autowiring removes a file of names, and it also removes the place where you would put a comment explaining why a host exists.

The day to day commands, and one detail about file descriptors

The Tips section is the working notes of somebody who uses this configuration, and it is where the operational knowledge sits.

To update NixOS and the other inputs you run nix flake update, and to update only the primary inputs there is a script exposed by the flake:

# nix run .#update

To free disk space there is a pair of commands, deleting all but the last two generations of the system profile and then rebuilding the boot configuration:

sudo nix-env -p /nix/var/nix/profiles/system --delete-generations +2
sudo nixos-rebuild boot

Formatting is handled by nixpkgs-fmt through a just recipe, run inside the Nix devShell, and the full output matrix is built with nix run nixpkgs#omnix ci, which the README says can be done locally or in CI. Secrets are managed with agenix, chosen because it works with SSH keys and functions well on both macOS and NixOS.

The justfile also contains the reason for a piece of defensive scripting, and it is the sort of detail that only shows up in practice. macOS login shells default to 256 file descriptors, and the github: tarball cache that Nix uses opens one descriptor per member, so the build dies with Too many open files. The activate recipe therefore raises the limit to 65536 before it does anything else, falling back to 10240 if that is not permitted.

That single comment tells you more about this configuration than the feature list does. It is a working setup that has been debugged on real machines, and the fixes are in the repository instead of in somebody's head.

The justfile covers containers and Kubernetes as well as the desktop

The README describes a fairly small configuration, and the justfile describes a larger one, which is worth reconciling.

The justfile starts with a default recipe that lists the available commands, and it is organised in modules rather than one long list. There is a mod incus entry pointing at modules/nixos/linux/incus/mod.just for the Incus container lifecycle, parametrized by container name, so you can deploy a container with a command like just incus deploy sheetal-codex. There is a mod apps entry pointing at k8s/apps/mod.just for K3s app operations, with the example just apps olai shell.

The main activate recipe is the one that matters. It runs nix flake lock, determines the local hostname, and then decides what to activate. If a home environment file exists for the current user and host, that is what gets activated, with the message that the home env is being activated. Otherwise the system environment for the hostname is activated.

The recipe also carries the Attic OSS cache option, which is off by default. Set oss_cache=1 or OSS_CACHE=1 and the activate run pulls from Juspay's shared OSS Attic cache at cache.nixos.asia/oss, by adding an extra substituter and an extra trusted public key to NIX_CONFIG. Two constraints are stated in the comment: it needs a trusted user in the wheel group for the extra public key to be honoured, and it applies to local builds only, because the SSH deploy path does not forward NIX_CONFIG.

So the repository is a personal workstation and server setup that happens to include a container layer and a Kubernetes application layer, with the k8s/ directory at the root and the Incus modules under modules/nixos/linux/incus.

Where this configuration is the wrong thing to copy

Four limits follow from what the repository is.

The first is that it is a personal configuration, and the author says so by pointing elsewhere for a general purpose starting point. A company that wants a shared standard will spend its time fighting the personal decisions baked into it, from the Attic cache dependency to the wheel requirement for that cache, to the lock file update that happens on every activate.

The second is the scope. Three configuration types, NixOS, Darwin and home, plus agenix secrets, plus Incus containers, plus K3s applications, is a lot of surface for something described as KISS. The KISS is in the wiring, which is genuinely simple, and the surface is what accumulates around it.

The third is the licence, and here the sources disagree. The README carries an AGPL v3 badge, while the licence field on the repository itself is recorded as unknown and cannot be classified by GitHub. For a configuration that people are invited to copy and run, that disagreement is worth resolving before you fork it, and the file in the repository is the one to read.

The fourth is that there is nothing to upgrade. There are no GitHub releases, so there is no version to pin and no changelog to follow, and the last push was on 2026-10-19. You are tracking a branch, which is fine for one person's machines and a different proposition for a team's.

The honest summary is that this repository is a good example of a personal Nix setup, written by somebody who clearly knows what they are doing, with a couple of rough edges that come from being one person's machine rather than a product.

Editorial conclusion

Adopt srid's nixos-config as a starting point if you want a Flakes based NixOS or macOS setup with home manager, directory driven outputs and agenix secrets, and you are willing to fork it and make it yours. Do not adopt it as a shared framework, because the author points at nixos-unified and its template for that, and the justfile encodes personal decisions such as the Attic OSS cache and the wheel requirement. Verify first that the licence in the repository matches the AGPL badge in the README, that you can live with the configuration types, NixOS, Darwin and home, and that the host installation paths, whether nixos-anywhere, nixos-infect or a custom image, match how you actually provision machines.

Frequently asked questions

Official sources

1. Issues
2. README
3. srid/nixos-config on GitHub