# Inside ryan4yin/nix-config: one flake for NixOS desktops, macOS and homelab servers

> ryan4yin/nix-config is a personal Nix setup that builds Wayland desktops, a macOS configuration and three homelab servers from one flake, with Home Manager shared across platforms. It is candid about its own complexity and sends newcomers to an older branch.

**ryan4yin/nix-config** — ❄️ My nix config for both desktops(NixOS+macOS) and homelab servers(NixOS).

- Repository: https://github.com/ryan4yin/nix-config
- Website: https://nixos-and-flakes.thiscute.world
- Stars: 2,107 · Forks: 105
- Language: Nix
- License: MIT
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/ryan4yin-nix-config

## One flake keeps desktops, Macs and servers in sync

Everything is built from a single `flake.nix`, and that one input covers three different classes of machine. Desktop machines run NixOS with Home Manager, the Wayland compositor Niri, the Noctalia shell and `agenix` for secrets; Apple machines run nix-darwin plus Home Manager; servers are three physical mini PCs hosting virtual machines. Those same mini PCs carry a K3s test cluster and the self-hosted services, with libvirt and microVMs doing the virtualization work. Hosts are inventoried in `hosts/`, flake outputs are composed in `outputs/`, and the default branch is `main`. Anyone forking this has to read both trees before touching either, because a change to a shared module lands on a laptop and on cluster nodes in the same commit.

## Home Manager is the only layer the Mac and Linux desktops share

The shared piece between Apple hardware and NixOS laptops is `home/`, and the editor paths show exactly where that sharing stops.

```
home/base/core/editors/
home/base/gui/zed-editor.nix
home/linux/gui/base/vscode.nix
agents/README.md
```

Helix and Neovim, plus the `$EDITOR` setting, live under a path with no platform name in it, and Zed sits under a base path rather than a linux one. VS Code is the odd case out: it sits under a linux path, so a Mac host inherits Zed and Helix from this repository but no VS Code module. The `agents/` directory is younger than the desktop stack and holds rules, installers and command-line snippets for LLM coding agents, documented separately in its own README.

## The component table covers Wayland desktops and nothing else

Every row of the component table sits under the header NixOS (Wayland), so the list says nothing at all about the Mac hosts. The display manager is greetd with tuigreet, the window manager is Niri, and Noctalia handles bar, notifications, launcher, lock screen, control center, power menu and screenshots in one native shell. Terminals are Kitty and Ghostty, the multiplexer is `tuios`, the shell is Nushell with Starship, and colours come from catppuccin-nix. Networking is systemd-networkd or NetworkManager, the input method is Fcitx5 with rime and flypy, and file handling splits between Yazi in the terminal and thunar on the desktop. Screenshots come from Noctalia capture, while recording uses OBS, gpu-screen-recorder and wf-recorder. A reader planning a Mac desktop gets not one row from this table.

## Topics still say i3 and hyprland while the config ships Niri

Repository topics are dotfiles, hyprland, i3, nix, nix-flake, nix-flakes, nixos, nixos-configuration, rice, ricing and unixporn. Measured against that list, the current component table names Niri as the window manager and Noctalia as the desktop shell; neither Hyprland nor i3 appears in any row. The author already concedes that the tree keeps getting harder to read and sends newcomers to older snapshots such as the `i3-kickstarter` branch, which is where the i3-era layout actually lives. Tags therefore travel behind the code, and a search that trusts them lands on compositors this checkout does not run. The ricing tags explain the rest of the picture: the desktop is treated as a hobby artefact, with its own wallpaper repository and screenshots whose file names carry 2026-10-02 and 2026-10-06.

## Operational files sit outside the desktop module tree

Much of what makes this usable over years sits outside `home/`.

```
BACKUP.md
AGENTS.md
SECURITY.md
secrets/
certs/
hardening/
infra/
```

BACKUP.md holds the backup design, AGENTS.md the repository conventions, and the README hands security and hardening off to SECURITY.md rather than listing steps inline. Secrets have a directory of their own, and `agenix` appears in the NixOS desktop list as the tool that feeds it.

```
flake.nix
flake.lock
nixos-installer/
Justfile
overlays/
modules/
lib/
templates/
tests/
vars/
utils.nu
```

That second block is the flake plus its scaffolding: an installer directory, a Justfile, overlays, reusable modules, templates, tests, vars and a Nushell utility script. A top-level `.github/` directory exists as well, yet the README does not say what runs inside it.

## The README prints no command, so the branch you pick is the install

