Nix Config

This is my interpretation of the perfect nix flake, this powers my desktops, laptops, servers, vms, containers, and all aspects of my computers.

Features

• Automated Discovery: Hosts and users are automatically configured from filesystem structure
• Automated Persistence: TempFS with persistable components using [Impermanence] or BTRFS snapshotting
• Secret Management: Encrypted secrets in [NixOS] ([sops-nix]) and [home-manager] ([sops-nix] with [sops])
• Automated Updates: Flake dependency updates through Github Actions using [Update-flake-lock]
• Hardware Acceleration: Automatic hardware acceleration support detection and configuration
• Modular Architecture: Custom modules and overlays for extensibility

Supported Configurations

• [NixOS]-managed systems with automatic configuration discovery:
  • Desktops - Personal workstations and development environments
  • Servers - Infrastructure services and automation
  • Laptops - Portable systems with power management

Repository Structure

The repository uses an automatic discovery system that scans the filesystem to build configurations:

.
├─ home              # Root for all user homes (auto-discovered)
│  ├─── {username}   # User-specific configurations
│  └─── shared       # Shared home-manager modules
├─ hosts             # Root for all hosts (auto-discovered by device type)
│  ├─── shared       # Auto-imported modules for all hosts
│  │    ├─── global  # Core system configuration (locale, networking, etc.)
│  │    └─── optional# Optional modules for specific use cases
│  ├─── desktop      # Desktop NixOS systems
│  │    ├─── shared  # Auto-imported modules for desktops
│  │    ├─── {host}  # Individual desktop host configurations
│  ├─── laptop       # Laptop NixOS Systems
│  │    ├─── shared  # Auto-imported modules for laptops
│  │    └─── {host}  # Individual laptop host configurations
│  └─── server       # Server NixOS Systems
│       ├─── shared  # Auto-imported modules for servers
│       └─── {host}  # Individual server host configurations
├─ lib               # Extensions to nixpkgs lib and custom builders
│  └─── builders     # System and home-manager configuration builders
├─ modules           # Custom NixOS and home-manager modules
├─ overlays          # NixPkgs overlays for package modifications
├─ pkgs              # Custom packages not in nixpkgs
└─ docs              # Additional documentation

Auto-Discovery Mechanism

The flake automatically discovers:

• Hosts: By scanning hosts/{device-type}/ directories (excluding shared/)
• Users: By scanning home/ directories and matching with existing hosts
• Hardware Acceleration: Support based on predefined host lists

Welcome to the docs!

Over to the left, you’ll find the sidebar. There you’ll see several sections including “User guides”, “Modules”, “Packages”, “Overlays”, “Hosts”, and “Lib”.

If you’re looking for a specific option you may find the dedicated RacciDev Option Search (at the bottom of the sidebar) has more relevant results.

Installation Guide

This guide covers various installation scenarios for the nix-config repository.

Windows Subsystem for Linux (WSL)

Prerequisites

• Windows 10 version 2004 and higher (Build 19041 and higher) or Windows 11
• WSL 2 enabled
• Administrator access to Windows

Installation Steps

1. Install WSL 2

# Run in PowerShell as Administrator
wsl --install

# If WSL is already installed, ensure you're using WSL 2
wsl --set-default-version 2

2. Setup NixOS for WSL

Download and install NixOS-WSL via NixOS-WSL:

# Download the latest NixOS-WSL tarball
# Import the NixOS-WSL distribution
wsl --import NixOS .\NixOS\ nixos-wsl.tar.gz --version 2

# Start the NixOS instance
wsl -d NixOS

3. Configure NixOS-WSL

After starting your NixOS-WSL instance:

# Clone this repository
sudo git clone https://github.com/DaRacci/nix-config.git /etc/nixos

# Apply the WSL configuration
sudo nixos-rebuild switch --flake /etc/nixos#winix

4. WSL-Specific Features

The WSL configuration includes:

• SSH agent relay between Windows and WSL
• Hardware acceleration support for development
• Remote desktop capabilities
• Optimized for headless operation

Native NixOS Installation

Prerequisites

• NixOS installation media
• Target hardware
• Network connectivity
• Backup of important data

Installation Process

1. Boot from NixOS Installation Media

• Download NixOS ISO from nixos.org
• Create bootable USB/DVD
• Boot from installation media

2. Network Configuration

# For WiFi connections
sudo systemctl start wpa_supplicant
wpa_cli
> add_network
> set_network 0 ssid "YourSSID"
> set_network 0 psk "YourPassword"
> enable_network 0
> quit

# Verify connectivity
ping nixos.org

3. Disk Setup

Follow standard NixOS installation procedures for disk partitioning and filesystem setup as described in the NixOS manual.

4. Generate Hardware Configuration

# Generate hardware configuration
nixos-generate-config --root /mnt

# Copy to your host configuration
mkdir -p /mnt/etc/nixos/hosts/{device-type}/{hostname}
cp /mnt/etc/nixos/hardware-configuration.nix /mnt/etc/nixos/hosts/{device-type}/{hostname}/hardware.nix

# Clone this repository
cd /mnt/etc/nixos
git clone https://github.com/DaRacci/nix-config.git .

5. Customize Host Configuration

Edit hosts/{device-type}/{hostname}/default.nix and hardware.nix according to your needs.

6. Install NixOS

# Install with your specific host configuration
nixos-install --flake .#{hostname}

# Set root password when prompted

7. Post-Installation

# Reboot into new system
reboot

# After reboot, ensure configuration is applied
sudo nixos-rebuild switch --flake /etc/nixos#{hostname}

Existing NixOS System Migration

From Traditional NixOS Configuration

1. Backup Current Configuration

# Backup current configuration (adjust path if using flakes)
sudo cp -r /etc/nixos /etc/nixos.backup

2. Clone This Repository

