Flake attributes

Fediversity is split across per-directory flake entrypoints. This site documents the core entrypoint (NixOS configurations, deployment packages and checks) and the thin repo root (the cross-cutting infra checks). The api and panel leaves document their own flake attributes in their own docs sites.

This page is generated from the core and root entrypoints themselves every time the docs are built, so it always reflects the current outputs -- both the lists at the end and the tables that describe the generated names. Descriptions come from each attribute's meta.description; a few attributes that evaluate to null (placeholder slots in a deployment group) are listed without one.

The naming grammar

core exposes on the order of a thousand packages, but they are not a thousand separate things: they are a handful of axes crossed with each other. Every generated attribute name follows one of four shapes.

<group>-<deployment-method>-<machine>[-<verb>]   deployment packages
<group>-<effect>[-<verb>]                       standalone operator effects
<group>-<machine>                               nixosConfigurations
<name>[-<verb>]                                 hand-bound standalone effects

The last shape is the exception. A handful of effects precede the deployment that would generate them, so they belong to no group and are written out by name. They are listed in full further down.

Read against that grammar:

• hosting-provider-tf-incus-netbox deploys the netbox machine of the hosting-provider group with the tf-incus deployment method: provision its Incus container and deploy onto it.
• operator-tf-incus-operator-all-plan takes the operator group, the tf-incus-operator deployment method and the all target, and runs the plan verb: show what deploying every machine of the group would change, without doing it.
• hosting-provider-octodns-zone-apply runs the octodns-zone standalone effect for the hosting-provider group with the apply verb: publish the group's DNS records.
• operator-mastodon is the NixOS system configuration of the operator group's mastodon machine -- the system the deployment attributes above build and activate.
• netbox-seed-plan is the group-less NetBox seed with the plan verb: show what the seed would create in the NetBox a deploy then reads from.

all and combined

Besides its own machines, every group has two aggregate deploy targets:

• all deploys each machine of the group to its own host, in one run.
• combined deploys the whole group as a single all-in-one host, with every service merged onto one machine.

combined is also a nixosConfiguration, but only for the groups that can actually collapse onto one host; for the others there is no such system to build, only the deploy targets listed above.

Apps and dev shells

apps.<name> mirrors packages.<name> one for one -- every deployment package is also runnable directly:

nix run ./core#operator-tf-incus-operator-all-plan

devShells.<name> mirrors it as well (plus a default shell), dropping you into an environment with that deployment's tooling on PATH:

nix develop ./core#operator-tf-incus-operator-all

Neither is enumerated on this page: the names are exactly the package names.

Getting the literal list

When you do need the flat enumeration rather than the pattern:

nix eval --json ./core#packages.x86_64-linux --apply builtins.attrNames
nix flake show ./core

Prefer the first: it forces only the attrset spine. nix flake show also reports each attribute's type and description, which means building out every one of the ~1400 deployment packages far enough to read its meta.

The legacyPackages output (the full nixpkgs package set) is omitted here.

Attribute families

Almost every attribute is generated: the grammar above is filled in from a handful of axes, listed below. These tables are generated from those same axes, so they always describe the current surface.

Groups and machines

A group is one deployment unit: a set of machines deployed together. Its roster splits those machines in two, and the split decides one thing: whether the machine gets a public identity. A published machine is given a record in the group's public zone and an ACME certificate for the names it serves; an internal machine is neither, and its peers reach it by its instance FQDN. Both kinds are deployed, both are allocated an address, and resource requests are gathered from both -- so moving a machine between the buckets changes its zone record and its certificate and nothing else.

That is deliberately not the application-versus-infrastructure distinction, which lives on the component instead, as components.<name>.optional. The two are separate because they disagree, and because they are answered at different scales: optional is true of mastodon in every group that runs it, while publication is a property of one machine in one group, which is the only place the answer can differ. They also cross. The hosting provider's garage, openbao and netbox are infrastructure by any reading and every one of them is published, because operator nodes and administrators dial them by name from outside that group; an operator group's own valkey, authelia, smtp and lldap are internal, reached only from within its deployment.

dev

Published machines:

• dev2
• dev3
• dev4
• fediversity-ci
• forgejo

Deploy targets: the machines above, plus all, combined. NixOS configurations: the machines above.

hosting-provider

Published machines:

• authelia
• bind
• garage
• lldap
• netbox
• openbao
• otel-collector
• overview
• postgresql
• smtp
• spire
• telemetry
• terraform-backend
• valkey
• windmill

Deploy targets: the machines above, plus all, combined. NixOS configurations: the machines above.

hypervisor

Published machines:

• incus

Deploy targets: the machines above, plus all, combined. NixOS configurations: the machines above.

operator

Published machines:

• mastodon
• peertube
• pixelfed

Internal machines:

• authelia
• lldap
• smtp
• valkey

Deploy targets: the machines above, plus all, combined. NixOS configurations: the machines above.

Each machine above is named by just two things -- its group and its own name -- and those two generate all of its attributes:

nixosConfigurations.<group>-<machine>                    the system itself
packages.<group>-<deployment-method>-<machine>           deploy that system
packages.<group>-<deployment-method>-<machine>-<verb>    one per verb of it

So the operator group's mastodon machine is the operator-mastodon NixOS configuration, deployed by operator-tf-incus-mastodon (and inspected with operator-tf-incus-mastodon-plan, and so on). The nixosConfigurations are not enumerated anywhere else on this page: the lists above already are that enumeration.

Standalone effects

Effects are imperative actions exposed thru our CLI's nix run commands. Stateful operations are typically run using OpenTofu. If an effect uses NixOS configurations, we call it a deployment method. Stand-alone efects are our lower-level construct, that without being wrapped by setups have no notions of our components.

Hand-bound standalone effects

A few attributes are written out one by one in core/render/catalog.nix's standaloneEffects instead of coming from a group. Two of them are named for the dev group but are not generated from it, and the third is named for no group at all, so its attribute is the bare <name>, plus <name>-<verb> where the effect is an OpenTofu graph.

What keeps them out of the cross-product is that each one precedes what would generate it. The base image every Incus container is created from is a prerequisite of the terraform-backend node itself, so it can keep no state behind that node, and it is built from a fixed local-dev configuration rather than a group's roster. The bootstrap that mints the local-dev deployer's credentials is a shell runner and not an OpenTofu graph, which is why it has no verbs. The NetBox seed creates the cluster and the tag a tf-incus deploy then reads by name, so it cannot be one of that deploy's own steps.

Verbs

Every OpenTofu-backed deployment method also exposes one attribute per tofu subcommand, appended to the deployment attribute name: apply, destroy, plan, refresh, validate, output, show, state-list, state-show, import, force-unlock. The verb-less attribute runs the deployment end to end; ssh has no verbs because it does not go through OpenTofu.

Deployment methods

A deployment method is an effect involving NixOS configurations. Setup modules in core/setups/ wrap these to plug in given groups' NixOS configurations, so that their exposed options may be serializable to facilitate UI generation through JSON-Schema.

|

Environment variables

No deployment coordinate is written in the repository: which Incus host to provision on, which NetBox holds the addresses, which DNS service serves the zone and where the state lives are all read from the environment at evaluation time, through core/lib/lib.nix's optionalEnv (the raw string, or null when unset) and envOr (the JSON value, or a default). That is what lets one code base deploy for more than one hosting provider: the operator states the coordinates, and the same attribute builds a different deployment.

An unset variable is not an error, unless its default below is "the deploy stops". Each reader turns it into "not stated", and the option behind it keeps its default -- so a deployment states only the coordinates that differ from the defaults.

Every variable below is declared as data, beside the reader that consumes it (core/effects/env-config.nix for the methods, the pseudo-modules in core/effects/common/ for the variables every method reads, core/effects/common/standalone-env.nix for the standalone effects, core/effects/common/node-identity.nix for the nodes). The same declarations are published as core.lib.deployEnvKeys for the front-end to forward, and the tables here are generated from them, so a reader that gains a variable gains a row.

Read by every deployment method

Read by some deployment methods

What each of those variables is for, and what applies when it is not set:

Read by the standalone effects

An effect projected out of a deployment's setup reads that deployment's coordinates, because it acts on exactly what the deployment allocated. An effect with none of its own is built from stated values. These are the variables each attribute reads: most of them at evaluation, and the switches of the octodns-zone verbs and the inputs of dev-tf-incus-bootstrap at run time.

What each of those variables is for, and what applies when it is not set:

Read by a deployed node

A node's own closure reads a second, smaller set, outside any method's reader: the names and addresses it has to know about itself and its peers. These are inputs to the system it builds, so changing one rebuilds the node.

How many attributes each family contributes

Other packages

• applications-catalog: What the components an operator deploys are called and look like.
• configuration-renames: The operator form's structured option-rename table ({ from; to; } entries), for migrating a stored configuration across renames.
• core-docs: Generate static site docs of nix options
• deployment-attributes: JSON list of the deployment attributes (<group>-<effect>-<machine>) this source exposes, for a detect-at-submit guard.
• frontend-configuration-schema: The front-end configuration JSON schema (the operator form that a front-end renders and validates against).
• garage-runtime-provider-schema
• incus-runtime-provider-schema
• inwx-provider-schema: The pinned INWX provider's resource schemas, filtered to the types the tf-inwx-* effects wrap.
• lldap-runtime-provider-schema
• netbox-provider-schema: The pinned NetBox provider's resource schemas, filtered to the types the tf-netbox-* effects wrap.
• openbao-runtime-provider-schema
• openprovider-provider-schema: The pinned Openprovider provider's resource schemas, filtered to the types the tf-openprovider-* effects wrap.
• porkbun-provider-schema: The pinned Porkbun provider's resource schemas, filtered to the types the tf-porkbun-* effects wrap.
• postgresql-runtime-provider-schema
• provider-application-schemas: JSON object of the schema of each application of provider-configuration-schema, keyed by the application name. Each schema validates a value for its application without the full schema.
• provider-configuration-schema: The operator form's JSON schema as the provider validates submissions against it: frontend-configuration-schema with this build's PIN_EFFECT collapse and HOSTING_CONFIG leaf prune applied.
• renames-log: Regenerate core/renames-log.json: the committed log of every option rename this tree has declared, so one retired from the pinned tree still migrates.
• settings-rename-candidates: Rank which added key each key a pinned upstream JSON Schema dropped most likely became, and emit the settings-renames.json entries that would carry a stored value across.

Checks

