AzurCrystal's nixos infra

Warning

This repository is not expected to deploy or run correctly as-is in a public checkout. It depends on an internal private/ submodule and site-specific inventory, so it should be treated as a reference repository rather than a directly usable deployment target.

This repository is a personal NixOS infrastructure tree.

It covers several different kinds of machines at once:

• a primary desktop
• a home router and edge node
• public VPS nodes
• self-hosted applications and platform services
• custom Nix packages and NixOS modules

It is not written as a generic starter template. It is a working repository with personal assumptions, but it is organized so those assumptions remain readable.

How To Read The Repository

The shortest path to understanding the repo is:

1. outputs.nix
2. modules/flake/osConfig.nix
3. modules/lib/mkOS.nix
4. the relevant module under modules/

That path shows how the flake entrypoint becomes concrete machine configurations.

Repository Shape

• modules/flake contains flake wiring, host declarations, and top-level checks.
• modules/lib contains small composition helpers and constructors.
• modules/substrate contains shared base assumptions used across multiple machines.
• modules/presets contains role bundles such as desktop or server.
• modules/profiles contains concrete machine definitions and node-specific values.
• modules/services contains service modules and repository-local service wrappers.
• modules/applications contains application-facing features.
• modules/pkgs contains custom package definitions.
• private contains private inventory layered into the public tree.

The repository is intended to be feature-first rather than host-first. Host profiles are where machines choose features and provide concrete values, not where the whole system is reimplemented from scratch.

Machines

• main is the primary desktop and workstation.
• router is the home edge machine and also hosts several local platform services.
• aliyun is a public control-plane VPS.
• greencloud is a public content or application VPS.

The exact workloads can evolve, but the split between desktop, edge, and public nodes is one of the main structural ideas in the repo.

Composition Model

At a high level, the composition flow is:

1. flake entrypoints and host declarations
2. shared substrate
3. role presets
4. feature and service modules
5. concrete host profiles

This is why the repository tree matters so much: directory names are part of the architecture, not just storage.

Service Namespaces

This repository uses two service namespaces on purpose:

• services.* is the real runtime service surface, usually native or upstream NixOS module options.
• local.services.* is for repository-local wrappers, orchestration layers, and instance wiring around those services.

A repository-local wrapper may still write into services.* internally, but its public interface lives under local.services.* so the deployment surface and the repository's own orchestration layer stay distinguishable.

What Lives In Profiles

Profiles are the place for concrete machine identity and values, such as:

• hardware and storage configuration
• addresses and network identity
• domains and host bindings
• secrets and host-local references
• per-node service instance values

If a behavior is reused across machines, it usually belongs back in a module.