# Clone to a working directory
git clone https://github.com/DaRacci/nix-config.git /tmp/nix-config
sudo cp -r /tmp/nix-config/* /etc/nixos/

3. Create Host Configuration

# Create your host directory
sudo mkdir -p /etc/nixos/hosts/{device-type}/{hostname}

# Migrate your hardware configuration
sudo cp /etc/nixos.backup/hardware-configuration.nix /etc/nixos/hosts/{device-type}/{hostname}/hardware.nix

# Create default.nix based on your old configuration
# Edit to follow the new structure

4. Test and Apply

# Test the new configuration
sudo nixos-rebuild build --flake .#{hostname}

# Apply if build succeeds
sudo nixos-rebuild switch --flake .#{hostname}

IO Guardian - Database Availability System

The IO Guardian system ensures that services across the infrastructure are aware of the availability of centralized databases (PostgreSQL and Redis) hosted on config.server.ioPrimaryHost. It provides graceful startup and shutdown coordination between the database host and dependent services on other servers.

Overview

The system consists of two components:

1. Guardian Server (runs on client servers)

   • WebSocket server that listens for commands from the coordinator
   • Executes drain/undrain commands by controlling io-databases.target

2. Guardian Client (runs on the IO Host)

   • WebSocket client that connects to all guardian servers
   • Sends undrain command after databases are online (start dependent services)
   • Sends drain command before database shutdown (stop dependent services)

How It Works

System Startup

1. Client servers boot and run wait-for-io-databases.service
2. This service waits (with retries) until PostgreSQL and Redis on the IO Host are reachable
3. Once databases are confirmed available, the service completes
4. The io-databases.target is now ready to be activated
5. When the IO Hosts io-database-coordinator.service starts, it sends undrain to all clients
6. Clients start io-databases.target, which starts all dependent services

Database Shutdown (Graceful Drain)

1. When io-database-coordinator.service stops (before databases stop)
2. It connects to all guardian servers via WebSocket
3. Sends drain command to each server
4. Guardian servers stop io-databases.target
5. Dependent services stop gracefully before databases go down

Database Startup (Undrain)

1. When databases come online on the IO Host
2. io-database-coordinator.service starts
3. It sends undrain command to all guardian servers
4. Guardian servers start io-databases.target
5. All dependent services start

Security

Communication is secured using a Pre-Shared Key (PSK) that must be at least 32 characters. All WebSocket connections must authenticate with this key before commands are accepted.

Generating the PSK

Generate a new PSK using OpenSSL:

openssl rand -base64 32

Adding the Secret

Add the generated PSK to hosts/server/secrets.yaml:

IO_GUARDIAN_PSK: <your-generated-key>

Then encrypt the file:

sops --encrypt --in-place hosts/server/secrets.yaml

Configuration

Port

The guardian WebSocket server listens on port 9876 by default. This port is automatically opened to local subnets on servers with database dependencies.

Dependent Services

Dependent Services will be automatically populated with service names where there is a systemd.service.<name> defined from the names in server.database.postgres or server.database.redis.

To manually add a service bind to the database availability target, add it to the server.database.dependentServices option:

{
  server.database.dependentServices = [
    "my-service"
    "another-service"
  ];
}

Services listed here will:

• Start only when io-databases.target is active
• Stop when io-databases.target stops
• Restart when the target restarts

Systemd Units

On Client Servers

On nixio

Troubleshooting

Checking Guardian Status

On client servers:

systemctl status io-guardian.service
systemctl status io-databases.target
systemctl status wait-for-io-databases.service
journalctl -u io-guardian.service -f

On IO Hosts:

systemctl status io-database-coordinator.service
journalctl -u io-database-coordinator.service

Manual Commands

To manually start dependent services on a client:

systemctl start io-databases.target

To manually stop dependent services:

systemctl stop io-databases.target

Common Issues

Guardian server won’t start:

• Check that IO_GUARDIAN_PSK secret is properly configured
• Verify the sops decryption is working: cat /run/secrets/IO_GUARDIAN_PSK

Services not starting after boot:

• Check wait service logs: journalctl -u wait-for-io-databases.service
• Verify network connectivity to an IO Host on ports 5432 (Postgres) and 6379 (Redis)
• Ensure an IO Hosts coordinator has sent the undrain command

Authentication failures in logs:

• Ensure the same PSK is deployed to all servers
• Re-encrypt secrets if the key was changed

Protocol Reference

The guardian uses a simple JSON-based WebSocket protocol:

Authentication

// Client sends:
{"type": "auth", "key": "<psk>"}

// Server responds:
{"type": "auth", "status": "ok", "message": "Authentication successful"}
// or
{"type": "auth", "status": "error", "message": "Invalid key"}

Commands

// Coordinator sends:
{"type": "command", "action": "drain"}
// or
{"type": "command", "action": "undrain"}
// or
{"type": "command", "action": "ping"}

// Server responds:
{"type": "response", "action": "<action>", "status": "ok", "message": "..."}
// or
{"type": "response", "action": "<action>", "status": "error", "message": "..."}

Server Cluster Monitoring

The monitoring module provides a comprehensive observability stack for the server cluster using Prometheus (metrics), Loki (logs), Grafana (visualization), and Grafana Alloy for authenticated OTLP ingestion. All components are configured as reusable NixOS modules with automatic cross-host discovery.

Overview

The system consists of three layers:

1. Exporters (run on all servers)

   • node_exporter for system-level metrics (CPU, memory, disk, network, per-process stats)
   • Grafana Alloy for shipping journald logs and Caddy access logs to Loki
   • Caddy access logs are parsed as JSON at ingest time so detected_level, logger, and status are available in Loki
   • Ingest-time log parsing for journal stdout entries and Caddy access logs to infer detected_level and normalize common timestamp formats
   • Application-specific exporters (Caddy, PostgreSQL, Redis) enabled automatically
   • fail2ban exporter available on the IO primary host (when fail2ban is enabled)

2. Collectors (run on the monitoring primary host)

   • Prometheus for metrics aggregation with 90-day retention
   • Loki for log aggregation with 90-day retention
   • Alertmanager for alert routing and notifications
   • OTLP/HTTP ingestion on otlp.<domain> with bearer-token authentication

3. Visualization (runs on the monitoring primary host)

   • Grafana with provisioned datasources and dashboards
   • Native Kanidm OAuth2 authentication

Architecture

┌─────────────────────────────────────────────────────┐
│                    nixmon (Monitoring Primary)      │
│  ┌──────────┐  ┌──────┐  ┌─────────┐  ┌──────────┐  │
│  │Prometheus│  │ Loki │  │ Grafana │  │Alertmgr  │  │
│  │  :9090   │  │:3100 │  │  :3000  │  │  :9093   │  │
│  └────┬──┬──┘  └──┬───┘  └─────────┘  └────┬─────┘  │
│       │  │        │                        │        │
│  ┌────┘  │   ┌────┘        ┌───────────────┘        │
│  │ scrape│   │ push        │ webhooks               │
├──┼───────┼───┼─────────────┼────────────────────────┤
│  ▼       ▼   ▼             ▼                        │
│  All servers:          Home Assistant / Nextcloud   │
│  - node_exporter :9100                              │
│  - alloy → Loki                                     │
│  - OTLP/HTTP → Alloy :4318                          │
│  - caddy metrics :2019 (if proxy configured)        │
│  - fail2ban_exporter :9191 (if fail2ban enabled)    │
│  - postgres_exporter :9187 (if postgres configured) │
│  - redis_exporter :9121 (if redis configured)       │
│  - pve_exporter :9221 (nixmon only, Proxmox API)    │
└─────────────────────────────────────────────────────┘

Configuration

Enabling Monitoring

Monitoring is enabled by default on all servers (server.monitoring.enable = true). The monitoring primary host is configured via the allocations.server.monitoringPrimaryHost option, currently set to nixmon.

Options

server.monitoring.collector.alerting.enable

Whether to enable Alertmanager and alert rules.

server.monitoring.collector.alerting.homeAssistant.enable

Whether to enable Home Assistant webhook alerting.

server.monitoring.collector.alerting.nextcloudTalk.enable

Whether to enable Nextcloud Talk webhook alerting.

server.monitoring.collector.enable

Whether to enable monitoring collector services (Prometheus, Loki, Grafana).

server.monitoring.collector.grafana.kanidm.enable

Whether to enable Kanidm OAuth2 authentication for Grafana.

server.monitoring.collector.otlp.bearerTokenSecret

SOPS secret path used as the bearer token for OTLP/HTTP ingestion.

server.monitoring.collector.otlp.enable

Whether to enable OTLP/HTTP ingestion via Grafana Alloy.

server.monitoring.collector.otlp.port

Port for the OTLP/HTTP ingestion endpoint.

server.monitoring.collector.otlp.subdomain

Subdomain used for the OTLP/HTTP ingestion endpoint.

server.monitoring.collector.proxmox.enable

Whether to enable Proxmox VE metrics collection.

server.monitoring.enable

Whether to enable monitoring for this server.

server.monitoring.exporters.caddy.enable

Whether to enable Caddy metrics exporter.

server.monitoring.exporters.fail2ban.enable

Whether to enable fail2ban metrics exporter.

server.monitoring.exporters.node.enable

Whether to enable node_exporter for system-level metrics.

server.monitoring.exporters.postgres.enable

Whether to enable PostgreSQL exporter.

server.monitoring.exporters.process.enable

Whether to enable Process exporter for monitoring specific processes.

server.monitoring.exporters.redis.enable

Whether to enable Redis exporter.

server.monitoring.logs.enable

Whether to enable Alloy log shipping.

server.monitoring.logs.extraConfiguration

Additional configuration for the alloy log processor. This is useful for adding custom Loki stages, relabeling rules, or write targets.

Note that the default configuration for processing the system journal is always included and does not need to be specified here.

server.monitoring.retention.logs

Loki log retention period.

server.monitoring.retention.metrics

Prometheus TSDB retention period.

server.monitoring.scrapeConfigs

Declarative scrape configs for services running on this host. These are collected by the monitoring primary host and converted into Prometheus scrape configurations.

server.monitoring.scrapeConfigs.<name>.bearer_token_secret

SOPS secret path for bearer token authentication. When set, the secret will be created on the monitoring primary host.

server.monitoring.scrapeConfigs.<name>.host

Host to scrape metrics from.

server.monitoring.scrapeConfigs.<name>.job_name

Prometheus job name for this scrape target.

server.monitoring.scrapeConfigs.<name>.metrics_path

HTTP path to the metrics endpoint.

server.monitoring.scrapeConfigs.<name>.port

Port the metrics endpoint listens on.

server.monitoring.scrapeConfigs.<name>.scheme

URL scheme for scraping.

Auto-Detection

The module automatically detects and enables exporters based on host role:

• Caddy exporter: Enabled when server.proxy.virtualHosts is non-empty
• PostgreSQL exporter: Enabled on the IO primary host when postgres databases are configured
• Redis exporter: Enabled on the IO primary host when redis instances are configured
• Caddy access logs: Enabled when Caddy metrics/logs are enabled; each access log file under /var/log/caddy-access-* is shipped to Loki and parsed as JSON
• node_exporter process collector: Enabled on all servers via the processes collector to expose per-process stats
• fail2ban exporter: Enabled on the IO primary host when fail2ban intrusion detection is enabled
• Collector services: Enabled only on the monitoring primary host

Secrets

The monitoring module requires the following secrets in hosts/server/nixmon/secrets.yaml:

MONITORING:
  OLTP:
    BEARER_TOKEN: <random-secret-key>
  GRAFANA:
    SECRET_KEY: <random-secret-key>
    OAUTH_SECRET: <kanidm-oauth2-secret>
  HOME_ASSISTANT:
    WEBHOOK_URL: <ha-webhook-url>
  NEXTCLOUD_TALK:
    WEBHOOK_URL: <nc-talk-webhook-url>
PROXMOX:
  USER: <proxmox-user-at-realm>
  TOKEN_ID: <proxmox-token-name>
  TOKEN_SECRET: <proxmox-token-secret>

Generating Secrets

Generating secure random secrets can be done with the following command:

cat /dev/urandom | tr -dc 'A-Za-z0-9' | head -c 48

The MONITORING/GRAFANA/OAUTH_SECRET must match the value in hosts/server/nixcloud/secrets.yaml under KANIDM/OAUTH2/GRAFANA_SECRET (the Kanidm provisioning side).

Caddy Virtual Hosts

The module configures four virtual hosts on nixmon:

Grafana remains protected by the existing Kanidm-backed login flow. The OTLP ingestion endpoint is intended for machine-to-machine clients and requires an Authorization: Bearer <token> header on every request. The exposed OTLP/HTTP paths are the standard /v1/metrics and /v1/logs endpoints.

These are defined in hosts/server/nixmon/default.nix and collected by the IO primary host’s Caddy configuration.

Alert Rules

The following alerts are configured by default:

Alerts are routed to:

• Home Assistant: All critical and warning alerts via webhook (requires collector.alerting.homeAssistant.enable = true)
• Nextcloud Talk: Critical alerts only via webhook (requires collector.alerting.nextcloudTalk.enable = true)

Module Structure

modules/nixos/server/monitoring/
├── default.nix              # Entry point, imports sub-modules
├── options.nix              # All server.monitoring.* options
├── collector/
│   ├── default.nix          # Imports collector sub-modules
│   ├── prometheus.nix       # Prometheus server + scrape targets
│   ├── loki.nix             # Loki server + storage config
│   ├── grafana.nix          # Grafana + Kanidm OAuth2
│   ├── otlp.nix             # OTLP ingestion
│   ├── alerting.nix         # Alertmanager + alert rules
│   └── dashboards.nix       # Dashboard provisioning
├── exporters/
│   ├── default.nix          # Imports exporter sub-modules
│   ├── node.nix             # node_exporter
│   ├── caddy.nix            # Caddy metrics
│   ├── postgres.nix         # PostgreSQL exporter
│   ├── redis.nix            # Redis exporter
│   └── fail2ban.nix         # fail2ban metrics exporter
├── logs/
│   └── alloy.nix            # Alloy log shipping
└── integrations/
    └── proxmox.nix          # PVE exporter for Proxmox API

Troubleshooting

Checking Service Status

On the monitoring host (nixmon):

systemctl status prometheus.service
systemctl status loki.service
systemctl status grafana.service
systemctl status prometheus-alertmanager.service
systemctl status prometheus-pve-exporter.service

On any server:

systemctl status prometheus-node-exporter.service
systemctl status prometheus-fail2ban-exporter.service
systemctl status alloy.service

Verifying Metrics Collection

Check Prometheus targets are up:

curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {instance: .labels.instance, health: .health}'

Verifying Log Collection

Alloy applies ingest-time parsing for journal stdout logs and Caddy access logs before forwarding to Loki:

• Caddy access logs are read as JSON, not plain text

• Legacy timestamps in form YYYY/MM/DD HH:MM:SS are parsed and used as event timestamps

• ISO-8601 timestamps with a log level prefix are parsed and normalized

• detected_level defaults to info when the source log line does not provide one

• Caddy JSON fields level, ts, logger, and status are extracted into Loki labels and timestamps

• Caddy access logs are read from /var/log/caddy-access-*.log and use the timestamp and level prefix in each line when present

node_exporter also enables the processes collector, which exposes per-process metrics such as CPU and memory usage for running processes.

Check Alloy is shipping logs:

journalctl -u alloy.service -f

Query Loki directly:

curl -s 'http://localhost:3100/loki/api/v1/labels' | jq

Common Issues

Grafana OAuth login fails:

• Verify GRAFANA_OAUTH_SECRET in nixmon matches KANIDM/OAUTH2/GRAFANA_SECRET in nixcloud
• Check Kanidm provisioning has the grafana OAuth2 client configured
• Verify DNS resolves auth.<domain> correctly

Prometheus targets showing as down:

• Check firewall rules allow traffic on exporter ports from the monitoring host
• Verify the exporter service is running on the target host
• Check network connectivity between nixmon and the target host

Proxmox metrics missing:

• Verify proxmox/token_id and proxmox/token_secret are valid
• Check PVE API is accessible from nixmon: curl -k https://pve.<domain>/api2/json
• Review PVE exporter logs: journalctl -u prometheus-pve-exporter.service

Creating New Users

To add a new user configuration:

1. Create User Directory

mkdir -p home/newuser

2. Create User Configuration Files

Create host-specific configurations in home/newuser/{hostname}.nix:

{ pkgs, lib, ... }:
{
  imports = [
    # Import shared configurations
    ./features/cli              # Common CLI tools
    ./features/desktop/common   # Desktop environment basics
  ];

  # User-specific configuration
  home = {
    username = "newuser";
    homeDirectory = "/home/newuser";
    stateVersion = "25.05";
  };

  # Add user-specific packages and configuration
  programs = {
    git = {
      userName = "Your Name";
      userEmail = "your.email@domain.com";
    };
  };
}

Create feature modules in home/newuser/features/:

mkdir -p home/newuser/features/{cli,desktop,development}

3. Link User to Hosts

The auto-discovery system will automatically link users to hosts if:

• A file home/{username}/{hostname}.nix exists
• The hostname matches an existing host configuration

4. Test User Configuration

# Build home-manager configuration
home-manager build --flake .#newuser@hostname

# Switch to new configuration
home-manager switch --flake .#newuser@hostname

Creating New Hosts

To add a new host to your configuration:

1. Create Host Directory Structure

# For a new desktop host named "mydesktop"
mkdir -p hosts/desktop/mydesktop

# For a new server host named "myserver"
mkdir -p hosts/server/myserver

# For a new laptop host named "mylaptop"
mkdir -p hosts/laptop/mylaptop

2. Create Required Configuration Files

Create hosts/{device-type}/{hostname}/default.nix:

{ self, pkgs, ... }:
{
  imports = [
    # Hardware configuration (required)
    ./hardware.nix

    # Optional: device-specific modules
    # "${self}/hosts/shared/optional/containers.nix"
    # "${self}/modules/nixos/custom-module.nix"
  ];

  # Host-specific configuration
  host = {
    device.isHeadless = false; # Set to true for servers
  };

  # Add your system configuration here
  # networking.hostName is automatically set from directory name
}

Create hosts/{device-type}/{hostname}/hardware.nix:

{ inputs, ... }:
{
  imports = [
    # Include relevant hardware modules
    inputs.nixos-hardware.nixosModules.common-cpu-amd
    inputs.nixos-hardware.nixosModules.common-pc-ssd

    # For laptops, also include:
    # inputs.nixos-hardware.nixosModules.common-pc-laptop
  ];

  # Boot configuration
  boot.loader = {
    systemd-boot.enable = true;
    efi.canTouchEfiVariables = true;
  };

  # Filesystem configuration (use disko for declarative disk setup)
  fileSystems."/" = {
    device = "/dev/disk/by-label/nixos";
    fsType = "ext4";
  };

  # Add hardware-specific configuration
}

3. Add Hardware Acceleration (Optional)

If your host supports hardware acceleration, add it to the acceleration lists in flake.nix:

accelerationHosts = {
  cuda = [
    "your-new-host"  # Add here for CUDA support
  ];
  rocm = [
    "your-amd-host"  # Add here for ROCm support
  ];
};

4. Build and Test

# Build the configuration (don't switch yet)
sudo nixos-rebuild build --flake .#your-new-host

# Test the configuration
sudo nixos-rebuild test --flake .#your-new-host

# Switch to the new configuration
sudo nixos-rebuild switch --flake .#your-new-host

Using a Nix Package or NixOS Module from a Separate Fork of Nixpkgs

This guide will show you how to use a Nix package or NixOS module from a separate fork of nixpkgs.

Step 1: Define the Forked Repository

In your Nix file, define the forked repository using fetchFromGitHub function:

nixpkgs.overlays = [
  (self: super: {
    <your-package> = (import
      (pkgs.fetchzip (
        let owner = "<owner>"; branch = "<branch>"; in {
          url = "https://github.com/${owner}/nixpkgs/archive/${branch}.tar.gz";
          # Change to 52 zeros when archive needs to be redownloaded.
          sha256 = "<sha256>";
        }
      ))
      { overlays = [ ]; config = super.config; }).<your-package>;
  })
];

In this example, replace <your-package>, <owner>, <branch>, and <sha256> with the actual values from the forked repository.

Step 2: Use Packages or Modules from the Forked Repository

Now you can use packages or modules from the forked repository in your Nix expressions. For example, if you want to use a package from the forked repository, you can refer to it using the <your-package> attribute. Here’s an example:

{
  environment.systemPackages = with pkgs; [
    <your-pckage>
  ];
}

In this example, replace <your-package with the actual name of the package you want to use.

Declarative Gnome Dconf

Description

When changing GNOME or GNOME extension settings, it is recommended to use dconf2nix and cherry pick its output. This allows for easy configuration using the GUI, but requires copying the settings back into the respective dconf settings in home-manager to save them.

DConf Locations

The locations for where to save DConf settings to is:

• Base.nix for standard GNOME DConf Settings.
• Extensions.nix for Extensions DConf Settings
• Per User Settings should be saved in the format of home/${username}/desktop/gnome.nix

Getting the Output

dconf2nix will be installed as part of this flakes dev shell.

Running the following will output the current dconf settings into a temporary file so you can Cherry Pick your changes.

dconf dump / | dconf2nix > dconf.nix

Using a Package/Module from a Fork

Modules Overview

Purpose

This section provides an overview of the custom NixOS and Home-Manager modules defined in this repository. These modules allow for modular and reusable configurations across different hosts and users.

Entry Points

• modules/nixos/: Contains NixOS-specific modules.
  • Core Module
    • Display Manager
    • Remote Desktop & Streaming
    • Virtualisation
  • Server Module
    • Dashboard Module
    • Network Module
    • Distributed Builds Module
    • Database Module
    • Storage Module
    • Proxy Module
    • SSH Module
  • Services
    • AI Agent
    • Huntress
    • MCPO
    • Metrics
    • Tailscale
• modules/flake/: Flake-level modules for cross-host configuration.
  • Flake Allocations
• modules/home-manager/: Contains Home-Manager-specific modules.
  • Programs
    • list-ephemeral
  • DIY & Making
  • AI Editors & Assistants
  • Hyprland

NixOS Modules

This section covers all NixOS modules provided by this flake.

NixOS Services

This section documents the custom NixOS service modules available in this configuration. These modules provide specialised integrations and monitoring capabilities.

Nested service modules emit generated fragments such as services-ai-agent-options.md.

AI Agent

AI Agent

Autonomous AI Agent service powered by Hermes, providing intelligent task automation with security controls for code review and development tasks.

• Entry point: modules/nixos/services/ai-agent.nix
• Upstream: Hermes Agent
• Package: The module routes services.hermes-agent.package through the local pkgs.hermes-agent overlay, which carries the lazy-deps managed-install fix from PR #48637. This ensures Hermes fails fast with FeatureUnavailable on read-only NixOS installs rather than retrying ensurepip.

Options

services.ai-agent.apiServer.enable

Whether to enable the OpenAI comptable endpoint.

services.ai-agent.apiServer.host

The host/IP for the API server to bind to.

services.ai-agent.apiServer.port

The port for the API server to listen on.

services.ai-agent.apiServer.tokenReference

The sops secret attribute for the API server authentication token.

services.ai-agent.containerPostStart

Shell commands to run inside the AI agent container after startup.

A plain string runs inside the container as root via docker exec. An attrset { command = "..."; host = true; } runs on the host.

Commands to run after the AI agent container starts. Container commands get automatic retry to wait for Docker + container readiness.

services.ai-agent.dashboard.enable

Whether to enable Hermes web dashboard.

services.ai-agent.dashboard.oidc.clientId

The OIDC client ID for dashboard authentication.

services.ai-agent.dashboard.oidc.enable

Whether to enable OpenID Connect authentication for the dashboard.

services.ai-agent.dashboard.oidc.issuer

The OIDC issuer URL for dashboard authentication.

services.ai-agent.dashboard.oidc.provider

The OIDC plugin to use for dashboard authentication.

services.ai-agent.dashboard.oidc.scopes

The OIDC scopes to request for dashboard authentication.

services.ai-agent.dashboard.port

The port for the dashboard to listen on.

services.ai-agent.dashboard.publicURL

The public URL for the dashboard, used for generating links in notifications and similar. If not set, localhost URLs will be used.

If set, must be a valid URL starting with http:// or https://.

services.ai-agent.enable

Whether to enable autonomous AI Agent service.

services.ai-agent.extras.plugins

Whether to enable enable extra plugins for the agent.

services.ai-agent.memory.enable

Whether to enable long-term memory

When enabled this disables the builtin user profile and memory markdown features, to nudge the agent towards using the configured long-term memory provider for all memory. .

services.ai-agent.models.brains

The smartest model to use for complex reasoning and decision-making tasks.

Used for auxiliary models:

services.ai-agent.models.compression

The model to use for compression of context, summorisation and similar tasks that don’t require reasoning. This model still needs a decently sized context window to be effective.

Used for auxiliary models:

services.ai-agent.models.primary

The primary language model to use for the AI agent.

services.ai-agent.models.provider

The model provider to use.

services.ai-agent.models.simpleton

The simpleton model to delegate tasks to that require less reasoning, basic understanding and small context windows.

Used for auxiliary models:

services.ai-agent.models.vision

The vision model to delegate image understanding tasks to.

services.ai-agent.platform.discord.allowedUsers

A list of Discord user IDs that the agent is allowed to interact with.

services.ai-agent.platform.discord.enable

Whether to enable Discord as a messaging channel.

services.ai-agent.platform.discord.homeChannel

The Discord channel ID to use as the home channel for the agent.

services.ai-agent.platform.discord.tokenReference

The sops secret attribute for the Discord bot token.

services.ai-agent.platform.hassio.enable

Whether to enable Home Assistant as a tool and notification channel.

services.ai-agent.platform.hassio.tokenReference

The sops secret attribute for the Home Assistant long-lived access token.

services.ai-agent.platform.hassio.url

The URL for the Home Assistant instance, including the scheme.

services.ai-agent.platform.webhook.port

The port for the webhook listener to listen on.

services.ai-agent.voice.enable

Whether to enable voice input and output using the TTS and STT.

services.ai-agent.voice.wyoming-stt.enable

Whether to enable use existing Wyoming faster-whisper server for STT instead of running a separate Whisper instance.

services.ai-agent.voice.wyoming-stt.host

The host of the Wyoming faster-whisper server.

services.ai-agent.voice.wyoming-stt.port

The port of the Wyoming faster-whisper server.

Secrets Management

Hermes requires API keys via environment files. Configure via sops-nix:

sops = {
  secrets = {
    "AI_AGENT/OPENROUTER_API_KEY" = { };
  };
  templates."HERMES_ENV".content = ''
    OPENROUTER_API_KEY=${config.sops.placeholder."AI_AGENT/OPENROUTER_API_KEY"}
  '';
};

services.hermes-agent.environmentFile = config.sops.templates."HERMES_ENV".path;

Usage Example

{ ... }: {
  services.ai-agent = {
    enable = true;
  };
}

Voice & STT

Enable voice input and output with services.ai-agent.voice.enable = true;.

Wyoming STT (Reuse Existing Server)

Instead of running a separate Whisper instance inside the Hermes container, you can point Hermes at an existing Wyoming faster-whisper server (e.g. the one already running on nixai at port 10300):

{ ... }: {
  services.ai-agent = {
    enable = true;
    voice = {
      enable = true;
      wyoming-stt.enable = true;
    };
  };
}

This sets HERMES_LOCAL_STT_COMMAND to invoke wyoming-transcribe, which sends audio over the Wyoming protocol to the faster-whisper server and returns the transcript. No second Whisper process needed.

Dashboard Service

Enable the web dashboard with services.ai-agent.dashboard.enable = true;.

This adds a separate hermes-dashboard systemd service that runs docker exec into the hermes-agent container to serve the dashboard under the hermes user. Environment files configured via services.hermes-agent.environmentFiles are loaded by systemd’s EnvironmentFile directive (read as root) and passed into the container via docker exec --env-file. The dashboard stays local by default and does not open a browser.

OIDC Authentication

Enable OpenID Connect authentication for the dashboard with services.ai-agent.dashboard.oidc.enable = true;.

The dashboard uses a public PKCE client (no client_secret). The client ID is a public identifier — it does not need to be stored as a secret.

{ ... }: {
  services.ai-agent = {
    enable = true;
    dashboard = {
      enable = true;
      publicURL = "https://dashboard.example.com";
      oidc = {
        enable = true;
        provider = "self-hosted";
        issuer = "https://auth.example.com/oauth2/openid/hermes";
        clientId = "hermes";
        scopes = [ "openid" "profile" "email" ];
      };
    };
  };
}

The module generates a HERMES_DASHBOARD_OIDC_ENV environment file with the OIDC settings, which is loaded by the hermes-dashboard service.

Memory (Mnemosyne)

Enable long-term memory with services.ai-agent.memory.enable = true;. This switches the memory provider from the built-in user profile (USER.md injection) to Mnemosyne, a local SQLite-backed memory system with semantic recall.

{ ... }: {
  services.ai-agent = {
    enable = true;
    memory.enable = true;
  };
}

Database location: /home/hermes/mnemosyne.db (SQLite with FTS5 hybrid ranking + vector search).

Huntress

Huntress

Managed EDR (Endpoint Detection and Response) platform that protects systems by detecting malicious footholds used by attackers.

• Entry point: modules/nixos/services/huntress.nix
• Upstream: Huntress Managed EDR

Options

services.huntress.accountKeyFile

The account key for the Huntress agent.

services.huntress.enable

Whether to enable Huntress service.

services.huntress.organisationKeyFile

The organisation key for the Huntress agent.

services.huntress.package

The Huntress package to use.

Usage Example

{ config, ... }: {
  services.huntress = {
    enable = true;
    accountKeyFile = config.sops.secrets.huntress_account_key.path;
    organisationKeyFile = config.sops.secrets.huntress_org_key.path;
  };
}

Operational Notes

The agent configuration is generated at /etc/huntress/agent_config.yaml during the service’s preStart phase. It merges the provided account and organisation keys using yaml-merge. The keys are securely loaded into the service using systemd LoadCredential.

MCPO

MCPO (Model Context Protocol Orchestrator)

Orchestrates Model Context Protocol (MCP) servers, providing a centralized way to manage and expose multiple MCP servers.

• Entry point: modules/nixos/services/mcpo.nix
• Upstream: MCPO GitHub Repository

Options

services.mcpo.apiTokenFile

Path to a file containing the API token for the mcpo service. This file will be exposed to the service through a systemd credential named “apiToken”.

services.mcpo.configuration

This option has no description.

services.mcpo.configuration.<name>.args

Arguments to pass to the command.

services.mcpo.configuration.<name>.command

Command to render the config file.

services.mcpo.configuration.<name>.headers

Headers to pass to the command.

services.mcpo.configuration.<name>.type

This option has no description.

services.mcpo.configuration.<name>.url

This option has no description.

services.mcpo.enable

Whether to enable mcpo (Model Context Protocol Orchestrator) service.

services.mcpo.environment

Additional environment variables for the service.

services.mcpo.extraPackages

Additional packages to include in the service’s PATH.

services.mcpo.helpers

Helper functions for constructing mcpo server command blocks.

services.mcpo.package

Package providing the mcpo executable.

Usage Example

{ config, ... }: {
  services.mcpo = {
    enable = true;
    configuration = {
      everything = config.services.mcpo.helpers.npxServer "@modelcontextprotocol/server-everything";
    };
  };
}

Operational Notes

MCPO runs as a DynamicUser with a state directory at /var/lib/mcpo. The configuration is rendered via sops.templates and loaded into the service via systemd credentials. The service’s PATH includes bash, nodejs, and uv by default to support various MCP server types.

Package Patches

• mcpo-union-repr-compat.patch — Applied via overlay in overlays/patches/. Upstream test src/mcpo/tests/test_main.py asserts Union repr starts with "typing.Union[", but Python 3.12+ may stringify unions as str | float. Patch uses get_origin(result_type) is Union instead. Build/test compatibility only; no runtime impact.

Metrics

Metrics & Hacompanion

Comprehensive metrics collection and integration with Home Assistant via hacompanion.

• Entry point: modules/nixos/services/metrics.nix
• Upstream: Hacompanion GitHub Repository

Options

services.metrics.enable

Whether to enable Metrics collection service.

services.metrics.hacompanion.enable

Whether to enable Enable Home Assistant Companion service.

services.metrics.hacompanion.script

This option has no description.

services.metrics.hacompanion.script.<name>.device_class

The device class for the script in Home Assistant.

services.metrics.hacompanion.script.<name>.icon

The icon to use for the script in Home Assistant.

services.metrics.hacompanion.script.<name>.name

The name of the script as it will appear in Home Assistant.

services.metrics.hacompanion.script.<name>.path

The path to the script to execute.

services.metrics.hacompanion.script.<name>.type

The type of the script in Home Assistant.

services.metrics.hacompanion.script.<name>.unit_of_measurement

The unit of measurement for the script in Home Assistant.

services.metrics.hacompanion.sensor.audio_volume.enable

Whether to enable Enable the audio_volume sensor.

services.metrics.hacompanion.sensor.companion_running.enable

Whether to enable Enable the companion_running sensor.

services.metrics.hacompanion.sensor.cpu_temp.enable

Whether to enable Enable the cpu_temp sensor.

services.metrics.hacompanion.sensor.cpu_usage.enable

Whether to enable Enable the cpu_usage sensor.

services.metrics.hacompanion.sensor.load_avg.enable

Whether to enable Enable the load_avg sensor.

services.metrics.hacompanion.sensor.memory.enable

Whether to enable Enable the memory sensor.

services.metrics.hacompanion.sensor.online_check.enable

Whether to enable Enable the online_check sensor.

services.metrics.hacompanion.sensor.power.enable

Whether to enable Enable the power sensor.

services.metrics.hacompanion.sensor.uptime.enable

Whether to enable Enable the uptime sensor.

services.metrics.hacompanion.sensor.webcam.enable

Whether to enable Enable the webcam sensor.

services.metrics.hacompanion.storage

Storage devices and ZFS pools to monitor

services.metrics.hacompanion.storage.<name>.name

The pretty display name for this storage device in Home Assistant.

services.metrics.hacompanion.storage.<name>.sensors.avail

Whether to enable Enable available space sensor.

services.metrics.hacompanion.storage.<name>.sensors.read

Whether to enable Enable read speed sensor.

services.metrics.hacompanion.storage.<name>.sensors.temperature

Whether to enable Enable temperature sensor.

services.metrics.hacompanion.storage.<name>.sensors.used

Whether to enable Enable used space sensor.

services.metrics.hacompanion.storage.<name>.sensors.write

Whether to enable Enable write speed sensor.

services.metrics.hacompanion.test

This option has no description.

services.metrics.upgradeStatus.enable

Whether to enable Enable Upgrade Status service.

services.metrics.upgradeStatus.uptimeKuma.enable

Whether to enable Enable Uptime Kuma tracking for Upgrade Status.

Usage Example

{ ... }: {
  services.metrics.hacompanion = {
    enable = true;
    sensor.cpu_temp.enable = true;
    sensor.memory.enable = true;
    storage.main = {
      name = "Main OS Drive";
      sensors.used = true;
    };
  };
}

Operational Notes

Hacompanion uses a generated TOML configuration file and securely loads the Home Assistant API token from sops.secrets.HACOMPANION_ENV. The upgradeStatus feature can also integrate with Uptime Kuma to provide heartbeat notifications for successful system upgrades.

Tailscale

Tailscale

Extensions to the standard NixOS Tailscale module, providing easier tag management.

• Entry point: modules/nixos/services/tailscale.nix

Options

services.tailscale.tags

Additional tags to advertise for this device.

Tags are used for access control and routing in Tailscale. See https://tailscale.com/kb/1018/tags/ for more information.

Usage Example

{ ... }: {
  services.tailscale = {
    enable = true;
    tags = [ "server" "internal" ];
  };
}

Operational Notes

This module simplifies the application of Tailscale tags by automatically constructing the --advertise-tags flag. Ensure that the device has the necessary permissions in your Tailscale ACLs to apply the requested tags.

Core Module

Documents shared NixOS core modules used across hosts.

Purpose

modules/nixos/core/ contains reusable host-level defaults and feature modules.

It also defines top-level baseline options under core.* that control this shared behavior for most hosts.

Options

core.activation.enable

Whether to enable report diff on activation.

core.audio.enable

Whether to enable Enable audio support.

core.auto-upgrade.enable

Whether to enable auto-upgrade.

core.auto-upgrade.hostName

The hostName to use for auto-upgrade

core.bluetooth.enable

Whether to enable Enable Bluetooth support.

core.containers.enable

Whether to enable container support.

core.defaultGroups

Additional groups to add all users to by default.

core.display-manager.enable

Whether to enable display manager configuration.

core.enable

Whether to enable Enable core features.

core.gaming.enable

Whether to enable Enable gaming features.

core.generators.enable

Whether to enable generators configuration.

core.generators.proxmoxLXC.clearPath

Clear binary to use for clearing the screen when asking the user for the SSH private key

core.generators.proxmoxLXC.enable

Whether to enable Proxmox LXC generator configuration.

core.generators.proxmoxLXC.sedPath

Sed package to use for validating the SSH private key provided by the user

core.generators.proxmoxLXC.sshKeygenPath

SSH package to use for validating the SSH private key provided by the user

core.hm-helper._1password.enableCli

Whether to enable Enable 1Password Cli support.

core.hm-helper._1password.enableGUI

Whether to enable Enable 1Password GUI support.

core.hm-helper.enable

Whether to enable Home Manager helper functions.

core.hm-helper.ff2mpv.enable

Whether to enable Enable ff2mpv native messaging host for Firefox..

core.hm-helper.hmUsers

List of Home Manager users that also exist in config.users.users.

core.hm-helper.kde-connect.enable

Whether to enable Enable KDE Connect firewall rules if any user has KDE Connect enabled..

core.hm-helper.nautilus.enable

Whether to enable Enable Nautilus extensions and integration helpers..

core.locale.enable

Whether to enable locale configuration.

core.network.enable

Whether to enable Enable network support.

core.networking.enable

Whether to enable opinionated networking defaults.

core.networking.tailscale.enable

Whether to enable tailscale configuration.

core.openssh.enable

Whether to enable OpenSSH server and client opinionated configuration.

core.printing.enable

Whether to enable printing support.

core.remote.enable

Whether to enable remote features.

core.remote.remoteDesktop

This option has no description.

core.remote.remoteDesktop.enable

Whether to enable remote desktop.

core.remote.remoteDesktop.startCommand

Command to start remote desktop session.

core.remote.streaming

This option has no description.

core.remote.streaming.enable

Whether to enable remote streaming.

core.security.enable

Whether to enable security features.

core.security.userLimit

The maximum number of open files per user.

This is used to set the limits for both PAM and systemd.

core.sops.enable

Whether to enable SOPS auto configuration.

core.sops.hostSecretsFile

Where the SOPS secret file of this host is located in the flake.

core.stylix.enable

Whether to enable Stylix configuration.

core.virtualisation.bridgeInterface

Bridge interface used for libvirt networking.

core.virtualisation.cpuCores

Total CPU core/thread count used for isolation helpers. Must be >= 4.

core.virtualisation.enable

Whether to enable virtualisation support.

core.virtualisation.externalInterface

Physical interface attached to bridge.

core.virtualisation.gpu.audio

PCI address for passthrough GPU audio device.

core.virtualisation.gpu.video

PCI address for passthrough GPU video device.

core.virtualisation.isolatedGuests

List of guests to apply isolation helpers to.

core.virtualisation.vmUsers

Users that should receive kvm and libvirtd group membership for VM management.

core.wsl.enable

Whether to enable WSL specific configurations, optimisations, and fixes.

core.wsl.user

The default user to use for WSL.

Baseline Behaviour

When core.enable is true, module applies shared defaults from modules/nixos/core/default.nix:

• sets services.dbus.implementation = "broker",
• enables PipeWire audio stack and disables PulseAudio when core.audio.enable is on,
• enables Bluetooth stack, Blueman, and persisted Bluetooth state when core.bluetooth.enable is on,
• enables NetworkManager and adds network to shared default groups when core.network.enable is on, and
• on non-headless hosts, adds video and i2c groups and enables dleyna, gnome-keyring, udisks2, colord, xserver.updateDbusEnvironment, and polkit.

Audio baseline also enables security.rtkit, adds audio, pipewire, and rtkit groups, installs udev rules for rtc0 and hpet, and sets PAM limits for realtime audio workloads.

Bluetooth baseline unblocks rfkill during activation and persists /var/lib/bluetooth.

Key Pages

• Activation
• Auto Upgrade
• Containers
• Display Manager
• Gaming
• Generators
• Default Groups
• Locale
• Nix
• OpenSSH
• Printing
• Remote Access
• Security
• SOPS
• Stylix
• Virtualisation
• WSL

Usage Example

{ ... }: {
  core = {
    enable = true;
    audio.enable = true;
    bluetooth.enable = true;
    network.enable = true;
  };
}

Notes

These modules are imported through modules/nixos/core/default.nix. Most feature pages document their own core.<name> option namespaces, while some baseline modules such as Nix apply unconditionally once imported.

Activation

Reports system generation changes during NixOS activation.

• Entry point: activation.nix

Overview

This module adds activation-time diff reporting with nvd. During activation it compares previous and new system generations and prints package and closure changes.

Options

core.activation.enable

Whether to enable report diff on activation.

Behaviour

When enabled, module installs system.activationScripts.report-changes that:

• finds previous and newest system profile links under /nix/var/nix/profiles,
• resolves both links to store paths, and
• runs nvd diff between them.

If no previous generation exists yet, script does nothing.

Usage Example

{ ... }: {
  core.activation.enable = true;
}

Operational Notes

• Diff output is informational only. Script ends with || true, so activation does not fail if nvd diff returns non-zero.
• Default follows top-level core.enable, so most hosts get generation diff reporting automatically.

Auto Upgrade

Schedules automatic NixOS upgrades from flake host outputs.

• Entry point: auto-upgrade.nix

Overview

This module configures system.autoUpgrade to rebuild host from github:DaRacci/nix-config#<host>. It also applies resource limits to nixos-upgrade.service so scheduled upgrades run with lower CPU and IO priority.

Options

core.auto-upgrade.enable

Whether to enable auto-upgrade.

core.auto-upgrade.hostName

The hostName to use for auto-upgrade

Behaviour

When enabled, module configures:

• system.autoUpgrade.dates = "04:00",
• randomizedDelaySec = "45min" to spread out upgrade times across hosts,
• flags --refresh, --accept-flake-config, and --no-update-lock-file,
• service resource controls for nixos-upgrade.service.

Auto-upgrade itself only turns on when flake has self.rev, meaning repository is in clean revisioned state.

Usage Example

{ ... }: {
  core.auto-upgrade = {
    enable = true;
    hostName = "my-host";
  };
}

Operational Notes

• Dirty working trees or non-revisioned evaluations leave system.autoUpgrade.enable = false.
• Module always points upgrades at GitHub flake source, not local checkout.
• Resource limits set CPUWeight = 20, CPUQuota = 65%, and IOWeight = 20 on upgrade service.

Containers

Enables Docker-based container runtime defaults.

• Entry point: containers.nix

Overview

This module turns on Docker as primary container backend and configures OCI containers to use Docker. It also enables weekly image pruning and persists Docker state directories.

Options

core.containers.enable

Whether to enable container support.

Behaviour

When enabled, module:

• enables virtualisation.docker,
• sets virtualisation.docker.package = pkgs.docker,
• enables CDI support with daemon.settings.features.cdi = true,
• enables weekly docker autoPrune,
• sets virtualisation.oci-containers.backend = "docker",
• adds docker to core.defaultGroups, and
• persists Docker state under /var/lib/docker.

Persisted directories include overlay2, image, volumes, containers, containerd, and buildkit.

Usage Example

{ ... }: {
  core.containers.enable = true;
}

Operational Notes

• Module intentionally prefers Docker because current workloads still need features not covered by Podman or podman-compose.
• Users receive Docker access through shared core.defaultGroups handling.

Display Manager

Configures display manager for graphical sessions on desktop and laptop hosts.

• Entry point: display-manager.nix

Overview

This module sets up greetd with tuigreet as default display manager. It is automatically enabled on hosts where host.device.isHeadless = false.

When session packages are present in services.displayManager.sessionPackages, module also passes both Wayland and X session directories to tuigreet.

Options

core.display-manager.enable

Whether to enable display manager configuration.

Behaviour

When enabled, greetd starts with tuigreet providing terminal-based greeter that:

• shows current time with --time,
• remembers last logged-in user with --remember,
• remembers last selected session with --remember-session, and
• adds --sessions and --xsessions only when services.displayManager.sessionPackages is non-empty.

Greeter cache is persisted to /var/cache/tuigreet through host.persistence.directories.

Usage Example

{ ... }: {
  services.displayManager.sessionPackages = [
    pkgs.hyprland
  ];

  core.display-manager.enable = true;
}

Operational Notes

• greetd runs as greeter user.
• Both Wayland (wayland-sessions) and X11 (xsessions) session paths are built dynamically from installed session packages, so adding new session package is enough to make it appear in greeter.

Gaming

Enables gaming, VR, and Steam-focused desktop features.

• Entry point: gaming.nix

Overview

This module configures desktop gaming stack around Steam, 32-bit graphics support, Android ADB tools, and WiVRn streaming. It also adds firewall rules, udev rules for common gaming devices, and optional Decky Loader lifecycle integration.

Options

purpose.gaming.controllerSupport

Whether to enable controller support.

purpose.gaming.enable

Whether to enable Gaming support base..

purpose.gaming.minecraft.enable

Whether to enable Enable Minecraft support.

purpose.gaming.modding.enable

Whether to enable Enable modding support.

purpose.gaming.modding.enableBeatSaber

Whether to enable Enable beatsaber modding support.

purpose.gaming.modding.enableSatisfactory

Whether to enable Enable satisfactory modding support.

purpose.gaming.modding.enableThunderstore

Whether to enable Enable thunderstore support.

purpose.gaming.osu.enable

Whether to enable OSU!.

purpose.gaming.osu.lazerPackages

The package to install for OSU! Lazer

purpose.gaming.roblox.enable

Whether to enable Enable Roblox launcher.

purpose.gaming.roblox.vinegarPackage

The package to use for Vinegar

purpose.gaming.simulator.enable

Whether to enable Enable simulator support.

purpose.gaming.simulator.enableRacing

Whether to enable Enable Moza Racing.

purpose.gaming.steam.enable

Whether to enable Steam.

purpose.gaming.vr.enable

Whether to enable Enable VR support.

purpose.gaming.minecraft.enable

Whether to enable Enable Minecraft support.

purpose.gaming.modding.enable

Whether to enable Enable modding support.

purpose.gaming.modding.enableBeatSaber

Whether to enable Enable beatsaber modding support.

purpose.gaming.modding.enableSatisfactory

Whether to enable Enable satisfactory modding support.

purpose.gaming.modding.enableThunderstore

Whether to enable Enable thunderstore support.

purpose.gaming.osu.enable

Whether to enable OSU!.

purpose.gaming.osu.lazerPackages

The package to install for OSU! Lazer

purpose.gaming.roblox.enable

Whether to enable Enable Roblox launcher.

purpose.gaming.roblox.vinegarPackage

The package to use for Vinegar

purpose.gaming.simulator.enable

Whether to enable Enable simulator support.

purpose.gaming.simulator.enableRacing

Whether to enable Enable Moza Racing.

purpose.gaming.steam.enable

Whether to enable Steam.

purpose.gaming.vr.enable

Whether to enable Enable VR support.

Behaviour

When enabled, module:

• adds adbusers to core.defaultGroups,
• enables hardware.steam-hardware,
• enables 32-bit graphics support,
• installs pkgs.android-tools,
• enables Steam with Steam Deck style launch arguments,
• enables programs.steam.extest,
• adds pkgs.xwayland-run and pkgs.xwininfo as Steam extra packages,
• adds pkgs.proton-ge-bin as compatibility package,
• opens Steam Remote Play and local transfer firewall rules,
• enables services.wivrn with highPriority, steam.importOXRRuntimes, firewall access, and JSON config, and
• installs udev rules for PlayStation controller, Oculus Quest, and tty ACM devices.

It also overlays gamescope-session to use 4K resolution and wider refresh limits, and opens firewall ports UDP 41492, 9943, 9944 plus TCP 8082, 9943, 9944, and 24070.

Decky Loader Integration

If config.jovian.decky-loader.enable is true, module additionally:

• prevents decky-loader.service from auto-starting at boot,
• adds Polkit rule so active local user can start and stop decky-loader.service, and
• when Home Manager is present, installs user service that polls Steam PID file, starts Decky Loader once Steam is running, and stops it after Steam exits.

Usage Example

{ ... }: {
  core.gaming.enable = true;
}

WiVRn Socket Activation

WiVRn is activated on-demand through systemd user socket activation instead of running for the full session.

• systemd.user.sockets.wivrn listens on %t/wivrn/comp_ipc (UNIX socket, mode 0770).
• Socket is WantedBy=default.target, so it’s available throughout the session, but WiVRn itself only starts when a client connects.
• Service env override: IPC_EXIT_ON_DISCONNECT=on — WiVRn exits after client disconnects.
• Steam’s OpenXR runtime path resolves to the socket; activating a SteamVR/OpenXR game triggers socket activation.
• Parent dir created with 0750, socket with 0770.

Operational Notes

• Module assumes desktop-class host with graphics stack and Steam support.
• WiVRn config uses NVENC H.265 encoder entries and enables pkgs.wayvr as application.
• Some extra behavior only appears when related modules already exist, such as Jovian Decky Loader and Home Manager.

Generators

Configures image and container generator support for shared NixOS hosts.

• Entry point: generators.nix

Overview

This module imports nixos-generators formats and exposes core.generators options for generator-specific setup.

Current focus is Proxmox LXC image generation. When enabled for virtual hosts, module adds activation logic that prompts for SSH host private key on first boot, validates it with ssh-keygen, and stores it under /persist/etc/ssh/ssh_host_ed25519_key so later secret management can install it into /etc/ssh.

Options

core.generators.enable

Whether to enable generators configuration.

core.generators.proxmoxLXC.clearPath

Clear binary to use for clearing the screen when asking the user for the SSH private key

core.generators.proxmoxLXC.enable

Whether to enable Proxmox LXC generator configuration.

core.generators.proxmoxLXC.sedPath

Sed package to use for validating the SSH private key provided by the user

core.generators.proxmoxLXC.sshKeygenPath

SSH package to use for validating the SSH private key provided by the user

Assertions and Behaviour

When core.generators.proxmoxLXC.enable = true, module asserts that image contains /etc/ssh/ssh_host_ed25519_key.pub.

If activation runs without controlling terminal, prompt is skipped and activation exits cleanly. If terminal exists, module loops until pasted private key:

• contains valid OpenSSH private key block,
• passes ssh-keygen -y, and
• matches public key already present at /etc/ssh/ssh_host_ed25519_key.pub.

Usage Example

{ ... }: {
  core.generators = {
    enable = true;

    proxmoxLXC = {
      enable = true;
    };
  };
}

Operational Notes

• nixos-generators formats are imported unconditionally by module, but runtime configuration only applies when core.generators.enable is on.
• Proxmox LXC flow is designed for images where public host key is baked into image but private key must be supplied interactively after boot.
• Stored private key lives in /persist, so persistence and later secret deployment must be configured for target host.

Groups

Locale

Sets shared timezone and locale defaults.

• Entry point: locale.nix

Overview

This module provides opinionated regional defaults for timezone and locale. It sets Australia/Sydney timezone and enables Australian and US English UTF-8 locales.

Options

core.locale.enable

Whether to enable locale configuration.

Usage Example

{ ... }: {
  core.locale.enable = true;
}

Operational Notes

• Module is enabled by default.
• Because settings use mkDefault, this module acts as baseline rather than hard override.

Nix

Defines shared Nix daemon, cache, and registry defaults.

• Entry point: nix.nix

Overview

This module establishes global Nix configuration for hosts in this flake. It sets overlays, system.stateVersion, trusted users, experimental features, binary caches, garbage collection, and registry-derived nixPath.

It also provisions cache push secret and attic-watch-store service for automatic uploads to remote Attic cache.

Options

This module does not define core.* options. It applies shared baseline configuration directly.

Behaviour

Module configures:

• overlays from inputs.nix4vscode,
• system.stateVersion from state.version file in flake root,
• trusted Nix users root and @wheel,
• nix.settings.auto-optimise-store = mkForce true,
• experimental features nix-command, flakes, and pipe-operator,
• substituters, trusted substituters, and trusted public keys for cache.nixos.org, nix-community, and cache.racci.dev,
• daily automatic Nix GC, and
• nix.nixPath derived from config.nix.registry.

It also enables services.angrr to retain recent system profiles and creates systemd.services.attic-watch-store that waits for network-online.target, restarts on failure, logs into Attic with SOPS-managed CACHE_PUSH_KEY, and watches store for uploads.

Operational Notes

• Because module has no enable flag, this is always active and applied to all hosts.
• attic-watch-store depends on sops.secrets.CACHE_PUSH_KEY from hosts/secrets.yaml.
• services.angrr keeps system profiles for 14 days, latest 3 generations, current system, and booted system.

OpenSSH

Configures opinionated SSH server and client defaults.

• Entry point: openssh.nix

Overview

This module enables OpenSSH with ed25519-only host keys, disables password authentication, and generates known-host entries for all configured NixOS hosts in flake outputs.

It also wires SOPS-managed host private key into sshd and publishes matching public key under /etc/ssh/ssh_host_ed25519_key.pub.

Options

core.openssh.enable

Whether to enable OpenSSH server and client opinionated configuration.

Behaviour

When enabled, module:

• enables services.openssh,
• disables socket activation (startWhenNeeded = false) to prevent mid-connection disruptions during system configuration switches,
• disables password authentication,
• sets PermitRootLogin = "prohibit-password",
• sets GatewayPorts = "clientspecified",
• configures services.openssh.hostKeys from config.sops.secrets.SSH_PRIVATE_KEY.path,
• publishes current host public key at /etc/ssh/ssh_host_ed25519_key.pub,
• enables security.pam.sshAgentAuth,
• adds current host public host key to users.users.root.openssh.authorizedKeys.keyFiles, and
• generates programs.ssh.knownHosts entries for every host in outputs.nixosConfigurations.

Client configuration also restricts host key algorithms and accepted public key types to ssh-ed25519.

Usage Example

{ ... }: {
  core.openssh.enable = true;
}

Operational Notes

• Module expects matching host public key file to exist in flake for each host.
• Current host gets localhost as extra known-host alias in generated SSH client config.
• Root authorization here uses host key material from flake, not per-user login keys.
• Private host key comes from SOPS secret SSH_PRIVATE_KEY, so core.sops integration usually pairs with this module.
• Socket activation disabled: By default, NixOS uses socket activation for SSH which spawns per-connection service instances (sshd@...service). When these instances are restarted during a configuration switch, it disconnects active SSH sessions. Disabling socket activation (startWhenNeeded = false) runs SSH as a traditional always-on service, preventing remote disconnection during nixos-rebuild switch over SSH.

Printing

Enables shared printer support for workstation-class NixOS hosts.

• Entry point: printing.nix

Overview

This module enables CUPS printing support on non-server, non-virtual hosts and installs common printer drivers used in this configuration.

When active, it turns on services.printing, adds HP and Gutenprint drivers, and includes Brother MFC-L3770CDW driver packages.

Options

core.printing.enable

Whether to enable printing support.

Behaviour

When both config.core.enable and core.printing.enable are true, module:

• enables services.printing,
• installs printer drivers from pkgs.hplip, pkgs.gutenprint, pkgs.gutenprint-bin, pkgs.cups-filters, pkgs.mfcl3770cdwlpr, and pkgs.mfcl3770cdwcupswrapper, and
• adds lp to core.defaultGroups.

Usage Example

{ ... }: {
  core.printing.enable = true;
}

Operational Notes

• Module does not activate unless top-level core.enable is also enabled.
• Default is tuned for physical desktop or laptop systems where local or network printer access is expected.
• core.defaultGroups = [ "lp" ] ensures standard users can access printer devices through shared default group handling.

Remote Access

Provides optional remote desktop and game-streaming capabilities for desktop hosts.

• Entry point: remote.nix

Overview

This module exposes core.remote with two independent sub-features:

Options

core.remote.enable

Whether to enable remote features.

core.remote.remoteDesktop

This option has no description.

core.remote.remoteDesktop.enable

Whether to enable remote desktop.

core.remote.remoteDesktop.startCommand

Command to start remote desktop session.

core.remote.streaming

This option has no description.

core.remote.streaming.enable

Whether to enable remote streaming.

Behaviour

When core.remote.enable = true:

• remoteDesktop.enable turns on services.xrdp, sets defaultWindowManager, and opens firewall for RDP.
• streaming.enable turns on services.sunshine, opens firewall for TCP 47989, and sets capSysAdmin = true.
• Sunshine does not run continuously. A socket-activated TCP proxy on port 47989 starts Sunshine on-demand when a client connects.
• When the client disconnects and no new connection arrives for 5 minutes, the proxy exits and Sunshine stops.
• if Home Manager is present, streaming also persists .config/sunshine through shared Home Manager module.

Hyprland Integration

When both core.remote.streaming.enable and programs.hyprland.enable are true, module additionally:

• sets services.sunshine.settings.output_name = "3",
• adds two Sunshine application entries named Shared Desktop and Exclusive Desktop,
• creates headless output at login via Home Manager, and
• keeps HEADLESS-2 disabled by default until Sunshine prep commands enable it.

Lua Mode Handling

If Hyprland is in Lua mode (programs.hyprland.configType = "lua"), the shared Home Manager module uses Lua-safe equivalents:

• Startup hook: settings.on with hyprland.start event triggers hyprctl output create headless.
• Monitor rule: { output = "HEADLESS-2"; disabled = true; } (attrset form instead of old string).
• Screencopy permission: routed through wayland.windowManager.hyprland.custom-settings.permission.screenCopy, which handles both Lua and hyprlang modes automatically.

For hyprlang mode, the old string forms (exec-once, monitor = "HEADLESS-2,disable") are used unchanged.

Usage Examples

Streaming only

{ ... }: {
  core.remote = {
    enable = true;
    streaming.enable = true;
  };
}

RDP only

{ ... }: {
  core.remote = {
    enable = true;
    remoteDesktop = {
      enable = true;
      startCommand = "hyprland";
    };
  };
}

Operational Notes

• Two sub-features are independent. You can enable streaming without RDP, or RDP without streaming.
• Sunshine persistence and Hyprland settings are only added when Home Manager is present in system configuration.
• Hyprland-specific Sunshine application entries are only added when both streaming and Hyprland are enabled.

On-Demand Activation & Idle Stop

Sunshine stays on its standard port family rooted at TCP/UDP 47989–47990+ (no port-family offset). External inbound TCP 47989 is firewall-redirected to internal proxy port 48989. The proxy wakes Sunshine and forwards to 127.0.0.1:47989.

Dependency Model

sunshine-proxy.socket (:48989)
    ↓ activates
sunshine-proxy.service  ──bindsTo──→  sunshine.service (:47989)

No cycle: proxy starts Sunshine, proxy bindsTo Sunshine (proxy dies if Sunshine fails), Sunshine uses StopWhenUnneeded (stops when proxy exits).

Firewall Flow

External client → TCP :47989
    ↓ (NAT PREROUTING REDIRECT)
Local port :48989
    ↓ (conntrack ctorigdstport 47989 match → nixos-fw-accept)
sunshine-proxy.socket
    ↓
sunshine-proxy.service → sunshine.service (:47989)

Redirect covers only inbound network traffic. Locally-originated traffic to :47989 (e.g. from Moonlight running on the same machine) is unaffected.

Caveats

• No LAN discovery while idle. Sunshine needs to run for mDNS/SSDP advertisements to appear on LAN. While stopped (idle), clients will not auto-discover the host. Users must add the host manually by IP/hostname in Moonlight or use a previously-added host entry (Moonlight remembers known hosts).
• TCP wake only. This proxy covers the control/initial TCP connection on 47989. Sunshine’s UDP audio/video streams (standard port range) will only work after Sunshine runs. Since Sunshine sets up its UDP sockets itself after startup, no UDP wake is needed in practice (the rendezvous happens over TCP first).
• Delayed first connect. The first TCP connection may stall ~1–2 seconds while Sunshine starts up. Clients (Moonlight) retry or timeout gracefully.
• Firewall. Sunshine opens its standard ports via openFirewall. The redirect only touches TCP 47989 for the wake path. No port-family offset anymore — all media/data ports remain at standard values.
• Redirect scope. The firewall redirect applies to inbound network traffic only. Local loopback connections to :47989 bypass the redirect and reach Sunshine directly if it is already running.

Security

Applies shared host security defaults.

• Entry point: security.nix

Overview

This module enables baseline security features such as sudo-rs, TPM2 support, Polkit, kernel protection flags, and open-file limits for users.

Options

core.security.enable

Whether to enable security features.

core.security.userLimit

The maximum number of open files per user.

This is used to set the limits for both PAM and systemd.

Usage Example

{ ... }: {
  core.security = {
    enable = true;
    userLimit = 65536;
  };
}

Operational Notes

• Module leaves security.lockKernelModules = false even while enabling other hardening defaults.
• userLimit affects both PAM sessions and user systemd services, keeping file descriptor limits aligned.

SOPS

Configures shared SOPS and age decryption defaults.

• Entry point: sops.nix

Overview

This module imports sops-nix, sets host default secrets file, derives age SSH key paths from persisted host SSH keys, and declares managed SSH private key secret for OpenSSH.

Options

core.sops.enable

Whether to enable SOPS auto configuration.

core.sops.hostSecretsFile

Where the SOPS secret file of this host is located in the flake.

Behaviour

When enabled, module:

• imports inputs.sops-nix.nixosModules.sops unless function argument importExternals = false,
• sets sops.defaultSopsFile to core.sops.hostSecretsFile,
• builds sops.age.sshKeyPaths from persisted host SSH key path first, then appends any configured ed25519 OpenSSH host keys, and
• declares sops.secrets.SSH_PRIVATE_KEY at /etc/ssh/ssh_host_ed25519_key with sshd.service restart hook.

Usage Example

{ ... }: {
  core.sops.hostSecretsFile = ./secrets.yaml;
}

Operational Notes

• Default age key path includes ${config.host.persistence.root}/etc/ssh/ssh_host_ed25519_key.
• Module filters config.services.openssh.hostKeys to ed25519 keys before adding them to sops.age.sshKeyPaths.
• core.openssh typically consumes sops.secrets.SSH_PRIVATE_KEY declared here.

Stylix

Applies shared system theme defaults with Stylix.

• Entry point: stylix.nix

Overview

This module imports Stylix and enables dark Tokyo Night theming on non-headless hosts by default.

Options

core.stylix.enable

Whether to enable Stylix configuration.

Behaviour

When enabled, module:

• imports inputs.stylix.nixosModules.stylix unless function argument importExternals = false,
• sets stylix.enable = true,
• sets stylix.polarity = "dark", and
• uses Tokyo Night dark Base16 scheme from tinted-schemes input.

Usage Example

{ ... }: {
  core.stylix.enable = true;
}

Operational Notes

• Module is intended for graphical hosts.
• Theme source is ${inputs.stylix.inputs.tinted-schemes}/base16/tokyo-night-dark.yaml.

Virtualisation

Configures libvirt, VFIO passthrough, bridge networking, and guest isolation helpers.

• Entry point: virtualisation.nix

Overview

This module enables libvirt with QEMU, VFIO GPU passthrough, Looking Glass shared memory, bridge networking, custom OVMF firmware metadata, and libvirt hook helpers for selected guests.

It also generates helper scripts that change AllowedCPUs on host slices while selected guests run, detach and reattach passthrough GPUs for -single guests, and block host sleep while libvirt domains are active.

Options

core.virtualisation.bridgeInterface

Bridge interface used for libvirt networking.

core.virtualisation.cpuCores

Total CPU core/thread count used for isolation helpers. Must be >= 4.

core.virtualisation.enable

Whether to enable virtualisation support.

core.virtualisation.externalInterface

Physical interface attached to bridge.

core.virtualisation.gpu.audio

PCI address for passthrough GPU audio device.

core.virtualisation.gpu.video

PCI address for passthrough GPU video device.

core.virtualisation.isolatedGuests

List of guests to apply isolation helpers to.

core.virtualisation.vmUsers

Users that should receive kvm and libvirtd group membership for VM management.

Behaviour

When enabled, module:

• imports external virtualisation helpers from crtified.modules.virtualisation.nix and ../desktop/vfio.nix,
• enables virtualisation.libvirtd, Spice USB redirection, and services.spice-autorandr,
• enables VFIO with IOMMUType = "amd", disableEFIfb = true, and configured GPU devices,
• configures Looking Glass shared memory file looking-glass owned by racci:qemu-libvirtd,
• adds virt-manager, virtiofsd, virtio-win, and win-spice to system packages,
• sets LIBVIRT_DEFAULT_URI = qemu:///system,
• creates bridge networking with DHCP on bridgeInterface and externalInterface enslaved into bridge,
• adds kvmfr kernel module package and modprobe config static_size_mb=128, and
• installs udev rule for /dev/kvmfr access.

Module also persists libvirt and swtpm state under host.persistence.directories.

Isolation and Hook Helpers

For each guest in core.virtualisation.isolatedGuests, module creates libvirt hook entries that:

• restrict host user.slice, system.slice, and init.scope CPU sets during guest startup,
• restore full CPU set when guest stops,
• for <guest>-single, detach GPU and stop display-related services before launch, and
• reattach GPU, reload drivers, restart saved services, and rebind VT consoles after shutdown.

It also creates libvirt-nosleep@<guest> service that uses systemd-inhibit to block sleep while guest is running.

Firmware and Persistence

Module extends libvirt startup to populate /run/libvirt/nix-ovmf with secure-boot and Microsoft-enrolled OVMF firmware files, then publishes matching firmware JSON metadata under /var/lib/qemu/firmware.

Persisted paths include:

• /var/lib/libvirt/qemu
• /var/lib/libvirt/images
• /var/lib/libvirt/swtpm
• /var/lib/libvirt/secrets
• /var/lib/swtpm-localca

Usage Example

{ ... }: {
  core.virtualisation = {
    enable = true;
    vmUsers = [ "racci" ];
    isolatedGuests = [ "win11-gaming" ];
    bridgeInterface = "br0";
    externalInterface = "enp6s0";
    cpuCores = 24;

    gpu = {
      video = "10de:1b06";
      audio = "10de:1bef";
    };
  };
}

Operational Notes

• core.virtualisation.cpuCores is validated by both option type and assertion, so values below 4 fail evaluation.
• vmUsers is opt-in. Only listed users receive kvm and libvirtd access.
• Hook generation assumes guest naming convention where <name>-single means single-GPU passthrough workflow.

WSL

Adds Windows Subsystem for Linux specific integration and fixes.

• Entry point: wsl.nix

Overview

This module configures WSL-focused defaults such as default user, Windows interop, graphics library paths, nix-ld, and Start Menu launcher syncing.

Options

core.wsl.enable

Whether to enable WSL specific configurations, optimisations, and fixes.

core.wsl.user

The default user to use for WSL.

Behaviour

When enabled, module:

• sets users.allowNoPasswordLogin = true,
• installs pkgs.wslu,
• enables programs.nix-ld with C toolchain library for Remote WSL compatibility,
• sets session variables for WSL graphics and library paths,
• enables hardware.graphics and adds config.hardware.graphics.package, config.hardware.graphics.package32, and pkgs.libvdpau-va-gl, and
• when NVIDIA graphics are present, appends CUDA and NVIDIA library paths.

If wsl module exists in option tree, module also:

• enables wsl.enable,
• sets wsl.defaultUser = core.wsl.user,
• enables Start Menu launchers and Windows driver usage,
• enables Windows interop and PATH appending,
• exposes dirname, readlink, and uname through wsl.extraBin for VS Code Remote WSL compatibility, and
• copies per-user Home Manager applications and icons into /usr/share during activation so launchers appear in Windows Start Menu.

Usage Example

{ ... }: {
  core.wsl = {
    enable = true;
    user = "racci";
  };
}

Operational Notes

• core.wsl.user is required when WSL integration is enabled.
• Extra binaries dirname, readlink, and uname are exposed for VS Code Remote WSL compatibility.
• Some behavior is conditional on separate WSL module being available in options.

Server Module

The Server module provides a cluster-aware configuration for server hosts in the flake. It must be explicitly enabled using the server.enable option.

Purpose

The primary purpose of this module is to establish a shared environment for servers in the cluster, defining a coordinator node (ioPrimaryHost) and providing helper functions for inter-server communication and attribute collection.

Entry Point

• modules/nixos/server/default.nix

Options

server.dashboard.displayData

Display data for the section in the dashboard.

server.dashboard.icon

Icon for the section in the dashboard.

server.dashboard.items

Additional configuration for items managed by the IO Hosts dashy instance. This will be merged with the automatically generated configuration that is nested in a section with the name of the machine.

server.dashboard.items.<name>.icon

Icon for the item.

server.dashboard.items.<name>.title

Title of the item.

server.dashboard.items.<name>.url

URL for the item.

server.dashboard.name

Name of the section in the dashboard.

server.database.dependentServices

List of systemd service names that depend on io databases. These services will be automatically bound to the io-databases.target and will stop/start when databases become unavailable/available.

server.database.host

The hostname or IP address to use when connecting to managed databases.

This is “localhost” when running on the host, and when connecting from other hosts.

server.database.postgres

This option has no description.

server.database.postgres.<name>.database

This option has no description.

server.database.postgres.<name>.host

This option has no description.

server.database.postgres.<name>.password

This option has no description.

server.database.postgres.<name>.password.group

This option has no description.

server.database.postgres.<name>.password.owner

This option has no description.

server.database.postgres.<name>.password.path

This option has no description.

server.database.postgres.<name>.port

This option has no description.

server.database.postgres.<name>.user

This option has no description.

server.database.redis

This option has no description.

server.database.redis.<name>.database_id

This option has no description.

server.database.redis.<name>.host

This option has no description.

server.database.redis.<name>.port

This option has no description.

server.database.redis.<name>.prefix

This option has no description.

server.distributedBuilds.builderUser