nix-topology is a NixOS-based tool that automatically generates infrastructure and network diagrams as SVGs from NixOS configurations. It uses a global topology module to aggregate information from multiple NixOS hosts, extracting data about interfaces, services, containers, and virtual machines via specialized extractors. The gathered topology is then rendered using ELK for layout and converted to SVG via custom tools (elk-to-svg and html-to-svg), producing both a physical connection diagram (showing nodes as cards with hardware and service details) and a network-centric view (showing logical networks and their connections). The architecture is modular, with clear separation between information gathering, topology aggregation, and rendering.
Nixpkgs is the largest, most comprehensive package repository for the Nix package manager and the NixOS Linux distribution. It contains over 140,000 package definitions spanning virtually every domain of software, along with the build infrastructure, standard environment, and NixOS system modules needed to build and configure a complete operating system declaratively. The repository is not a single application but a collection of Nix expressions, shell scripts, Python tools, and Rust utilities that together form a reproducible, source-based distribution framework. It provides a modular module system for declarative configuration, a generic build phase hook mechanism, extensive CI automation for PR review and package updates, and a sophisticated test driver for integration testing. The codebase is actively maintained with thousands of contributors, and its architecture emphasizes composability, reproducibility, and cross-platform support.
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.
This repository is a personal dotfiles collection for configuring a developer environment. It provides a cohesive setup across Linux distributions using Nix flakes and Home Manager for declarative configuration, with fallback scripts for other systems. The environment integrates Zsh shell, Neovim editor, terminal emulators (Wezterm/Alacritty), and window managers (i3/Sway) with consistent keybindings and productivity enhancements. Configuration is modular, with isolated plugin setups for Neovim and Zsh, utility scripts for cross-tool functionality, and version management via mise. The repository emphasizes reproducibility through lock files and structured installation processes.
Kubenix is a Nix-based framework for declarative Kubernetes management. It uses the NixOS module system to define Kubernetes resources, Helm charts, Docker images, and custom resources in a type-safe, composable manner. The project provides a CLI tool for applying manifests with diffing, pruning, and secret injection via vals. At its core, kubenix is a set of Nix library functions and modules that evaluate user configuration to produce Kubernetes YAML/JSON. It supports submodules (nested composable configurations), testing frameworks (including kubetest), and code generation from Kubernetes OpenAPI specs. The architecture is purely functional, leveraging Nix's lazy evaluation to merge and validate resources at build time. This is a hybrid project combining a library (Nix modules and functions) with an application (CLI tool), but it is classified as an application because its primary deliverable is a deployable package and CLI.
This repository is a personal Nix configuration (dotfiles) for managing a heterogeneous fleet of machines: NixOS desktops and servers, macOS laptops (via nix-darwin), and Kubernetes clusters (k3s, KubeVirt). It is structured as a Nix flake with modular components for system configuration, home-manager profiles, package overlays, secrets management (agenix), and infrastructure monitoring (Grafana, Prometheus, VictoriaMetrics, Loki). The codebase demonstrates advanced Nix patterns: parameterized module generators for K3s and KubeVirt, automatic file scanning for module imports, declarative disk partitioning (disko), ephemeral root filesystems with persistent state (preservation), and sandboxed GUI applications (nixpak, bwrap). It also includes a custom desktop shell (noctalia) and extensive input method customization (Rime/Fcitx5). While highly personalized and not intended for direct reuse, the architectural patterns and modular design serve as a reference for building complex Nix-based infrastructure. The repository is actively maintained with eval tests and CI, but lacks integration tests for runtime services.
Xonsh is a cross-platform, Python-powered interactive shell that combines Python syntax with shell subprocess commands. The codebase implements a full shell environment with a custom parser (PLY-based with version-specific extensions), an execution engine that compiles xonsh code to Python AST, a rich tab-completion system with multiple backends (bash, git, pip, python, custom completers), a pluggable history backend (JSON, SQLite), a prompt system with git status and virtualenv information, and a subprocess management layer with job control. It also includes CLI tools for formatting, linting, and interactive configuration (xonfig wizard and web UI). The architecture is monolithic with a clear module structure: parsers, executers, completers, prompts, history, procs, and shells. External dependencies include prompt_toolkit, pygments, and PLY (vendored). The repository is actively maintained with frequent releases, supports Python 3.10+, and has an extensive test suite. Some technical drift exists due to deprecated API shims, multiple parser versions, and LLM-generated tests, but the core is well-engineered.
This is a personal dotfiles repository for NixOS, authored by Henrik Lissner (hlissner). It serves as a complete, declarative system configuration for multiple machines (laptops, desktops, and a HTPC) using Nix flakes. The repository defines the entire system—from the bootloader and kernel parameters to the desktop environment (Hyprland), shell (zsh, tmux), development tools, and custom utilities. It is not a standalone application but a collection of configuration files, NixOS modules, and scripts that together form a highly opinionated, reproducible computing environment. The architecture is centered around a Nix flake (flake.nix) that imports modular NixOS modules organized by category (desktop, development, editors, shell, services, hardware profiles, themes, etc.). A custom CLI tool called 'hey' (written in Janet) provides a command hub for system management tasks like rebuilding, garbage collection, profile switching, and dotfile synchronization. The desktop environment is heavily customized with Hyprland (Wayland compositor), rofi launcher menus, matugen-based dynamic theming, and a suite of utility scripts for screenshots, screen recording, audio, and more. While the repository is not designed for reuse by others (it explicitly warns against being used as a community framework), several components demonstrate high craftsmanship and could be extracted with minimal modification. The Janet libraries under lib/hey/ provide a reusable command-line argument parser, an async rofi interaction library, and general utility functions. The Nix library (lib/nixos.nix) implements a flake builder pattern that could be adapted for other multi-host NixOS setups. The matugen templates and rofi themes are also potentially reusable as standalone theming assets.
OpenClaw is a Nix flake that packages the OpenClaw AI assistant gateway for declarative installation on NixOS, macOS, and Home Manager. It provides a Home Manager module (programs.openclaw) and a NixOS module (services.openclaw-gateway) with options for instances, plugins, skills, workspace files, environment variables, and systemd/launchd services. The flake also includes an overlay, a Home Manager module for runtime plugins, and a set of Nix scripts that generate and validate plugin locks, config options, and runtime plugin materialization.
Jovian-NixOS is a NixOS overlay and module collection that enables running NixOS on the Steam Deck and similar handheld gaming devices. It provides hardware-specific kernel configurations, firmware update integration, Steam Deck UI (Gaming Mode) support, audio/display driver patches, and a suite of system services (power management, input handling, performance control) modeled after SteamOS. The repository is structured as a Nix flake with a clear separation of concerns: NixOS modules under `modules/` define configuration options for Steam Deck hardware, Steam client integration, and SteamOS-like system settings; a Nix overlay under `pkgs/` provides patched or vendored packages (gamescope, mesa, linux kernel, pipewire, etc.) that are not yet in upstream Nixpkgs or require Steam Deck-specific modifications. The codebase demonstrates strong NixOS engineering practices: modular design, extensive use of lib.mkIf/mkMerge for conditional configuration, hardcoded path patching via replaceVars, and resholve for shell script safety. The documentation system is a custom Ruby pipeline that generates a static site from markdown with options and package listings. While the repository is tightly coupled to NixOS and the Steam Deck domain, it is a well-maintained, production-quality example of how to extend NixOS for specialized hardware.
Attic is a self-hostable Nix binary cache server written in Rust. It provides a multi-tenant, globally deduplicated cache for Nix store paths, supporting both local filesystem and S3-compatible storage backends. The system consists of a server binary (`atticd`) that implements the Nix binary cache HTTP API and a client CLI (`attic`) for authentication, pushing store paths, and managing caches. Authentication is stateless via signed JWTs (RS256/HS256) with fine-grained permissions per cache. The server uses content-defined chunking (FastCDC) to split NAR archives into variable-sized chunks, enabling deduplication at both the NAR and chunk levels. Compression (brotli, zstd, xz) is applied during upload with simultaneous hash computation for integrity verification. Garbage collection supports per-cache retention periods and cascading deletion from local caches to global chunk storage. The codebase is organized as a Cargo workspace with four crates: `attic` (core library with chunking, hashing, Nix store FFI), `server` (HTTP server, database, storage, garbage collection), `client` (CLI with push, watch-store, cache management), and `token` (JWT creation and verification). The architecture is modular, with clear separation between API handlers, database entities, storage backends, and authentication. While the project is still in early prototype stage with many TODOs and some fragile FFI bindings to Nix's C++ store library, it demonstrates solid engineering practices with reusable components like streaming hash readers, compression streams, and a custom serde serializer for Nix manifest format.
This repository is a comprehensive, declarative NixOS homelab configuration managed with the Clan framework. It defines the entire infrastructure for a multi-machine homelab including servers, desktops, and network devices, all version-controlled and reproducible. The system provisions self-hosted services (Caddy, Grafana, VictoriaMetrics, Vector, Blocky, Miniflux, Linkding, etc.), identity management (Authentik, Zitadel), monitoring and alerting, backup (Borgbackup), and desktop environments (KDE, i3). The architecture is modular: reusable NixOS feature modules under `modules/nixos/features/` follow a consistent pattern using `mkFeatureOptions` for enabling services with standardized options (domain, firewall, monitoring integration). Secrets are managed via SOPS with age encryption, and disk partitioning is handled by Disko templates. The repository is not a software application but an infrastructure-as-code project that demonstrates high craftsmanship in Nix module design, with clear separation of concerns, helper functions, and integration patterns. It is actively maintained but shows some technical drift due to deprecated identity providers and hardcoded IPs.
not-os is a minimal, embedded-focused Linux distribution built entirely as a Nixpkgs overlay, demonstrating how to construct a bootable OS from scratch (kernel, initrd, squashfs root) using NixOS modules while replacing systemd with runit. The repository provides configurations for x86_64 QEMU, Raspberry Pi (ARM), and Xilinx Zynq targets, along with an iPXE boot chain featuring cryptographic signature verification for secure boot. It illustrates advanced Nix techniques for building custom initrds, integrating firmware, and creating reproducible embedded system images, though some components (like the dummy stage-2 init script placeholder) indicate a focus on flexibility over polish. The codebase is well-structured with clear module boundaries and includes Hydra CI integration for automatic testing.
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.
NixBSD is a declarative system configuration framework that ports NixOS infrastructure to BSD kernels (FreeBSD and OpenBSD). It functions as a complete operating system distribution definition, managing bootloaders, init systems, services, and user configurations through Nix expressions. The architecture is modular, leveraging the NixOS module system to define system state, with specific adaptations for BSD-specific tools like rc.d, jails, and ZFS. The system relies heavily on custom build logic to generate disk images, installers, and bootloader configurations that are compatible with BSD hardware constraints. It includes a portable init abstraction layer to unify service management across Linux, FreeBSD, and OpenBSD, though this introduces significant complexity. Security features like PAM, ACME certificates, and setuid wrappers are implemented as declarative modules. While the codebase demonstrates high craftsmanship in system integration and Nix expression patterns, it suffers from high technical drift due to the inherent divergence between NixOS (systemd-based) and BSD (rc-based) ecosystems. Upstream NixOS changes frequently require manual merging, and BSD-specific logic (e.g., initware, stand-freebsd) creates maintenance bottlenecks. It is a robust infrastructure tool for users requiring declarative BSD management but requires significant expertise to maintain.
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 GRUB bootloader theme styled after the Minecraft main menu. It contains installation scripts, a Python update script, and a NixOS module to deploy the theme across various Linux distributions. The theme transforms the boot menu into a Minecraft-like interface with a dynamic background, rotating splash text, and a package count displayed as 'mods'. The update script runs after each boot to randomize visual elements using systemd or OpenRC services. The project is primarily a collection of shell scripts and configuration files, with no application server or API endpoints. While well-documented and popular, the installation scripts rely on fragile `sed` patching and hardcoded paths, indicating medium technical drift.
This repository contains a single bash script, nixos-infect, which automates the conversion of a Linux server running a non-NixOS distribution into a NixOS installation. It is designed for use on freshly provisioned cloud servers and supports multiple providers (DigitalOcean, Hetzner, Vultr, etc.) through environment variables and auto-detection. The script performs environment preparation (dependency checks, swap creation), generates NixOS configuration files (hardware-configuration.nix, configuration.nix, and optionally networking.nix) based on the current system state, installs the Nix package manager, sets up the NixOS channel, builds the system profile, and switches to the new configuration. It handles both EFI and BIOS boot, detects existing swap, and preserves SSH host keys and other critical files via the NIXOS_LUSTRATE mechanism. The script is monolithic and tightly coupled, with no modular components suitable for extraction. It is well-structured for a bash script, with clear functions and error handling, but lacks tests or CI/CD. Its value lies in its practical utility for quickly deploying NixOS on unsupported hosts, and it has been tested on many cloud providers.