• applications-catalog: Hold the applications catalog to its index: every component has the artwork the index names.
• apps-tf: Deploy all services via OpenTofu and verify the result.
• apps-tf-incus: Deploy all services via OpenTofu into Incus containers and verify.
• contracts-chaining: NixOS test: contract chaining (multiple providers in sequence).
• contracts-credential-environmentfile: NixOS test pinning that a systemd credential cannot be consumed as an EnvironmentFile=.
• contracts-credentials-creds-openbao-ordering
• contracts-credentials-hardcoded-credential: NixOS test: credentials contract with hardcoded-credential provider.
• contracts-creds-openbao
• contracts-cross-node: NixOS test: cross-node contract evaluation.
• contracts-filebackup-hardcoded-file-backup: NixOS test: file-backup contract with hardcoded provider.
• contracts-filebackup-restic: NixOS test: file-backup contract with the restic provider, on a local repository.
• contracts-filesecrets-hardcoded-secret: NixOS test: fileSecrets contract with hardcoded-secret provider.
• contracts-generatefiles-vars: NixOS test: generateFiles contract with vars provider.
• contracts-generatefiles-vars-independent: NixOS test: generateFiles instance growing a file with independent = true.
• contracts-generatefiles-vars-openbao: NixOS test: generateFiles contract with vars-openbao provider.
• contracts-ldap-lldap: NixOS test of the lldap-backed ldap contract provider.
• contracts-ldap-openldap: NixOS test: ldap contract with the openldap reference provider.
• contracts-oidc-dex: NixOS test: oidc contract with the dex reference provider.
• contracts-postgresql: NixOS test of the postgres-backed postgresql contract provider.
• contracts-postgresql-rotation
• contracts-redis-valkey: redis contract behavior test with the reference valkey provider (ACL-isolated namespaces).
• contracts-s3-garage: NixOS test: s3 contract with the garage reference provider.
• contracts-secrets-openbao: NixOS test: the secrets-openbao envSecrets/fileSecrets providers.
• contracts-smtp-maddy: smtp contract behavior test for the maddy-backed relay provider.
• contracts-smtp-opensmtpd: NixOS test: smtp contract with the opensmtpd reference provider.
• contracts-ssl-self-signed: NixOS test: SSL contract with self-signed provider.
• contracts-streamingbackup-hardcoded: NixOS test: streaming-backup contract with hardcoded provider.
• contracts-streamingbackup-restic: NixOS test: streaming-backup contract with the restic provider, on a local repository.
• core-docs: Generate static site docs of nix options
• deployment-cd-env-credentials: Unit-test the private directory CD stages credentials into and its lifetime, which is what keeps a deployer credential off a shared runner's disk past the job.
• deployment-cd-env-host-key: Unit-test the hypervisor host-key pin CD stages, which is what keeps a shared-store deploy from trusting whatever answers on the address.
• deployment-cd-env-incus-identity: Unit-test the shared-store identity CD stages, which is what a deploy of a hosting provider's containers lands each closure over.
• deployment-cd-env-kv: Unit-test the KV read CD stages coordinates by, which is the one path every value read back out of a deployment's own OpenBao takes.
• deployment-cd-env-oidc: Unit-test the OIDC exchange CD mints its deployer token by, which is what keeps every deployer credential short-lived and off the forge, and the SSO login a workstation mints it by.
• deployment-cd-env-profile: Unit-test the profile dispatch of the CD coordinate staging: which coordinates each profile trims and which it refuses to deploy without.
• deployment-domain-claim-probe: Unit-test the read of the operator lane's domain ledger, which decides whether a deploy registers a name, adopts it, or refuses.
• deployment-eval-cache: Unit-test the record that lets the seed pass and the deploy pass of one node share a single NixOS evaluation, the key material that must make that record miss, and the SBOM build that the deploy starts and collects.
• deployment-k8s-hosts: NixOS test of the k8s-hosts deploy method: it pushes the image of one node to a registry, applies the Deployment to k3s with OpenTofu, keeps the address of the pod on eth0, lets only pods in the namespace of the target connect to the node, keeps /var/lib on a volume and the machine ID from the pod, has no changes to plan after, and sets the Deployment back to the previous image when the new pod does not become ready, with the state and the machine ID of the node.
• deployment-migration-quiesce: Unit-test the quiesce of the export of a migration: the services of each node stop before the first mint, and a failed export starts them again.
• deployment-nixos-hosts: Sanity-check direct NixOS deployment of a trivial host.
• deployment-registrar-domains: Unit-test the read of the domains of the registrar account, which gives the alert rules the expiry, the renewal and the holder of each domain.
• deployment-registrar-transfer: Unit-test the command that gives the auth code of a domain of the registrar account for a migration, and that makes the code invalid again.
• deployment-remote-path-fallback: Unit-test the PATH fallback a remote command carries, which is what reaches a node whose own PATH resolves nothing.
• deployment-ssh-host-key: Unit-test the host-key options of the SSH deploy, which are what make a deploy refuse a node that shows a different key.
• deployment-ssh-hosts: Sanity-check SSH-based deployment of a trivial host to two targets that take a login only on a port that is not 22: the deploy reaches one target through the sshOpts of its own SSH_NODES entry and the other through SSH_CONFIG_FILE, and accepts only the pinned host key of each target.
• deployment-ssh-recovery
• deployment-tf-hosts: Sanity-check OpenTofu deployment of a trivial host.
• deployment-tf-hosts-bootstrap: Graceful fresh-provider TF-backend bootstrap (local-then-migrate, #336/#882).
• deployment-tf-incus-decisions: Plan the incus graph with mocked providers and assert on what it decides from its tfvars: the shared store only for a container, from the stub image and with no shift, the form of the public NIC eth1 per uplink mode, and the NetBox records only for the nodes with needs_public_ip.
• deployment-tf-incus-hosts: Sanity-check OpenTofu deployment into Incus containers.
• deployment-tf-incus-operator: Run the operator graph's garage/OpenBao half: mint a namespace's cache-backup bucket and key, and a media bucket with CORS rules, on a shared garage node, check the CORS rules, publish the pair into OpenBao KV over the :8200 TLS listener, then destroy and check that the buckets and the deployment's KV are gone.
• deployment-tf-incus-operator-decisions: Plan the operator graph with mocked providers and assert on what it decides from its tfvars: the plan fails when the NetBox prefix of the operator deployments on the bridge is not the prefix of the firewall gate of the hosting provider, the bridge ACL limits each node of the hosting provider with a known address to its own ports and fails on an address outside the prefix of the hosting provider, and the plan selects the registrar resources from the domain registration, the claim in KV and the state of the name at the registrar, and suspended, migration_exported and the DNS lane decide the hold of the zone, the resume gate, the migration marker, the records, and the start or stop of the instances, and the graph publishes a garage key to KV with write-only arguments whose version comes from the key ID.
• deployment-tf-self-state-reachable: Unit-test the netbox self-state reachability probe (fresh-provider DHCP fallthrough, #833/#882).
• deployment-tld-handles-probe: Unit-test the read of which contact roles a domain's extension has at Openprovider, which decides the contacts the operator lane's registration names, and of whether the account holds the nameserver group the registration names, which decides whether the deploy adopts the group or creates it.
• deployment-unit-parsers: Unit-test the readers of the shared deploy body that turn systemctl output into unit sets, ages, periods and verdict inputs.
• deployment-verdict-chain: NixOS test of the secret-chain gate a verdict-only pass runs before judging, through an SSH deploy of one host: it waits for the chain to converge, gives up early on a member that took its terminal branch or stopped moving, names the member at fault, and sweeps only once the chain is up.
• deployment-verdict-failed: NixOS test of the deploy verdict's failed-unit reading, through an SSH deploy of one host: a deploy that leaves a unit failed exits non-zero and names it, on this apply and on the next; DEPLOY_STRICT_UNITS=0 keeps the name and drops the exit code; a verdict-only pass judges the node without deploying to it; the sweep revives a unit parked in start-limit-hit once what it waited for has arrived; and a verdict-only pass does the reloads, restarts and starts an interrupted switch left in /run/nixos, unless a switch holds the lock.
• deployment-verdict-loop: NixOS test of the deploy verdict's restart-loop watch, through an SSH deploy of one host: a loop is reported without failing a deploy, a verdict-only pass fails every loop still attempting in windows sized from the widest declared RestartSec, a declared DEPLOY_LOOP_BUDGET delays that verdict and never lifts it, the one loop no window can measure is forgiven out loud, a start job is judged by its age, a unit cycled by something other than systemd is named with no restart to show for it, and a unit systemd retries is not named there but given to the loop watch.
• deployment-verdict-spawn: NixOS test of the deploy verdict's host spawn fault reading, through an SSH deploy of one host: a unit the manager never spawned is named without blaming the closure, a Result=resources with nothing said about spawning keeps its ordinary attribution, and a verdict-only pass retries the fault and reports the recovery.
• deployment-zone-keys-probe: Unit-test the read of the key-signing keys of a zone that deSEC holds, which a registration hands the registry for the DS records of the delegation: the operator lane's, with the token of the zone read from the KV subtree of the deployment, and the apex's, with the token read from the file the deploy names.
• integrations-acme-rate-limit: NixOS test of core/setups/nixos/acme-rate-limit: a stub ACME server refuses each order with rateLimited and a Retry-After. The boot completes as degraded, the order unit is failed with status 75, and the end of the limit is in the state directory and in the gauge acme_rate_limited_until_seconds. A start before that time sends no order, and the transient retry timer orders again when the limit ends. An order that fails for another reason removes the limit, the gauge and the timer.
• integrations-apex-key-mint: Runs the apex signing key's generateFiles generator under exactly the PATH the vars backend gives it -- unset PATH; PATH=<runtimeInputs>, which REPLACES the environment rather than prepending to it -- and asserts it emits a DNSKEY plus a state file carrying the KSK:/ZSK: roles dnssec-policy adopts a key by. Every other assertion about this generator is made against its text, and a generator whose declared inputs do not cover its script is invisible to those: it fails only when it runs, as exit 127 on the node.
• integrations-audit-shipper-series: NixOS test of the guard on the version of the OpenTelemetry collector of the audit shipper: a node with no record records the version of the package without a copy, an upgrade copies the state directory while the shipper is stopped and keeps only that copy, a downgrade is refused with exit status 78 until the copy is put back, after which the lines in the queue and the lines after the cursor of the copy arrive, and an upgrade without room for the copy is refused with exit status 78.
• integrations-authelia-series: NixOS test of the guard on the version of authelia: a fresh installation records the version of the package without a dump, an upgrade dumps the database through the backup command of the streamingBackup contract and keeps only that dump, and a downgrade is refused with exit status 78 while authelia stays stopped and the data stays.
• integrations-await-incus-static-address: await-incus.sh restarts the DHCP client of a running guest that does not have the static eth0 address of its NIC.
• integrations-bind-series: NixOS test of the guard on the version of BIND: a node with no record records the version of the package without a copy, an upgrade copies the state directory while named is stopped and keeps only that copy, a downgrade starts named with a warning and records the older version, and an upgrade without room for the copy is refused with exit status 78 while the zone stays.
• integrations-boot-counting: NixOS test of the boot counting of core/setups/nixos/boot.nix: the first boot of a host is counted, and systemd-bless-boot marks its entry good only after boot-check-gateway gets an answer from the default gateway. A new generation whose gateway does not answer fails its check, reboots, and after bootCounting.tries boots systemd-boot boots the good generation again, on which the check does not run. PID 1 arms the emulated hardware watchdog. A generation whose check waits for a unit that never gets ready reboots at the job timeout of boot-complete.target, and systemd-boot then boots the good generation.
• integrations-bootstrap-backup: NixOS test that the bootstrap backups restore on the node that made them and on a new node: the raft snapshot of OpenBao with its escrowed unseal key, and the states of the terraform backend with their kmsKey. On a new node the restore without the key fails with a hint, and with the key that an admin decrypts and adds to the archive it gives the data of the old node. OpenBao seals the restored key to the new TPM, thus it unseals after a reboot.
• integrations-bridge-dns: NixOS test that the incus bridge dnsmasq, holding the deployment apex authoritatively, answers a served alias with an ADDRESS rather than a bare CNAME: a node's own lease under its instance FQDN, an alias onto that lease, a bucket under the garage wildcard, and the UI name that has no lease of its own; with a name it holds no record for still refused rather than forwarded. Every served domain of a deployment is such an alias, and a reply carrying the CNAME alone reads to a stub resolver as no such host -- which is what the hypervisor's own OIDC discovery fetch failed on.
• integrations-cd-jwt-login: NixOS test that CD can actually log in as the deployer: a stand-in forge publishes an OIDC discovery document and a JWKS over TLS and signs Actions-shaped tokens, and the fediversity-deployer role admits a run of this repository on the deploy ref with the deployer policy attached. Nothing else in the tree performs this login, so a broken role write -- a map-typed bound_claims sent as a string, or a bound_subject a later partial update left stale -- is an error no evaluation, plan or deploy verdict can see, and it deadlocks CD. The refusals are asserted too, a role that admits everything being the other way this write goes wrong: a pull_request run, a run on another branch, a run of another repository on the same forge, and a token minted for another audience all fail to authenticate.
• integrations-cold-start: NixOS test that a node deployed before its spire-server and OpenBao PKI exist still finishes activating: the cold-start fetches give up on a name that does not resolve, and the units waiting on them land in failed rather than holding switch-to-configuration's lock open forever, while spire-agent is left restarting on purpose -- its cold-start cycle is measured against the start-limit window, because a limit narrow enough to fire here would also cut off a deployment that is merely still converging. Also that the node keeps a usable trust store while its CA is absent, folds one in unattended when it lands, and re-runs the CA fetch on a timer rather than giving it a single attempt.
• integrations-destroy-detaches-state: A destroy of a graph that deploys its own state backend migrates the state down to the deployer first, so the teardown reaches the resources the backend node's death would otherwise strand.
• integrations-destroy-reports-left-behind: A failed destroy step of bootstrap-apply.sh does not stop the run, and makes it list the object and exit 4. In an apply, the same failure is not listed and the apply stays green when a create step of the replace writes the object again.
• integrations-dns-key-render: NixOS test that a fediversity.dns-master TSIG key render fails rather than emitting secret ""; when the secret it renders from has not landed yet. The producer of that path is backend-specific and the component cannot order on it, so the render can lose the race -- and losing it used to be silent, leaving named reloaded onto an empty key with the unit green and cmp matching from then on so nothing re-rendered. Also that the same unit renders once the secret arrives, and that the key it writes actually authenticates a signed update to the apex.
• integrations-dry-run-runs-nothing: DRY_RUN=1 makes a deploy package evaluate the system of each node and print its command, and run nothing.
• integrations-forgejo-series: NixOS test of the guard on the release series of forgejo: a node with no record records the release series of the package, an upgrade dumps the database while forgejo is stopped and keeps only that dump, a downgrade and an upgrade without room for the dump are refused with exit status 78 while the user stays, and a fresh installation is recorded without a dump.
• integrations-garage-provision: NixOS test of the garage node's own OpenTofu reconciler: it adopts a bucket and a key made with the garage CLI and keeps their ids, a bucket gets the CORS rules of cors and the run leaves no key, a second apply has nothing to change, a state with one for_each resource for the buckets moves to one resource per bucket without a change, a key with no render is pending until the render lands, a key in the state stays when its render goes missing, and a bucket and a key that leave the config are deleted, the bucket emptied first.
• integrations-garage-series: NixOS test of the guard on the release series of garage: a node with no record records the release series of the package without a copy, an upgrade copies the metadata directory while garage is stopped and keeps only that copy, and a downgrade and an upgrade without room for the copy are refused with exit status 78 while the layout and the buckets stay, and a fresh installation is recorded without a copy.
• integrations-garage-snapshots: NixOS test of the snapshots of the metadata of garage: garage makes snapshots of its metadata database in a directory outside the metadata directory and keeps the two newest snapshots, and a snapshot replaces a lost database while the buckets stay.
• integrations-grafana-series: NixOS test of the guard on the version of grafana: a fresh installation records the version of the package without a copy, an upgrade copies the SQLite database and keeps only that copy, and a downgrade is refused with exit status 78 while grafana stays stopped and the data stays.
• integrations-incus-bridge-acl: NixOS test of the isolation of operator deployments on the shared incus bridge: OpenTofu creates the ACLs of two deployments with the module of the operator deploy, each ACL drops exactly the rest of the operator prefix and the ports of the provider that are not in operator-reach.nix, and imageless containers with the NIC keys of instance.tf get their static addresses over DHCP. The nodes of a deployment reach each other, the nodes of the provider in the two directions, and the gateway and its DNS; they do not reach a port of the provider that is not in the list, or the nodes of a different deployment, the egress rules and the ingress rules each drop on their own, and a rule for one node of the provider limits only that node.
• integrations-incus-oci: NixOS test that Incus runs our NixOS guest as an OCI container from a locally imported image, own-store and shared-store, with systemd as PID 1, the Incus /etc binds removed, and no raw.lxc, also in a restricted project; it records how the DHCP client of Incus and the guest's networkd work together.
• integrations-incus-shared-store: NixOS test that an imageless incus container boots off the host's own /nix/store, bind-mounted read-only the way nixos-container does it under systemd-nspawn: no image, LXC's init pointed at a per-container profile the host owns and which doubles as the host-side GC root, and a rootfs holding no copy of the closure it is running. Booted in two device shapes -- store-only, and store plus the nix daemon socket and database -- because sharing the daemon lets any tenant drive builds on the hypervisor and enumerate every other tenant's closure; the check records which in-guest nix usage the store-only shape costs, which is the evidence that decision is made on.
• integrations-incus-token-publish: NixOS test that incus-deploy-token-publish proves both ends before it mints: with the KV endpoint away, the unit fails having minted no trust token, which is what makes its unbounded retry safe on work that is not idempotent. Also that it publishes again once the endpoint is up, and keeps publishing across the two ways its work is undone without it ever failing -- the KV emptied by a cold rebuild of the fleet, and the token revoked at the daemon -- while a run with the pair still whole mints nothing, which is what makes the refresh timer safe.
• integrations-k3s-oci: NixOS test that k3s runs the rootfs of our OCI node image as a pod with systemd as PID 1, and that the node takes its allocated addresses and peers from a ConfigMap volume at boot and on each change.
• integrations-lldap-provision: NixOS test of the lldap node's own OpenTofu reconciler: it adopts a seeded user, group and membership that exist and does not make them again, a second apply has nothing to change, a state from before the per-object labels moves to them without a change, a seeded user, a group and a membership that leave the config are deleted, users, groups and memberships that it did not seed stay, and a retained user and membership that leave the config stay and leave the state.
• integrations-lldap-series: NixOS test of the guard on the version of lldap: a fresh installation records the version of the package without a dump, an upgrade dumps the database through the backup command of the streamingBackup contract and keeps only that dump, and a downgrade is refused with exit status 78 while lldap stays stopped and the data stays.
• integrations-maddy-series: NixOS test of the guard on the version of maddy: a node with no record records the version of the package without a copy, an upgrade copies the state directory while maddy is stopped and keeps only that copy, a downgrade starts maddy with a warning and records the older version, and an upgrade without room for the copy is refused with exit status 78 while the mailboxes stay.
• integrations-mariadb-series: NixOS test of the guard on the release series of MariaDB: a node with no record records the release series of the package, an upgrade copies the data directory while MariaDB is stopped, keeps only that copy, and runs mariadb-upgrade while it keeps the data, a downgrade and an upgrade without room for the copy are refused with exit status 78, and a fresh installation is recorded without a copy.
• integrations-media-backup: NixOS test of the media backup of an application on a garage node: a backup encrypts the names and the content of the objects and leaves out the excluded ones, a second backup with no change transfers nothing, an empty credential stops the backup, a restore puts back a deleted object, an overwritten object with its content type and a bucket that was deleted and made again, a restore at a stamp puts back the versions of that backup, an erasure deletes an object from the backup and all of its history, and a retention of 0 days keeps no history.
• integrations-migrate-after-failed-apply: A cold bootstrap-apply.sh whose apply fails after allocating still migrates its state to the HTTP backend, and still reports the failure.
• integrations-migrate-target-hint: The bootstrap's migrate wait names BOOTSTRAP_TUNNEL_SSH when it is waiting on a host-internal bridge lease, and stays quiet when it is not.
• integrations-migration-restore: NixOS test of the migration of the state of an application to another network: mint gives the public HTTPS endpoint of the S3 API and the bucket with the path of the repository in it, or the internal endpoint without migrationRepository, and restore-foreign on a target that cannot get to the internal endpoint restores the files through the public endpoint.
• integrations-migration-restore-boot-wait: When the boot of a node does not complete after the restore of a migration, the restore tells that the boot did not complete and names the start jobs that still run. A complete boot is ok, and a boot with a failed unit names the unit.
• integrations-octodns-bind: NixOS test of the OctoDNS bind provider into our own named over RFC2136: the group-derived zone pushed into the live primary, transferred to the group's second nameserver with its challenge delegation and refused to anyone else, a peer resolving group nodes through the primary, and verify finding both nameservers serving every record, naming one the primary dropped, and setting aside the glue address the deployer has no route to; then the self-held apex rendered from NetBox under a publisher key read out of the KV, keeping its delegation at the short TTL, withdrawing a record it no longer names, failing on a credential the store does not hold, and relaxing the record but not the credential under the additive switch.
• integrations-octodns-desec: The octoDNS desec provider at a stub of the deSEC API, as a provider apex at deSEC publishes: each TTL under the minimum TTL of the domain is raised to it, the ownership markers too, so that the bulk write is not refused; the record that no config names survives; a second sync writes nothing; and the token is the one that service.tokenFile names.
• integrations-octodns-kv-txt: NixOS test of the KV-sourced TXT record in every way its read fails, at a third party's PowerDNS: a value the store does not hold and one that is not a key both fail the render after rendering the rest and fail the verbs before anything is published; a refused token names the token rather than the record; a deployer with no coordinates skips the record out loud and publishes the rest; and OCTODNS_NO_WITHDRAWALS leaves a record an earlier publish owned standing while the same sync without it withdraws it.
• integrations-octodns-netbox: NixOS test of the zone rendered at run time from what NetBox recorded and pushed at a third party's PowerDNS: allocated addresses at the short node TTL, served-name aliases including a wildcard, a static host, a multi-label _acme-challenge delegation answered as a referral, the mail policy TXT records, and the DKIM key read back out of the deployment's KV in two character-strings -- each reaching the live zone with its ownership marker, an unallocated or foreign node skipped out loud, and the next plan a genuine no-op.
• integrations-octodns-powerdns: NixOS test of the OctoDNS PowerDNS provider at a third party's PowerDNS, on MariaDB: a whole zone pushed at an empty one, then partial-zone ownership over zones that already hold records nobody here wrote -- the unowned sibling and apex NS survive, a record that would land on an unowned one is refused until an operator deletes it or adopts it by marker, and a publish that moves every record it owns is not refused for its size.
• integrations-openbao-pki: Test the OpenBao PKI secrets engine as an internal-CA contracts.ssl provider, for an nginx vhost and for the LDAPS listener of lldap.
• integrations-openbao-series: NixOS test of the guard on the release series of OpenBao: a node with no record records the release series of the package and does not restart, a switch to a newer release series does not restart OpenBao, a restart of OpenBao copies its state directory while OpenBao is stopped and keeps only that copy, and a restart after a failure on an older release series and an upgrade without room for the copy are refused with exit status 78 while the secrets stay.
• integrations-openbao-spire-ca-bundle: OpenBao installs a SPIRE CA bundle from its own agent only when each block parses and a CA is valid now, and otherwise keeps the bundle and the cert auth roles it has.
• integrations-operator-registrar: Applies the registration of the tf-incus-operator effect (registrar.tf) against a fake registrar API and a dev OpenBao: a premium name or a quote above max_cost orders nothing, a quote at the bound registers with the renewal of the lane, and a destroy keeps the registration in the account with its renewal off. With claim_held_domain, a name that the account holds is adopted with no order. With the auth code of a migration import, a name that a different account holds is transferred once, the deploy fails until the transfer is complete or when the registry refused it, and the auth code is deleted from KV when the transfer is complete.
• integrations-plan-does-not-apply: A plan against an effect that declares no HTTP backend stays a plan, even with TF_HTTP_ADDRESS set.
• integrations-podman-oci: NixOS test that podman runs the rootfs of our OCI node image with systemd as PID 1, and that the node takes its allocated addresses and peers from a bind-mounted directory at boot and on each change.
• integrations-postgres-upgrade-dump: NixOS test of the dump of the guard of an application on the path of a live node: the backup command comes from the routed postgresql result through core/components/shared/postgres-backup.nix, an upgrade dumps the database of a different node over TLS with the rendered password and keeps only that dump, a dump that fails keeps the application stopped until a retry dumps the database. With an offsite backup, an upgrade makes a restic snapshot of the version before and removes the local copies, a snapshot that fails keeps the application stopped until a retry makes the snapshot, a snapshot that fails for UPGRADE_BACKUP_TIMEOUT seconds refuses the upgrade with exit status 78 until a start of the target, and a deploy of the version before an upgrade that did not finish restores the snapshot of that version.
• integrations-postgresql-major: NixOS test of the guard on the major of PostgreSQL: a fresh installation records its major, a switch to the next major upgrades the cluster with pg_upgrade and keeps the data and the old cluster, also after an upgrade that stopped halfway, a skipped major and a downgrade are refused with exit status 78, and a node with no record records the cluster in use and warns about the cluster that is not in use, but refuses when only a cluster of another major is on disk.
• integrations-postgresql-provision: NixOS test of the postgres node's own OpenTofu reconciler: it adopts a role and a database made the way ensureUsers/ensureDBOwnership made them and keeps their data, a second apply has nothing to change, a state with one for_each resource per type moves to one resource per object without a change, group roles get their BYPASSRLS, database privileges and memberships, a password, a VALID UNTIL, a membership and a role setting written by the engine or an app's bootstrapSQL are not drift, and a database, a role, a grant and a membership that leave the config are dropped, the database first, so an owner role that owns a table in its database drops too.
• integrations-publish-records: The publisher walks up to the zone that holds a name, and stops rather than climbing past a refusal that never reached the zone API. A retire fails when it cannot find the zone, when the key may not read the zone, or when it cannot release the record, writes the record that it left to LEFT_BEHIND_FILE, and is green when nothing holds the record any more. A publish writes the record that it wrote to WRITTEN_FILE. On the deSEC lane, the publisher writes at the minimum TTL of the domain, waits out a rate limit, creates the domain on a hold and keeps it on a release, and reads its token from the KV subtree of the deployment.
• integrations-publish-records-follow: NixOS test of named-operator-zones-follow on the provider's named primary, with a parent zone and the nameserver of a new provider: an operator zone with a migration marker that the parent delegates to other nameservers followed, copied from the new provider by a zone transfer that includes a name the zone did not have, by a walk of the NSEC chain that also gives such a name and deletes a name the new provider does not have when the new provider refuses the transfer of a zone it signs with NSEC, or by authoritative queries for the names the zone has when the new provider refuses the transfer of a zone it does not sign, and given the NS set of the new provider; the primary letting only the addresses of the transfer property transfer the zone; its release deferred until the parent moved the delegation, the copy is done and resolvers can no longer follow the old delegation, with the cache time from the TTL of the parent's NS records, also when the parent moved before the job saw the zone, and up to delegation_wait_seconds when the parent does not move; a resume refused while the zone is away, and a zone whose delegation comes back served as before; a zone that moved without a migration marker not followed, and dropped at once on release when the job never saw it delegated here; and the owner marker, so that only the last deployment that holds a zone releases it, and a hold by a different deployment removes the migration marker; and the transfer property and its time removed after the longest time that the follow job of the source needs it, which is the time of the job or the time property when that is longer, and by a release; and the TSIG keys of a migration, kept in a keys zone that only the apex key and the operator key may read: the export key, with which the job signs the transfer of a zone that the new provider lets no address transfer, and the transfer key, which the primary lets transfer the zone while the transfer property stays, both refused when not the base64 of 32 bytes and removed with the transfer property or by a release.
• integrations-publish-records-named: NixOS test of the operator graph's record publisher over its RFC2136 lane, against the provider's own named primary and secondary as the bind component renders them: an app name published, repointed and released at any depth below the apex; the provider's own names and the apex refused by the server even with the publisher's own refusal list bypassed; every type but the address types refused to the operator key while the zone publisher's key still writes anything; a wrong secret, a name under no zone, and a retirement whose address moved on all leaving the zone as it was; then the operator zone lane: a domain of the operator's own added to the catalog, rendered into a zone the primary serves and the secondary provisions, a zone above the apex, above an admitted zone or below the catalog refused, the operator key held to member entries, and a member the provider prunes dropping the zone from both.
• integrations-reclaim-own-lock: A steady-state bootstrap-apply.sh with TF_RECLAIM_OWN_LOCK=1 releases a state lock left under its own identity and no other, and releases none without the flag.
• integrations-register-ek-evidence: A deploy that finds no EK reader in the container it stood up prints what that container runs, rather than naming one of the three faults the incus exec message covers, and a deploy gives the container only a trust bundle that holds a valid CA.
• integrations-registrar-guards: Applies the Porkbun and Openprovider domain effects against a fake registrar API: a quote above max_cost orders nothing, a quote at the bound registers, and a plan -destroy of the registration is refused. An Openprovider registration with no period is quoted and ordered for one year.
• integrations-retire-records-follow-openbao: The retire of the DNS records of a node on the deSEC lane reads the OpenBao of the last apply, also after OpenBao moves, and the move of publish_app_records from a null_resource to a terraform_data replaces no record and publishes no record again.
• integrations-smtp-dkim: NixOS test that outbound mail leaves the relay with a DKIM signature a receiver can act on: the envelope sender arrives at the upstream rewritten to the smarthost account while the message still carries its original From: and a signature verifying as the organizational domain, in alignment with it.
• integrations-smtp-reports: NixOS test that the address the zone's DMARC rua= points at receives: a report arrives from a second container on :25, opened by the firewall only because reports are enabled, and leaves again for the operator's inbox while every other recipient is still refused.
• integrations-spire-incus: Test SPIRE TPM attestation of an incus-deployed node via its incus vTPM.
• integrations-spire-openbao: Test the SPIRE and OpenBao secret/identity integration.
• integrations-spire-register-name: spire-register-name creates, re-points or updates the entry of a name, and exits non-zero, with the error and with no new entry, when spire-server cannot read, delete or create an entry.
• integrations-spire-retire-name: spire-retire-name is a no-op with exit 0 for a name with no entry, deletes each entry of a name, and exits non-zero, with the error and with the drop-file kept, when spire-server cannot read or delete an entry. A destroy whose retire fails lists the host as left behind, with the error of the retire.
• integrations-spire-series: NixOS test of the guard on the release series of SPIRE: a node with no record records the release series of the package without a copy, an upgrade copies the datastore without the CA key while the server is stopped and keeps only that copy, a downgrade starts the server with a warning and records the older release series, and an upgrade without room for the copy is refused with exit status 78 while the registration entries stay.
• integrations-state-migrations: NixOS test of systemd.stateMigrations on a fake application: a fresh installation is initialized once, an upgrade runs only the steps in its version range before and after the restart of the application, a failed step restores its backup and keeps the application stopped, a downgrade or a skipped release series is refused with exit status 78, an existing installation without a version record is recorded, not initialized again, and a failed run that Restart=on-failure with RestartMode=direct retries keeps the start job of the application while a refusal is not retried. A second application with a restore and a privilegedBackup makes its backup as root, records a failed upgrade as upgrading, keeps the first backup when the upgrade is retried, refuses a third version with exit status 78, and restores the backup on a deploy of the previous version.
• integrations-steady-backend-freshness: A steady-state bootstrap re-run tunnels past a backend name that does not resolve to this fleet's tf-backend, and honors one that does.
• integrations-steady-refuses-backend-replace: A steady-state apply of a graph that deploys its own state backend refuses a plan that deletes or replaces the backend node, and applies every other plan.
• integrations-steady-refuses-lost-state: A steady-state bootstrap-apply.sh refuses to apply when the backend holds no state for a key this deployer has a fleet's worth of local state for.
• integrations-suspend-power: A suspended instance stops and does not start at boot, and a resumed one starts at boot and is waited for.
• integrations-tf-backend-front: Runs the state backend with its nginx front in a VM, and asserts that the front accepts a request for a state only from the deployer of that state, and that a state written through the front is stored under the ID that the existing states on a live deployment have.
• integrations-tf-backend-series: NixOS test of the guard on the version of the state backend: a node with no record records the version of the package without a restart of the backend, a switch to a later version does not restart the backend and a restart by hand copies the state directory and keeps only that copy, a restart on an earlier version is refused with exit status 78 until the copy is put back, and a restart without room for the copy is refused with exit status 78 while the states stay.
• integrations-tf-backend-state-id: The state backend stores a state under the ID that the existing states on a live deployment have.
• integrations-valkey-series: NixOS test of the guard on the release series of valkey: a node with no record records the release series of the package without a copy, an upgrade copies the RDB snapshot and the AOF directory while valkey is stopped and keeps only that copy, a downgrade starts valkey with a warning and records the older release series, and an upgrade without room for the copy is refused with exit status 78 while the keys stay.
• integrations-windmill-grants: Runs the bootstrap SQL of the windmill database request against a windmill database whose older tables belong to windmill_admin and whose newer tables belong to the login role, and asserts that the SECURITY DEFINER trigger of config fails with permission denied for table notify_event before it, and passes after it is applied twice, and that windmill_user and windmill_admin can write to a table that the login role makes later.
• integrations-windmill-series: NixOS test of the guard on the version of windmill: a fresh installation records the version of the package without a dump, an upgrade dumps the database through the backup command of the streamingBackup contract and keeps only that dump, and a downgrade is refused with exit status 78 while the three windmill units stay stopped and the data stays.
• lib-settings-rename-candidates: Unit tests for the rename-candidate suggestion tool: which schema paths it enumerates, how it ranks an added key against a removed one, and that the block it prints parses as JSON with the upstream field left for a human.
• license-report: Unit-test the license report of a node: the verdict of each component in a fixture SBOM, the license of the files that the configuration generates, the exit status, and the form of the license allowlist.
• nix-unit-components: Every nix-unit-components-* suite in one evaluation, as CI builds them.
• nix-unit-components-authelia: Unit tests for the authelia component: the operator sets the portal policy, with only a duration that the schema admits, but not the storage or the session cookies, the node gets the settings without null values, the storage takes the authelia result of the postgresql request, with TLS and the assertion that follow its sslMode, and the sessions take the authelia result of the redis request, with TLS that follows the result and a restart on a rotation of the password, or stay in memory without a result.
• nix-unit-components-hosting-provider-helpers: Unit tests holding the contract of the helpers that core.lib.components.hosting-provider exports for a front end that runs the hosting-provider group: the exports are the ones the spec names, operatorCuration needs only the netbox and dns results and refuses a missing or mistyped one, deployCredentials puts its KV paths on the stem of the coordinates given and refuses a missing or mistyped curation, and machine names the node for its application and refuses a name that is not a string.
• nix-unit-components-incus-deploy-tokens: Unit tests for when incus-deploy-token-publish mints the trust token pair of a deploy runner again: only when one of the two KV entries or one of the two daemon-side names of that runner is missing, with the guard of the rendered shell the same checks joined by &&, and the mint writing the same names and KV paths the guard reads.
• nix-unit-components-incus-oidc: Unit tests for what the incus server takes from the oidc result: the issuer and the scopes of the incus result only, nothing without that result, and the PKI bundle only for an https:// issuer with a PKI CA file.
• nix-unit-components-incus-store-identity: Unit test holding the store-serve identity constants the windmill worker's _jobenv.py restates to incus-store-identity.nix, the file its nix-side consumers read.
• nix-unit-components-mastodon-oidc: Unit tests holding the mastodon OIDC client secret env file to the units that serve logins: the migration oneshots, which never read it and hold back every unit that they order before, are not given it.
• nix-unit-components-netbox-consumers: Unit tests for what the netbox node renders from the oidc, smtp, otel and postgresql results of netbox, and nothing without them: each unit loads the credentials it reads under keys that do not collide, the OTel wrapper keeps the configured package, the database replaces the local one, the API token goes to a KV instance that the node can write only on a node with the OpenBao vars backend, and the version guard dumps the database before an upgrade, and puts the dump back with its restore, only on a node with the offsite backup.
• nix-unit-components-openbao-init: Unit tests holding what Nix puts into the openbao-init unit: the script enables only the secret KV v2 mount with one key share, seals at an owner TPM handle that is not the endorsement key, waits for the TPM for less time than the start timeout, and wants rather than requires openbao.service; the openbao-root-token command dials services.openbao.runtimeApi.
• nix-unit-components-openbao-spire-auth: Unit tests holding the cert-auth policies and roles of a small roster to the grants each roster entry kind gives: a write only on the own instances and never on a stem of the host name, a read only on what is named for the host, a namespaced host only under its own deployment, and one role per roster key bound to its SPIFFE ID and policy. A host that only an OIDC client, a relay or a DNS, ACME or incus-store roster names gets no policy and no role.
• nix-unit-components-operator-curation: Unit tests holding the provider's curation of the operator form to the deploy's own IPAM and DNS coordinates: the NetBox instance, cluster, tenant and pool an operator deploy allocates from, and the zone service it publishes app names to, are the ones the front-end node's netbox and dns requests resolved; a self-hosted named opens no write lane, and the curation restates none of its own.
• nix-unit-components-windmill-workspace-imports: Unit tests holding the windmill scripts' workspace imports to the set the bootstrap uploads, and holding the deploy and destroy scripts to one shared job environment: a module nobody uploads fails a job at its first line, and an environment written twice drifts into a destroy the deploy's credentials never reach.
• nix-unit-contracts: Every nix-unit-contracts-* suite in one evaluation, as CI builds them.
• nix-unit-contracts-lib: Unit tests for the vendored contracts lib extensions (nestedAttrsOf, evalOption, etc.).
• nix-unit-contracts-vendored: Guard test keeping the vendored copies of nixpkgs code (the dischargeProperties copy in the contracts lib, the replaced restic module) in step with the pinned nixpkgs, so a pin bump that changes upstream fails here rather than drifting silently.
• nix-unit-deployment-plan: Every nix-unit-deployment-plan-* suite in one evaluation, as CI builds them.
• nix-unit-effects: Every nix-unit-effects-* suite in one evaluation, as CI builds them.
• nix-unit-effects-common-lib: Unit tests for the common deployment-effect helpers.
• nix-unit-effects-octodns-types: Unit tests for the types of the octodns-zone options zone and providers.<name>.configuration: a record type that DNS does not have, a SOA in zone, a provider configuration value in place of an option declaration, a value of the wrong type, and a provider name that providers does not declare all fail at evaluation. Also that each provider makes its configuration and token secret from the same service coordinates, and that bind refuses a service.
• nix-unit-effects-registry: Unit tests for the effect registry: each effect declares an effect-meta or is in buildingBlocks, not both and not neither, and each name in buildingBlocks is an effect.
• nix-unit-effects-ssh-option: Unit tests for the form of an sshOpts item: a bare Key=Value passes, and an item in argv form such as -o Port=2222 fails at evaluation, in the host-ssh submodule and in the ssh-hosts settings. The form schema gives each item a pattern that admits the same items.
• nix-unit-effects-submitted-config: Unit tests for how a submitted configuration resolves against the baked one, which decides both the node configurations a deploy builds and which nodes it stands up.
• nix-unit-effects-tf-destroy-provisioner: Unit test holding every when = destroy provisioner in the graphs to taking its command off the environment rather than off the state: the deployer that destroys is not the one that created, so a runner or a key path recorded at create time names a store path from before the fix and a credential the job that staged it has since removed. Also that each such provisioner with on_failure = continue writes what it left to LEFT_BEHIND_FILE, that no destroy step reads a triggers key that ignore_changes holds (such a key keeps the value of the create, not a moved coordinate such as the address of OpenBao) other than as the fallback of a read of self.output, and that the effect of each graph with a lifecycle { destroy = false } resource, and no other effect, destroys with -suppress-forget-errors.
• nix-unit-effects-tf-incus-bootstrap: Unit test that dev-tf-incus-bootstrap gives its script the image alias of dev-tf-incus-image and the dev TF-backend address of core.lib.devTfBackend, and that the script holds no copy of them.
• nix-unit-effects-tf-incus-image-hostname: Unit tests that the image of tf-incus-image, evaluated as the effect does, has no /etc/hostname, thus each container keeps the name that Incus gives it, and that the image keeps the node name in networking.hostName. The node configuration without the image changes has the file.
• nix-unit-effects-tf-incus-plan-inputs: Unit test for the tfvars from which the incus graph makes its instance plan, rendered from real setups: which nodes go on the shared store, the probe of the replace guard, the uplink mode, which nodes ask for a NetBox address, the persistent volume of the state backend and its place in the wrapper guard, and that the self-read of the state of the hosting provider takes the credential of the deployer from the deploy runtime, not from the baked config, and that only a deploy with an http backend writes the addresses document that an operator deploy reads. Also that each rendered tfvar and node field is declared by the graph, because the graph does not fail on a name that it does not declare.
• nix-unit-effects-tf-provider-pins: Guard test asserting the OpenTofu provider versions written into tf/ still match the npins pins (derived rev/constraint, and no version literal in the HCL of netbox-seed).
• nix-unit-effects-tf-registrar-render: Guard test forcing each registrar effect's generated OpenTofu module to evaluate. Of these effects, only the Porkbun and Openprovider domain effects also reach an integration test, integrations-registrar-guards, which applies them against a fake registrar API.
• nix-unit-effects-tf-ssh-triggers: Unit tests that each node input of the tf/ssh provisioner, other than username and key_file, is in triggers_replace, thus a change of it alone deploys the node again.
• nix-unit-effects-write-config: Unit tests for the files that the deployer evaluates at apply time: the deploy-time configuration.nix keeps its store path across runs that differ only in the credential-staging directory of the deployer, each generated file defines the variables it uses, and the plan of a setup outside the tree resolves.
• nix-unit-env-adapter: Unit tests for the name-free env-adapter fold (pluggable getEnv, multi-module folding, recursive merge).
• nix-unit-env-config: Guard test asserting each effect reader's getEnv keys are declared in its envKeys (the core.lib.deployEnvKeys DRY invariant).
• nix-unit-lib: Every nix-unit-lib-* suite in one evaluation, as CI builds them.
• nix-unit-lib-application-schemas: Unit tests for the schema of each application, re-rooted from the provider schema.
• nix-unit-lib-data-model: Unit tests for the data model (core/lib/data-model.nix). A call of apply or process with an argument of the wrong outer shape fails.
• nix-unit-lib-function: Unit tests for the type-checked function type.
• nix-unit-lib-json-schema: Unit tests for JSON Schema draft 2020-12 (validating a value against a published schema, restating a schema of configuration keys as one of environment variables, narrowing one to what an operator is offered, upgrading an older draft, and the option type that carries a schema instead of being converted from one).
• nix-unit-lib-json-schema-suite: The JSON Schema draft 2020-12 implementation against the specification's own conformance suite, with a checked ledger of what it refuses and where it diverges.
• nix-unit-lib-lib: Unit tests for the general utility library.
• nix-unit-lib-nixos-service-options: Unit tests for wrapping an upstream NixOS service's options onto an application (a selection says what is exposed, ours shadow theirs at any depth, only operator-set values are forwarded back).
• nix-unit-lib-option-selection: Unit tests for stating which parts of a nested option structure we want: allow-lists and deny-lists at every layer, names ending in * that select by prefix, and a selected name the structure does not have throwing.
• nix-unit-lib-option-title: Unit tests for GUI-facing option titles and the word dictionary.
• nix-unit-lib-renames-for-source: Unit tests for structured option-rename extraction and schema pruning.
• nix-unit-render: Every nix-unit-render-* suite in one evaluation, as CI builds them.
• nix-unit-render-catalog-source: Unit tests holding that the source of each hand-bound standalone deployment of the catalog names a file of the repository that is not under core/checks/: an operator runs the attribute outside the checks, and the docs site names that file as its origin.
• nix-unit-render-env: Unit tests holding that every deploy coordinate the provider's curation fixes for the operator method reaches that method's setup arguments, the registrar lane (domainRegistration) included: the front-end node forwards the registrar login on the strength of the served curation, so a leaf the render never lifts opens the lane on one node and shuts it on the other.
• nix-unit-render-image-state: Unit tests holding that the generated image effect of the catalog bakes no HTTP backend and reads no TF_HTTP_ADDRESS, so its state is a local file on every provider: the image is uploaded before the TF backend exists.
• nix-unit-render-unset-apex: Unit tests holding that the name of each package and the description of each app evaluate when the apex is not set: nix flake show is a pure eval, where DNS_DOMAIN is not available, and one attribute that needs the apex for its name stops the whole listing.
• nix-unit-resources: Every nix-unit-resources-* suite in one evaluation, as CI builds them.
• nix-unit-resources-coordinate-consumer: Unit tests for the consumer side of the dns and netbox resources: each request resolves on the node to the contract result under its consumer name as plain data.
• nix-unit-resources-firewall: Unit tests for the firewall resource: dual-stack source classification, which ports are published rather than merely served, the fail-closed guards, the allocated addresses at the gate, the operator sources that reach only their own ports, then the bridge interfaces that reach only their own ports, before the trusted interfaces and the internal sources, the bridge ports that nixos-fw serves only on the bridge interfaces, and the component-request / environment-policy split.
• nix-unit-resources-garage-consumer: Unit tests for the consumer side of the garage resource: each requested bucket resolves on the node to an s3 contract result with its tenant-prefixed name and endpoints, as plain data. An ensureAccess entry with no permission stops the evaluation.
• nix-unit-resources-garage-forward-compat: Regression test for the #972 forward-compatibility rule: an old-shaped garage config evaluates against the renamed option and the value lands at the new path.
• nix-unit-resources-generateFiles: Unit tests for the generateFiles resource's vars provider wiring and fileSecrets bridge.
• nix-unit-resources-ldap-consumer: Unit tests for the consumer side of the ldap resource: a routed request gives the contract result as plain data on the node.
• nix-unit-resources-ldap-provider: Unit tests for the provider side of the ldap resource: the wants, the bind password and the key seed of the lldap node, and no output without a routed provider.
• nix-unit-resources-network: Unit tests for the apply of the network resource: the host name check, the CIDR split, the resolver order, the gateway suppression and the allocated address that replaces the address of the settings.
• nix-unit-resources-nixos-module: Unit tests for the apply of the nixos-module resource: the policy module and each requested module land on the node.
• nix-unit-resources-oidc-consumer: Unit tests for the consumer side of the oidc resource: a client request gives the contract result as plain data on the node, equal to the result that the provider gives.
• nix-unit-resources-oidc-ldap-backend: Unit tests for the account that Authelia binds to the directory as: authelia-bind with the OpenBao LDAP engine, the admin bindDN of the contract result without it.
• nix-unit-resources-oidc-policy: Unit tests for the apply of the oidc resource: clients versus forward-auth protections, the name of each protected UI, the admin-UI gate, and what the authelia node gets.
• nix-unit-resources-otel: Unit tests for the OpenTelemetry resource module.
• nix-unit-resources-plain-requests: Unit tests that every request to a resource whose clients render from resolved data holds only data, which survives a JSON round trip.
• nix-unit-resources-postgresql-converge: Unit tests for the postgresql resource's rotation convergers: which agent render restarts which consumer, in both credential modes.
• nix-unit-resources-redis-port: Unit tests for the deterministic per-namespace valkey port helper (known-answer + collision-freedom).
• nix-unit-resources-secrets: Unit tests for the secrets resource's agenix fileSecrets routing.
• nix-unit-resources-secrets-recipients: Unit tests for the recipients of the .age secrets: each secret goes to the host keys of the machines whose components request it, and the recipients stay equal to the ones that the .age files are encrypted to.
• nix-unit-resources-smtp: Unit tests for the process and the apply of the smtp resource: one want per application, the consumer result, the relay daemon and its secrets. apply takes the requests by app and refuses a list.
• nix-unit-resources-spiffe: Unit tests for the apply of the spiffe resource: an enabled request gives one spire-agent with the routing context, and no request gives nothing.
• nix-unit-resources-ssl: Unit tests for the apply of the ssl resource: the nginx vhost and port for each domain, no vhost for a self-terminated domain, and the request defaults.
• nix-unit-resources-ssl-openbao-pki-login: Unit tests for the order of the OpenBao login on an openbao-pki node: it starts before the issuing unit of each domain on the private CA, whose names need not match the host name, and before no unit when no domain is on the private CA.
• nix-unit-setups: Every nix-unit-setups-* suite in one evaluation, as CI builds them.
• nix-unit-setups-admin-emails: Unit tests on the realised nodes of the hosting-provider group for the consumers of the deployment email: on the telemetry node it gives one alert recipient for each ;-delimited address and has priority over the group data alertEmails, which gives the list when email is empty, and with neither the evaluation stops with an error that names ADMIN_EMAIL. The seeded directory administrator, the DMARC report forward and the ACME account get the first address.
• nix-unit-setups-apex-cohesion: Guard test asserting the deployment serves one apex: every served name across the group is a label under core/apex.nix, each alias of the static table of served-domains.nix is a vhost of the node it points to, and no other source file names that apex.
• nix-unit-setups-apex-group: Unit tests for the shape of a deployment's apex DNS group -- its nameservers, the secondaries it offers a transfer to, the keys its named mints per node, and whether it holds and uses a signing key -- under an external apex, a held one, and a held one with signing on.
• nix-unit-setups-apex-resolution: Unit tests on the realised incus node for where it resolves the apex: the routing domain pinning the split-horizon apex to the bridge link, that it lands on the same unit that carries the address, and the flat resolver list that makes the pin load-bearing.
• nix-unit-setups-apex-signing: Unit tests on the realised bind node for the unit placing the apex signing key: scoped to a signed apex we hold, fail-closed against named because a keyless policy mints a replacement, and -- being fail-closed over a secret that lands minutes later -- owning a retry and re-pulling the daemon whose start job its own failure discards.
• nix-unit-setups-app-vars-grant: Unit tests holding what an application node uploads to the central OpenBao KV against what that node's policy lets it write: the two are separate groups' evals, so an instance a component declares for itself and no roster grants shows up only as a 403 on a live deploy. Also that each node generates the repository password its restic backups read, else the credential is empty and the backups fail, and that only the backups of OpenBao and of the terraform backend have a fixed password.
• nix-unit-setups-backup-retention: Unit tests on the retention of the restic backups of the realised nodes of the hosting provider and of the shared operator services: the database backups of lldap and Authelia, which hold personal data, prune with backupRetention.application (30 days), and the backups of NetBox, Windmill, OpenBao, BIND, Grafana and the terraform backend, which restore the infrastructure, prune with backupRetention.infrastructure; and the shared PostgreSQL node has only the backup of its clusters before an upgrade, with no scheduled prune.
• nix-unit-setups-caller-groups: Unit tests for the groups from which the central group evaluates the model of an operator group or a central-login group: the groups of the caller, so a group that only the caller defines has a model, and an in-tree group that the caller does not give is not selected.
• nix-unit-setups-capability-node-lookup: Unit tests holding the values found by the capability of a component against the fixed names they replace: the OpenBao cert-auth roster, the node roster of the per-node form schema, the groups that get tf-incus-operator, and the OpenBao and NetBox nodes of the tf-incus-hosts self-read.
• nix-unit-setups-central-ldap: Unit tests on the realised nodes of the hosting-provider group for its LDAP setup: the lldap node seeds the administrator that the group data names in ldap.adminUser, a group with an lldap node that names none fails the eval, and the LDAP engine of the central openbao node serves its own directory at the bare ldap mount and gets the directories of the operator groups.
• nix-unit-setups-central-postgresql: Unit tests on the realised nodes of the central group for its PostgreSQL setup: the postgresql node accepts connections from samenet, and the database engine of the openbao node gets the roles of the roster.
• nix-unit-setups-default-configuration: Unit tests holding the group evaluation to one definition of default-configuration, with the configuration derived from the roster or stated by the caller, because a second definition of the same value doubles each listOf option in it.
• nix-unit-setups-delegated-zones: Unit tests on the realised bind node for the zones delegated inward to it: one per DNS-01 challenge name, each granting its own TSIG key one owner and one record type, and reachable from beyond the deployment either way -- for the validator's resolver, and for whoever answers for an apex we hold ourselves.
• nix-unit-setups-deployer-kv: Unit tests for the KV publish of the deployer coordinates an operator deploy reads back: which deployer publishes (the provider's own, holding a token) and which does not (an operator graph, a cold walk), that a CD deploy publishes the password of the operator deployer at the front of the state backend, that the deployer policy is widened to exactly the published keys, and that the deploy runners read each published key back but the manager token of the zone service.
• nix-unit-setups-dev-config: Unit tests on the realised forge and runner nodes of the dev group: the forge domain, the addresses its nginx listens on, the mail sender and the security.txt of the forge, the URL the runners connect to, the UUID and token of each runner, and the host labels.
• nix-unit-setups-dns-routing: Unit tests for the DNS self-hosted-vs-external gate: roster filtering, contract provider routing, the _acme-challenge zones delegated inward to the deployment's own named for a wildcard leaf's DNS-01 challenge, and the write lane an operator deploy publishes its app names over.
• nix-unit-setups-domain-claim-grant: Unit tests for who may write the operator domain claim ledger: the SSO policy a person logs in with may hand a name over, the operator graph's own token writes the same path, the rest of the central KV stays read-only from the UI, and the reader of the registrar account reads a claim by its name but cannot list or write the ledger.
• nix-unit-setups-firewall-policy: Unit tests for the environment's half of a node's firewall resource: the ACME and DNS additions concatenate their published ports on a node that has both roles, the public uplink still takes the default :22 off a node it delivers to, and the hypervisor adds the incus API, limits its container bridge to the ports of hypervisor-reach.nix and does not trust it, and limits the operator sources to the ports of the resources of the node.
• nix-unit-setups-forgejo-runner-pool: Unit tests for the CI runner pool of the dev group: the roster machines in the pool and the machine name of each, the instances, names and MemoryMax of each memory tier, the labels of each instance, the host-not-<peer> labels as the complement of the machine in the pool, and the assertion that the machine is in its own pool.
• nix-unit-setups-garage-key-minter: Unit tests for the deploy targets of a deployment on tf garage provisioning without the operator graph: the target fails when a key with pair files has no minter in the group, and evaluates when each key has one.
• nix-unit-setups-garage-kv-stems: Unit tests for the KV stems a garage request publishes into, and the OpenBao grants derived from them: the operator deployer may write every stem the graph publishes, the app node may read its own back, and both are granted again under the per-deployment KV prefix a namespaced deployment uses. Also the grants on the secrets that a retained *-backups bucket keeps: the deployer cannot reach them and can only create a retention record, and the garage node can delete them and the record with the bucket when the grace period of seven days ends, but cannot read a secret value.
• nix-unit-setups-group-zone: Unit tests for the hosting-provider group's derived DNS zone: which node records it carries, the static seam publishing the bare-IP hypervisor's browser-facing name.
• nix-unit-setups-hypervisor-config: Unit tests on the realised hypervisor node: the served UI port survives the firewall resource's own definition, the published UI name is the one its nginx terminates, the bridge dnsmasq answers for every name the central garage node serves, tpm2.target does not wait out a start timeout on a resource-manager device this host has no chip for, the wait where it is pulled in anyway is bounded, the wait of a container guest for its TPM devices is bounded, no TPM is left as the host's hardware-RNG source, the shared-store login identity lingers, the incus reconciler holds no hard edge on incus or its preseed, so that its retry also covers a failed start of either, and an OpenBao reconciler wants openbao-init but does not require it or restart with it.
• nix-unit-setups-hypervisor-reach: Unit tests on the realised nodes of the hosting provider and the realised hypervisor for the ports of the hypervisor that the nodes on its container bridge dial: each dial to the bridge address or to a name that the bridge dnsmasq resolves to it is in core/components/hosting-provider/hypervisor-reach.nix, each port in that list has a dial, the gate of the hypervisor accepts only these ports from incusbr0 and then drops all but ICMP, an unused port is closed to the bridge, the bridge is not a trusted interface, and the operator prefix reaches only the ports of instances.
• nix-unit-setups-internal-reach: Unit tests on the realised garage node for what the deployer can reach: the v2 admin API is served but unpublished, and the deployment's own peers cover both the incus bridge subnet and the routed public-segment addresses, and the operator deployments on the bridge reach only the ports of the object store.
• nix-unit-setups-k8s-config: Unit tests on the network of a realised k8s-hosts node: systemd-networkd does not manage eth0, the interface of the pod network, also when networking.interfaces declares it, the node does not run systemd-networkd-wait-online, and the gate of the firewall resource does not filter eth0, while it filters eth0 on the same node under ssh-hosts. Also that the host keys of sshd are on the volume of the state of the node (/var/lib), and that the SPIRE agent of the node attests with k8s_psat and reads the trust bundle from the ConfigMap of the deployment. Also that the OpenBao node of the hosting-provider group fails its assertions under k8s-hosts, as a pod has no TPM to seal the unseal key to, while its garage node passes them.
• nix-unit-setups-ldap-directory: Unit tests on the realised nodes for the KV path a group's lldap publishes its bind coordinates to and the central LDAP engine reads them back from: the engine cannot derive them, and an entry nobody writes is skipped in silence. Also the LDAPS leaf and the stop time limit of each lldap node.
• nix-unit-setups-ldap-grant: Unit tests on the realised hosting-provider openbao node for which cert-auth policy is granted read on which group's rotated LDAP bind credential: the grant is keyed by roster label, and a label naming no host emits no grant at all, which shows up only as that group's Authelia looping on an empty credential.
• nix-unit-setups-lldap-mail: Unit tests on both groups' realised lldap and relay nodes: the password-reset mail settings, the credential the submission password arrives by, the relay's account and local sender domain, and the publicly trusted leaf the relay's submission listener has to carry.
• nix-unit-setups-mastodon-trust: Unit tests for the mastodon node's PKI trust seam: the default hiredis driver reads no CA from the environment, which the TLS-only valkey connection needs.
• nix-unit-setups-migration-keys: Unit tests for the vars instances that a migration carries as the keys of a backup, on the realised operator nodes: the keys of mastodon, pixelfed and peertube that encrypt or sign data in their databases, the key seed of lldap, and the storage and OIDC keys of authelia.
• nix-unit-setups-migration-pointers-grant: Unit tests for the grant on the state pointers of a migration import: the operator deployer token may write, read and delete them under each deployment's KV prefix, the operator graph builds the path the policy names, and the token may rotate the bind user of authelia on the ldap mount of each deployment but not read its password.
• nix-unit-setups-minted-garage-keys: Unit tests for the own-group garage keys the group's garage node mints itself: that no bucket the provisioner creates is left without a key, that the pair renders where the import reads it, and which keys with pair files no route mints when a deployment on tf provisioning does not use the operator graph.
• nix-unit-setups-netbox-pinning: Unit tests for the NetBox register-vs-allocate rule: which nodes pin the address the group data names, and with which mask.
• nix-unit-setups-netbox-routing: Unit tests for the NetBox self-hosted-vs-external gate: roster filtering, contract provider routing, and the token-as-path secret seam.
• nix-unit-setups-node-selection: Unit tests for which roster nodes a deployment stands up: the component a node runs, the module-driven enablement backing the group-deploy default, that an explicit configuration is passed through and leaves unnamed nodes enabled, and the nodes an external NetBox or DNS service makes redundant -- including the wildcard that keeps bind anyway.
• nix-unit-setups-openbao-scoped-tokens: Unit tests on the realised hosting-provider openbao node for its scoped OpenBao tokens: each reconciler, the PKI leaf, the snapshot and the deployer token unit read their own token and no unit reads the root token. The policy of each token is held to the paths its unit uses, only the units that use root-protected paths get sudo, and no policy grants all paths, the ACL policies of other units, raw storage or tokens of any role. The deployer policies have no sudo, sys/ or auth/ path other than the child token, the CD and workstation deployer cannot write the token of the front-end node, and the SSO deployer login gives only the deployer policy.
• nix-unit-setups-operator-config: Unit tests on the realised operator application nodes: each runs the spire-agent it logs in to OpenBao with, carries the get_tpm_pubhash the operator deploy execs to allow-list its TPM, and keeps the data of the application in all its backups for 30 days: each restic backup prunes with --keep-within 30d (backupRetention.application), and the media backup keeps its history for the same number of days; and the media buckets of Mastodon and Pixelfed allow CORS GET only from the origin of the application, the media buckets of PeerTube from any origin for the players of other instances, and the backup buckets have no CORS rules.
• nix-unit-setups-operator-peers: Unit tests on the gate of a realised node of an operator deployment: it trusts the provider prefix of the incus bridge and not the bridge subnet, no source covers a node of another operator deployment, and it admits the addresses of its own deployment from the guest API sets.
• nix-unit-setups-operator-publish: Unit tests on a realised operator deployment: which names it publishes an address record for, which the hosting provider's own names hold back, and that its nodes allocate an address rather than pinning one, that the plan of each node holds only data, and that its nodes dial the central OpenBao by the static name its leaf carries.
• nix-unit-setups-operator-reach: Unit tests on a realised operator deployment for the ports of the hosting provider that its nodes dial: each dial to a node of the provider or to the bridge gateway is in core/components/hosting-provider/operator-reach.nix for a resource that the node supplies, each port in that list has a dial, the ACL of the bridge limits each node of the provider to the ports of the resources that the node supplies, and its nodes reach the object store at garage.<apex>, the FQDN of the central garage node.
• nix-unit-setups-overview-uis: Unit tests on the realised overview node for the browser UIs its page lists: only the nodes the deployment deploys, so an external NetBox gets no tile.
• nix-unit-setups-pixelfed-database: Unit tests for the pixelfed node's database: the central postgres from the postgresql result when routed, a local postgres on its socket when not, no mariadb in either case, the password only in the agent-composed .env, a backup that follows the database, and a refused verify-* sslMode.
• nix-unit-setups-pixelfed-rotation: Unit tests for the pixelfed node's secret rotation seam: the agent restarts pixelfed-data-setup only while active, so it must stay active and pass the restart to php-fpm and horizon; the list of old APP_KEY values is a file that the node generates.
• nix-unit-setups-pixelfed-trust: Unit tests for the pixelfed node's PKI trust seam: php-fpm's clear_env drops the manager's SSL_CERT_FILE, which the TLS-only valkey connection needs.
• nix-unit-setups-pki-trust: Unit tests asserting the runtime OpenBao PKI CA bundle is named to systemd units and not only to login shells, and that both names resolve to a file the node's own writes produce.
• nix-unit-setups-plan-data: Unit tests on the plan of each node of each tester group: it holds only data, thus no function, derivation, string with a store context, or path outside the repository. The JSON writer and reader of core/lib/plan-json.nix give the same plan back.
• nix-unit-setups-postgresql-render-gate: Unit tests asserting every unit that reads a database credential the openbao agent renders waits for that very file to carry a password, gives the render a bounded budget, and retries the run its own gate failed.
• nix-unit-setups-postgresql-roster: Unit tests for the two halves of one PostgreSQL roster -- what the shared postgres node pre-creates and what the central OpenBao database engine leases -- asserted against each other, a disagreement between them being invisible until runtime.
• nix-unit-setups-public-uplink: Unit tests for the public-uplink seam: which nodes the uplink delivers to, and the interface/gateway overrides that follow.
• nix-unit-setups-registrar: Unit tests for the delegation records a deployment publishes AT the registrar: that the surface is absent until a registrar is named and each spending or ordering coordinate is stated, that every resource gets its own state key, and that the apex DS reads the same as four fields or as the whole record the node writes.
• nix-unit-setups-resource-routing: Unit tests for which contract resources a deployment provides -- including the three routes that provide one while standing up no node of ours -- and for the eval-time assertion that fires where a node insists on a resource its deployment cannot provide.
• nix-unit-setups-served-aliases: Unit tests for the aliases and the mail records the hosting-provider setup derives from its components: each alias of the static table of served-domains.nix is in the derived aliases, an SPF record for each sender name at the CNAME target, and the relay label and the DMARC rua from the node that provides smtp.
• nix-unit-setups-served-domains: Unit tests for the served-domain map and the public zone built from it: which names are published, and which are dropped for want of a record to alias.
• nix-unit-setups-shared-reads-grant: Unit tests on the realised hosting-provider openbao node for which cert-auth policies read the credentials of the hosting provider's own services: each instance only by the nodes that use it, as a grant to every host gives each tenant node the keys to the deploy runners, the database engine and the telemetry bucket.
• nix-unit-setups-shared-store: Unit tests for which nodes boot off the Incus host's own /nix/store: the provider lane sharing by virtue of the lane, the operator lane keying on the scoped store-serve identity reaching it, and the per-node opt-out for a component needing a writable store.
• nix-unit-setups-smtp-relay-grant: Unit tests on the realised hosting-provider openbao node for which cert-auth policies are SMTP relays: the nodes that provide smtp in each group, by roster label, which alone read the upstream submission password and whose submission passwords only the nodes of the same group that send mail read, and which generate the authelia and lldap submission passwords.
• nix-unit-setups-smtp-routing: Unit tests for the SMTP provider policy: which provider a group submits through, which upstream account its relay authenticates as, and the DKIM domain that is the only identifier on this path DMARC can align.
• nix-unit-setups-spire-registration: Unit tests for which deployments register their nodes' EKs with a SPIRE server, and against which node: the provider's own, the operator's cross-group resolution of it, the group under the per-app method that registers nothing, and the evaluation failure where no roster publishes a spire node.
• nix-unit-setups-spire-roster: Unit tests for the SPIRE host roster the server prunes stale identities against: which nodes are on it, and under which name.
• nix-unit-setups-ssh-defaults: Unit tests for the per-node SSH identity the ssh deployment method resolves: the setup's own defaults, the operator map's defaults over them, and the per-node entry over both -- field by field, with sshOpts overriding rather than appending, the operator-facing keyFile renamed to the submodule's key-file, and a hostKey that only the per-node entry gives.
• nix-unit-setups-ssl-key-accounts: Unit tests for the accounts an ssl request names -- the user and the group the provider is asked to give the private key -- asserted against the account table of the node that issues the certificate, the request and the account being spelled in separate modules and install refusing a name it cannot resolve.
• nix-unit-setups-supporting-requests: Unit tests for the cross-group collection of supporting requests -- what the hosting provider's shared garage, postgres, openbao and authelia nodes read of the operator and hypervisor groups' requests -- including that a collection forces only the group it reads and that the raw machine facts force no model.
• nix-unit-setups-terraform-backend-config: Unit tests on the realised terraform-backend node, the component alone: the backend binds loopback only, the nginx front sends the requests for a state and the health check to it and serves only TLS, the bootstrap port of the front serves the same locations and is open to the internal sources but not published, a request for a state needs a password and a permission and the backend gets basic:fake-secret in place of the credential of the deployer, the state key is the file that generateFiles makes on the node and not an OpenBao secret, the service waits for generate-vars and not for an OpenBao agent, and a switch does not restart the service that holds the locks.
• nix-unit-setups-tf-backend-htpasswd: Unit tests on the realised state backend node of the hosting-provider group for the credentials of the deployers at its front: the TF_BACKEND_HTPASSWD env key has priority over the group data tfBackendHtpasswd, with neither the evaluation stops with an error that names TF_BACKEND_HTPASSWD, a user that is not a deployer fails an assertion, and the in-tree evaluation gives the test credentials.
• nix-unit-setups-tls-routing: Unit tests for the certificate-audience split: which served names stay on the private CA, which move to the public issuer, and where they go when there is no issuer -- including the names that reach a node without an ssl request at all.
• nix-unit-setups-tls-trust: Unit tests for which served domains a node trusts at the private CA root: a redis consumer trusts the node that provides redis, and a group with no provider of redis gives no valkey address to trust; the node that provides otel trusts the telemetry ingest CA, and so does a node whose component sets wiring.auditLog; the node that provides pki fetches no CA, and every other node fetches it.
• nix-unit-setups-valkey-config: Unit tests on the realised valkey node: every unit that reads the PKI CA off disk at start is ordered after the runtime fetch that writes it, the redis-commander config renderer owns a retry and re-pulls the UI whose start job its own failure discards, and each instance keeps its user set in an ACL file under its own state directory, rewrites that file's default line at every start, and saves the app password it repairs. Also that the redis-commander UI is behind the forward-auth vhost, which sends each request to the address that the UI binds, that the UI port is not open in the firewall, and that a node without the forwardAuth entry of the UI runs no UI. Also that its cache backups prune to the retention of the applications (backupRetention.application).
• nix-unit-setups-valkey-coordinates: Unit tests on the seam between the central OpenBao valkey-database engine and the valkey nodes it brokers for: the engine states no instance address of its own, never names the hosting provider's own valkey node, reads each address back from exactly the KV path that namespace's valkey node publishes it to, and renders each static role only together with its connection.
• nix-unit-setups-valkey-gate: Unit tests asserting an application's migration runner waits for a verified TLS connection to the cache it dispatches jobs on, and probes the address its own client uses.
• nix-unit-setups-valkey-tls-agreement: Unit tests asserting the valkey node and its pixelfed client agree on TLS: both read resources."cache".redis.tls.enable, with TLS turned off as well as under the PKI plan.
• nix-unit-setups-vars-prefix: Unit tests for the vars KV prefix rules: the shared prefix, the per-deployment subtree a namespaced deploy carries its id in, the + glob the provider's policies name it with, the cache-backup bucket name, and that the operator TF graph writes the subtree Nix names.
• nix-unit-setups-vars-reload: Unit tests for the converge a rendered vars file carries -- the units the openbao agent signals after it writes a file again, over each value a reader takes once and then holds -- asserted on the realised nodes, the render path and the reader being spelled in separate modules with nothing else to hold them together.
• nix-unit-setups-wildcard-tls: Unit tests on the realised garage node for the wildcard bucket-endpoint names: routed to the public issuer over DNS-01 where the deployment can answer one and to the private CA where it cannot, always under a cert name carrying no *.
• nix-unit-setups-windmill-config: Unit tests on the realised windmill node: its UI -- whose open-source build can do no SSO of its own -- is fronted by an authelia forward-auth vhost that redirects an unauthenticated browser to the portal, passes the job-log websocket through, and no longer registers a dead OIDC client with windmill's own settings API; it reads for itself, from its own OpenBao render files, each credential the front-end node keeps off the job it submits; and each worker gives every root:windmill render file to its dynamic group again before it starts.
• nix-unit-setups-zone-publication: Unit tests for the two independent questions behind one zone publication: where the records come from (external IPAM, read back at deploy time, or the eval-time zone) and where they go (an external service's API under a token, or this deployment's own named over RFC2136 under a TSIG key) -- including the apex delegation, which a self-held zone must state or plan for deletion.
• nix-unit-testers: Every nix-unit-testers-* suite in one evaluation, as CI builds them.
• nix-unit-testers-leaf-boundary: Guard test holding that no Nix file under core/ refers to a path of the api or panel leaves or imports the repository root entrypoint, and that no source file under core/ outside the specs and the docs names a source file, a node or an option namespace of these leaves in its text, with the samples that each scan must find and must not find.
• nix-unit-testers-machine-kind: Guard test holding that each VM of a NixOS test under core/ states, in the comment directly above it, the feature for which it cannot be a container, with the samples that the scan must find and must not find.
• nix-unit-testers-oidc-routing: Unit tests for what an app node templates in for single sign-on: a test deployment carrying no authelia node asks for no client secret, one carrying authelia does, and a production node keeps it regardless.
• nix-unit-testers-openbao-pki: Unit tests asserting the test OpenBao serverNodePki runs the PKI engine of production with a role for the bare test names, and that a test node issues its leaf at and fetches the CA from the openbao container only when that container serves the PKI engine.
• resources-secrets-agenix: fileSecrets contract conformance test for the agenix provider.
• sbom-vendored: Unit-test the step of the SBOM of a node that adds the npm packages, the Rust crates and the Go modules that a package vendors, against a fixture store, and the parents that the license report gives for them.
• test-forgejo-service: NixOS test of the forge node at run time: forgejo with MariaDB behind nginx and its Anubis gate, security.txt, the mailer against a stand-in relay, the access log, the dispatch of a job to a runner while another runner claims the oldest job, and a git-pages site that a forge user with push access uploads. It pins that the machine-readable repo paths (/raw/, info/refs, ...) reach forgejo unchallenged for a browser user agent carrying no Anubis cookie, while the expensive HTML views are still gated.
• test-incus-oidc-login: NixOS test of the OIDC login of the Incus UI and API through authelia and its lldap directory, with a script in place of the browser.
• test-incus-service: NixOS test of the hosting-provider Incus host.
• test-ldap-engine: NixOS test of the OpenBao LDAP secrets engine rotating the dedicated authelia-bind account in the lldap directory (mint, real bind, rotation survival).
• test-lldap-admin-release: NixOS test that a changed adminUser releases the recovery address from the account holding it, so the seeded directory admin lands under its new name instead of the create being rejected on every start.
• test-lldap-mail: NixOS test of lldap's password-reset mail against the real maddy relay: the rendered settings, the submission password staged as a unit credential, lldap's own transaction reaching certificate validation, a live authenticated send under its identity, and the reset through the forward-auth vhost of lldap's UI with no session.
• test-lldap-seed-isolation: NixOS test that an unseedable lldap user is reported without withholding another seeded user's groups.
• test-mastodon-service: NixOS test deploying the Mastodon service.
• test-monitoring-storage: NixOS test that collector signals reach the garage-backed Loki/Tempo/Mimir stores through the ingest vhost and are queryable back, that Grafana's datasources, dashboards and alert rules are provisioned with a live drilldown panel behind each rule, and that the provisioned datasources and contact points work after a change of Grafana's secret key, that a deliberately failed backup unit drives its rule to Alerting, and that the database and bucket sizes reach Mimir labelled with their deployment.
• test-netbox-consumers: NixOS test of the NetBox component on a running node: the postgresql, oidc, smtp and otel consumers, and the API token that the node writes to OpenBao KV.
• test-netbox-service: NixOS test of the hosting-provider Netbox service.
• test-otel-collector-service: NixOS test of the OpenTelemetry collector service.
• test-otel-wiring: NixOS test of OpenTelemetry collection wired across services.
• test-peertube-service: NixOS test deploying the PeerTube service.
• test-pixelfed-service: NixOS test deploying the Pixelfed service.
• test-valkey-service: NixOS test of the hosting-provider valkey node + OpenBao valkey-database engine (per-tenant ACL, rotation).
• tf-providers: Build the from-source OpenTofu providers, assert the plugin mirror holds each one at its pinned version, assert the lock file of netbox-seed selects the pinned netbox version, and assert each vendored schema still matches its provider, also the schemas of the declarative-runtime pairings.
• treefmt: Check that the project tree is formatted
• vulnix-report: Unit-test the report of the vulnix scan against a fixture and a stub forge: the summary, one issue for each new CVE of high or critical severity, and the check for an open issue.

Repo-root checks

• reuse
• treefmt: Check that the project tree is formatted