NUR (Nix User Repository) is a community package registry and distribution layer for Nix. In production it maintains a registry of several hundred user-contributed Nix repositories in repos.json, pins every entry to a specific revision in repos.json.lock, and exposes the aggregate as a Nix flake/overlay/package set. The Nix entry points (default.nix, flake.nix, lib/evalRepo.nix, lib/repoSource.nix) lazily translate locked registry entries into `nur.repos.<name>.<pkg>` attributes, including typed support for NixOS, Home Manager, Darwin, and flake-parts modules and overlays via flake-parts. The operational core is a small, typed Python CLI (`bin/nur` and `ci/nur/`) with subcommands for updating the lockfile, evaluating repos, formatting the manifest, generating a combined monorepo, and producing a search index. Updates run hourly via GitHub Actions: each repo is concurrently prefetched using either the Git smart HTTP protocol or GitHub/GitLab archive endpoints, evaluated in a sandboxed `nix-env` run to catch breakage, and then either locked to a new revision or pruned from the registry if deleted. A separate set of CI scripts publishes `nur-combined` and updates package search data. The architecture is cleanly split between Nix expression logic and Python automation, with careful handling of async concurrency, evaluation failures, and safety guards against accidental mass repository loss.

SrvOS is a production-grade NixOS and nix-darwin configuration framework that provides opinionated, modular server configurations. The codebase exports NixOS modules organized into machine types (common, server, desktop), hardware profiles (Hetzner, AWS, DigitalOcean, Vultr), roles (GitHub Actions runner, Nix remote builder), and mixins (telegraf, nginx, terminfo). It uses Nix flakes for dependency management and includes comprehensive test configurations that validate module evaluation across multiple platforms. The architecture follows NixOS module patterns with clear separation between shared configurations, platform-specific modules, and role-based configurations. Key entry points are default.nix and flake.nix, which expose nixosModules and darwinModules for consumption. The codebase demonstrates strong engineering practices with security-focused defaults (SSH hardening, sudo restrictions), comprehensive systemd service configurations, and production-ready monitoring setups. Notable for its GitHub Actions runner implementation, which includes sophisticated token management via GitHub Apps, ephemeral runner support, and secure systemd sandboxing. The Prometheus alert rules provide production monitoring capabilities with well-defined alert conditions for infrastructure health.

Naersk is a Nix library that automates building Rust projects by parsing `Cargo.lock` and creating Nix derivations for dependencies and the final binary. It leverages Nix's sandboxing and caching to achieve reproducible and incremental builds. The library exposes a single entry point, `buildPackage`, which accepts a source directory (or attribute set) and returns a derivation. Internally, it implements a two-phase build: first compiling all dependencies into a cached derivation, then compiling the user's crate with those pre-built dependencies. This architecture optimizes rebuild times when only the application code changes. Key capabilities include support for git dependencies, workspace crates, custom `rustc`/`cargo` toolchains, cross-compilation (via `CARGO_BUILD_TARGET`), and automatic crate-specific overrides (e.g., adding `openssl` and `pkg-config` for the `openssl-sys` crate). The codebase is implemented entirely in pure Nix, showcasing advanced Nix patterns like recursive toml serialization, generic closure traversal, and dynamic source stub generation. The project is actively maintained, has a comprehensive test suite (fast and slow), and is widely used in the Nix ecosystem.

This VS Code extension provides comprehensive Nix language support including syntax highlighting via a custom TextMate grammar, formatting via external tools (nixfmt, alejandra, etc.), linting via nix-instantiate, and a language server client supporting nil and nixd. It uses a clean architecture with separate modules for the language client, formatter, linter, and process execution. The extension activates on Nix files and falls back to local formatting/linting when no LSP is enabled. The codebase demonstrates good software engineering practices with TypeScript, unit tests, and continuous integration, though it is tightly coupled to the VS Code extension API and Nix toolchain, limiting reuse outside its domain. The most reusable component is the process-runner module, which encapsulates external command execution with error handling in a workspace-aware manner.

This repository provides a collection of Nix development shell environments for a variety of open-source projects, including Arduino, Firefox, Git, OpenWRT, Yocto, and others. Each environment is defined by a `shell.nix` file that specifies the dependencies, environment variables, and sometimes FHS sandboxing (via `buildFHSEnv`) needed to build or develop that project. The codebase acts as a library of reusable Nix expressions—users can drop into any environment using `nix-shell` or `nix develop`. While not a traditional application, it serves as a practical tool for developers using Nix/NixOS to set up reproducible, self-contained build environments that isolate project-specific dependencies from the host system. The environments vary in complexity from simple `mkShell` wrappers to sophisticated FHS chroots with custom linker settings and variable passthrough (e.g., Yocto). The repository also demonstrates advanced Nix patterns like overriding `stdenv` for LTO (Firefox) and creating wrapper scripts for C standard enforcement (Buildroot).

dconf2nix is a CLI tool and Haskell library that converts GNOME dconf configuration files into Nix expressions for use with Home Manager's dconf.settings option. It parses the GVariant text format using Parsec combinators, supporting a wide range of dconf value types (booleans, integers, floats, strings, byte strings, tuples, lists, variants, dictionaries, typed values, and JSON). The parser is comprehensive and handles edge cases such as hexadecimal and octal integers, scientific notation, Unicode escapes, and nested structures. The rendered output uses Home Manager's lib.hm.gvariant constructor functions to produce valid Nix code. The architecture cleanly separates parsing (DConf module), data model (DConf.Data), and Nix rendering (Nix module), with a small CLI entry point. The codebase is well-tested with 20+ test cases covering various dconf input patterns and their expected Nix output.