There is no rebuild command anywhere in the README, no shell block and no package list to copy; what you get is the repository itself, on the default branch `main`. Where a reader should start depends on who they are. Someone new to NixOS is pointed at older, simpler snapshots such as `i3-kickstarter`, because the author says the configuration is becoming more complex and difficult for beginners to read. A macOS user is sent to `nix-darwin-kickstarter` for a quick start, and anyone who wants the flake commands the README omits is sent to the NixOS and Nix Flakes Book, which doubles as the project homepage at nixos-and-flakes.thiscute.world. Those starters are narrower by design: this repository is the accumulated result of desktops and servers sharing modules. Code is published under the MIT licence, and the last push was on 2026-10-06.

## The same flake also drives three homelab mini PCs

Server-side content gets one dense sentence in the README. Three physical mini PCs run the virtual machines, with libvirt and microVMs named side by side, and the same three machines host a K3s test cluster plus the self-hosted services. `hosts/` holds the inventory, and `infra/` sits at the top level beside it. Since flake outputs are composed in `outputs/`, server declarations live in the same flake that builds the Wayland desktops, which means the component table gives a reader no clue what a cluster node looks like. There is no server table, no per-host description and no documented rollback path for a failed rebuild, so host roles and machine count have to be read out of `hosts/` directly.

## Tmpfs on root and a passphrase-guarded Btrfs partition

The filesystem choice is the part with real operational weight. The root filesystem is tmpfs, and persistent data sits in Btrfs subvolumes on a LUKS encrypted partition that a passphrase opens, with lanzaboote handling Secure Boot. Anything written outside those subvolumes is gone when the machine reboots, and the passphrase becomes a boot-time dependency: a node that comes up without it has no route to the persistent data. The README does not document a recovery path for a lost passphrase, and the backup design lives in BACKUP.md rather than in the README itself, so that question is answered, if at all, in a separate file. Servers follow the same arrangement, which puts the passphrase decision squarely in front of the K3s nodes.

## Conclusion

Adopt this flake if you want to read how one repository carries a Wayland desktop, a macOS configuration and three servers at once, and you are willing to work through Home Manager modules before changing anything. Do not adopt it as a first NixOS install: the author says the current tree is hard for beginners to read and points new users to the older i3-kickstarter branch or, on macOS, to nix-darwin-kickstarter. Before the first rebuild, read hosts/ and BACKUP.md, because the layout puts tmpfs on / and keeps persistent data in Btrfs subvolumes inside a LUKS partition that wants a passphrase at boot.

## FAQ

### Can ryan4yin/nix-config be used on macOS as well as NixOS?

Yes. macOS desktops run nix-darwin plus Home Manager and share the same home/ configuration with the NixOS desktops, while the component table only describes the NixOS Wayland side. The README still points macOS users to ryan4yin/nix-darwin-kickstarter for a quick start.

### Which window manager does ryan4yin/nix-config actually use?

Niri on Wayland, paired with the Noctalia shell that carries the bar, notifications, launcher, lock screen, control center, power menu and screenshots. Repository topics still list i3 and hyprland, neither of which appears in the current component table.

### How can a beginner get a simpler version of ryan4yin/nix-config?

The README says the configuration is becoming more complex and difficult for beginners to read, and points to older, simpler versions such as the i3-kickstarter branch. macOS users are pointed to ryan4yin/nix-darwin-kickstarter instead.

### How does ryan4yin/nix-config handle disk encryption and persistent storage?

Root is tmpfs, and persistent data lives in Btrfs subvolumes on a LUKS encrypted partition opened by passphrase. Secure Boot is handled by lanzaboote rather than the distribution default.

### What do the three NixOS servers in ryan4yin/nix-config run?

They are physical mini PCs hosting virtual machines through libvirt and microVMs, a K3s test cluster and the self-hosted services. The host inventory lives in hosts/ and flake outputs are composed in outputs/.

### Does the README show a rebuild command for ryan4yin/nix-config?

No, the README contains no shell command at all. It points to hosts/ for the inventory, outputs/ for how flake outputs are composed, and the NixOS and Nix Flakes Book for the flake commands themselves.

## Sources

- [License: MIT](https://github.com/ryan4yin/nix-config/blob/main/LICENSE)
- [Project website](https://nixos-and-flakes.thiscute.world)
- [README](https://github.com/ryan4yin/nix-config/blob/main/README.md)
- [Releases](https://github.com/ryan4yin/nix-config/releases)
- [ryan4yin/nix-config on GitHub](https://github.com/ryan4yin/nix-config)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ryan4yin-nix-config