NixOS Fleet — ymrtech.com

_{One declarative source of truth for every host behind YMRTECH's services and its client VPN product.}

---

What this repository is

This is the public configuration skeleton of a small, fully declarative NixOS fleet. Every host — the public service edge, the mail and monitoring hub, the VPN gateways and the operator workstation — is described as code: its packages, users, network policy, services and hardening are expressed in Nix and rebuilt from this repository. No server is ever hand-edited. A host changes only when main changes.

The same fleet backs two things:

• YMRTECH's own services — the site, mail, monitoring and the internal collaboration tooling behind ymrtech.com.
• The client VPN product — a subscription service whose accounts, devices and regional egress are provisioned from this configuration. Product overview: ymrtech.com/vpn.

This repository is deliberately the evaluable half of that configuration. The implementation that is specific to the product's security perimeter lives in a private companion repository, kept separate on purpose so the architecture can be inspected without publishing the material that makes the perimeter defensible.

The public / private boundary

	Public — this repository	Private — nix-config-private
Contents	Flake shape, host definitions, module layout, shared hardening defaults, generic service wiring, the CI/CD workflows	The product perimeter: the client tunnel interface and its service wiring, the private operational runbooks, and the real secret store
Consumed how	Readable and evaluable by anyone	Consumed as a flake input, pinned in flake.lock and fetched at deploy time

Both repos are the same shape of thing — NixOS modules — and the public repo stays a flake that still evaluates and builds on its own. The boundary moves implementation out of view; it never removes capability, and it never moves the evidence: the audit reports, verification keys and signed logs that let a third party check the claims below stay public (see Security & compliance).

Fleet at a glance

Host	Role	Type
vpn	Primary mesh gateway — encrypted tunnel termination, NAT egress, encrypted DNS, and network-wide tracker/ad filtering. Also the fleet-operator host: it runs the automation and the operator agent that maintains the fleet.	VPS
vpn-mx	A second mesh entry point in a second region, so clients can egress from the geography they choose.	VPS
public	Public service edge — git forge and CI runners, password vault, status and uptime monitoring, real-time media relay for messaging.	VPS
mail	Mail and monitoring hub — mail delivery and storage with server-side full-text search, encrypted file sync, a self-hosted binary cache, and the metrics/log store.	VPS
giga	Operator workstation / GPU box. Off the automated deploy path (giga moves by an explicit dispatch only).	Laptop
command	Bare-metal host on the operator's own hardware.	Bare metal

                          ┌───────────────────────────┐
    clients ──tunnel──▶   │   mesh gateway  (vpn)     │──▶ internet
                          │   · encrypted DNS         │
                          │   · tracker/ad filtering  │
                          └────────────┬──────────────┘
                                       │ encrypted mesh
        ┌──────────────┬───────────────┼───────────────┬──────────────┐
        ▼              ▼               ▼               ▼              ▼
   public edge     mail hub      second gateway   workstation    bare metal
   (services)     (mail, mon.)      (vpn-mx)         (giga)       (command)

Architecture principles

1. Declarative — every system's state is defined in code. No manual changes on running servers.
2. Reproducible — copy a host's config, rebuild, and get an identical system.
3. Modular — shared settings live in common modules; host-specific settings override as needed.
4. Version-controlled — the entire OS lives in Git. Changes are reviewed, committed and deployed.
5. Atomic — new configurations are evaluated and built before activation; rollback is instant.
6. Health-gated — every deploy verifies its critical services after the switch and rolls itself back if one is down.
7. Least exposure — secrets are split per host (a host can decrypt only the store it is a recipient of); services bind to the private mesh, never to the public interface.

How a change reaches a host

1. A change lands as a pull request. CI evaluates every affected host configuration and then builds its full closure, pushing the result to a self-hosted binary cache so that the merge substitutes rather than rebuilds.
2. On merge to main, a self-hosted runner on each affected host deploys it.
3. The new generation activates, then the deploy polls its gated services until they are active and asserts that no unit on the host is in a failed state.
4. Any violation auto-rolls-back to the previous generation. There is no unattended upgrade: hosts move when main moves, and inputs advance only through the weekly flake-update job.

CI / CD

Workflow	Trigger	What it does
Build check	every PR, and every push to main that touches host-relevant paths	Evaluates the changed hosts (PRs are git-diff scoped) to catch every eval/syntax error in seconds, then builds each changed host's closure natively and pushes it to the binary cache. Docs-only changes skip it.
Deploy	push to main, plus manual dispatch	One job per host, on that host's own Actions runner: fetches the pinned private implementation, runs the switch, verifies, and rolls back on a failed health check.
Secret scan	every PR, every push to main	Full-history secret scanning over this (public) repository.
PR base guard	every PR	A real three-way merge-tree check against the current main; red on a genuine conflict, warns when main moved under the branch.

Runners are outbound-only — they dial out to the forge and there is no SSH between hosts and no inbound port opened on a target. main is protected: every PR must pass the secret scan and the base guard before it can merge, administrators included. A direct push is refused for everyone except the identities named on main's push whitelist — in this repo hermes and the fleet automation identity clientsv, a service account, never a blanket allowance for writers. The one lane that uses it is the pin-follow lane (.forgejo/workflows/vpn-pin-follow.yml), whose output is a single IPv4 literal two independent public resolvers agreed on, spliced by a tested one-line rewrite and read back before it is committed; it keeps the ordinary PR-merge path as a fallback if the whitelist is ever revoked.

The autonomous engineering system

The fleet is not only described declaratively — it is operated by an autonomous software-engineering system built on top of it. For us this is the real engineering result: building the VPN product was, in effect, the exercise that forced it into existence.

You talk to the fleet in plain language. Work is expressed as a card on a self-hosted kanban board, or as a reply to an email. That message is the input — no logging into hosts, no hand-run commands, no local merges. The system takes the request, plans it, makes the change on a fresh branch, and carries it through the fleet's normal path: evaluate every affected host, build its closure, push it to the binary cache, open a pull request, drive CI to green, merge, deploy, verify.

Nothing bypasses a gate. The same review, CI, branch protection and post-deploy health check apply to work the system does as to work a human does. The human stays in the loop exactly where a review is wanted — and nowhere it is not.

It is autonomous and self-healing. When a pipeline goes red or a host rolls itself back, the system diagnoses the actual failure and opens the fix itself; it does not wait for someone to notice. A broken change is repaired by the same loop that shipped it.

It is conflict-avoidant by construction. Because several workstreams can run at once, each one claims the files it is about to touch in a shared coordination ledger before it edits them. Two sessions can never silently overwrite each other's work — a collision becomes a queue, not a merge race.

Everything is tracked and declared. Every intent, claim, verification and landed change is recorded on the board and in the ledger, so any change can be audited after the fact: what was asked, what moved, and what proved it. Nothing depends on a person remembering what they did.

It maintains its own knowledge. The system keeps a curated library of the procedures and lessons it learns — a host that fills its disk, a deploy lane that deadlocks, a dependency that must not be bumped — so an operation that took a session to work out the first time is a lookup the next time.

Scheduled agent jobs tend the fleet. Beyond change work, LLM-driven scheduled passes reconcile the board with reality, keep monitoring and backups healthy, and handle routine upkeep unattended.

We are turning this way of operating a fleet into an offering — rolling it out inside enterprises and as a hosted platform. Details on request: contact.

Repository layout

nix-config/
├── flake.nix                # Flake root: inputs, host set, mkNixos helper
├── flake.lock               # Pinned dependency revisions
├── shell.nix                # Dev shell
├── .sops.yaml               # Secret-store encryption rules
├── .forgejo/
│   ├── workflows/           # CI/CD: build check, deploy, secret scan, base guard, flake update
│   ├── scripts/             # Workflow helper scripts (freeze policy, scope, lock bumps)
│   └── tests/               # Hermetic suites run on every PR
├── hosts/
│   ├── common/
│   │   ├── global/          # Shared host settings: hardening, memory pressure, DNS zone, health gate
│   │   ├── optional/        # Toggleable service groups
│   │   └── users/           # User accounts, keys, shells
│   ├── vpn/                 # Mesh gateway + fleet operator
│   ├── vpn-mx/              # Second mesh entry point
│   ├── public/              # Public service edge
│   ├── mail/                # Mail + monitoring hub
│   ├── giga/                # Operator workstation
│   └── command/             # Bare-metal host
├── modules/
│   ├── monitoring/          # Metrics, logs, traces, dashboards, alerting, status page
│   └── …                    # Backup, topology, service priority, provider metrics
├── overlays/                # Package overrides and pinned upstream packages
├── packages/                # Locally built packages
├── secrets/                 # Demo value only — the real store is private
└── certs/

Dependency surface

Inputs are pinned in flake.lock and are chosen from upstream releases that are at least five days old — never the absolute tip. They advance only through the weekly flake-update job, or for a high/critical security fix, and never regress.

Input	Role
nixpkgs	Package set (unstable channel)
sops-nix	Per-host encrypted secret delivery
hardware	Hardware profiles
nixos-mailserver	Mail server module
nix-config-private	Private product-perimeter modules
clientsv	VPN subscription backend (private)
hermes-agent, llm-agents	Operator-agent tooling
hindsight	Operator-agent memory store
hermes-bench	Operator-agent benchmarking application
comfyui-nix	Image-generation tooling
ninfer-3090	GPU inference engine

Service capabilities

Network, privacy and the client tunnel

• An obfuscated encrypted mesh between every host, with NAT egress through the gateway.
• Encrypted recursive DNS with aggressive caching and upstream authenticated transport.
• Network-wide tracker and advertising filtering at the DNS layer, plus client-specific filter policies served from the same resolver.
• Per-device client provisioning, regional egress selection, and a portal that shows each device's live connection state and verifies that its DNS is not leaking.

Public services

• A self-hosted git forge (git.ymrtech.com) with an integrated CI/CD pipeline and self-hosted, container-free runners.
• A self-hosted password vault, a service status page, and uptime monitoring with alerting.
• A relay for real-time messaging media, restricted to the private ranges.

Mail, data and storage

• A full mail stack: authenticated delivery and storage with server-side full-text search, plus policy-enforced authentication and per-source throttling against abuse.
• A newsletter list with double opt-in and self-service export/deletion, published on an allowlisted path set of the main site.
• Encrypted cross-host file synchronisation, a self-hosted binary cache, and snapshot-based filesystem backup with off-site replication.

Observability and automation

• Central metrics, log aggregation and tracing, with dashboards, alert rules and a public status surface.
• The autonomous engineering system that runs and evolves the fleet — see above.

Security & compliance

The fleet is run toward an ISO-27001-style, defensible posture, and the evidence for the claims above is published rather than described:

• Audit — signed logging audit reports and their history.
• Standards — the standards each host is held to, and the evidence for each.
• Logging — exactly what the VPN logs, and what it cannot log.
• Privacy and Terms.
• Management system — scope, risk register, statement of applicability, change management, incident response and internal audit.

Quick start

# Dev environment
nix-shell

# Build and activate a host locally
sudo nixos-rebuild switch --flake .#<host>

# Or build straight from the remote, bypassing any local cache
sudo nixos-rebuild switch --flake git+https://git.ymrtech.com/ymrtech/nix-config#vpn --refresh

# Move inputs forward (the job that the weekly flake update automates)
nix flake update

Hostnames: vpn, vpn-mx, public, mail, giga, command

---

ymrtech.com · VPN · Writing · Contact

_{Built with Nix · Declarative · Reproducible · Health-gated}