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-netboxdeploys thenetboxmachine of thehosting-providergroup with thetf-incusdeployment method: provision its Incus container and deploy onto it.operator-tf-incus-operator-all-plantakes theoperatorgroup, thetf-incus-operatordeployment method and thealltarget, and runs theplanverb: show what deploying every machine of the group would change, without doing it.hosting-provider-octodns-zone-applyruns theoctodns-zonestandalone effect for thehosting-providergroup with theapplyverb: publish the group's DNS records.operator-mastodonis the NixOS system configuration of theoperatorgroup'smastodonmachine -- the system the deployment attributes above build and activate.netbox-seed-planis the group-less NetBox seed with theplanverb: 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:
alldeploys each machine of the group to its own host, in one run.combineddeploys 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>.operatorFacing. The two are separate because they
disagree, and because they are answered at different scales:
operatorFacing 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:
dev2dev3dev4fediversity-ciforgejo
Deploy targets: the machines above, plus all, combined. NixOS configurations: the machines above.
hosting-provider
Published machines:
apiautheliabindgaragelldapnetboxopenbaootel-collectorpanelpostgresqlsmtpspiretelemetryterraform-backendvalkeywindmill
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:
mastodonpeertubepixelfed
Internal machines:
authelialldapsmtpvalkey
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.
| Effect | Setup | Groups | Verbs | What it does |
|---|---|---|---|---|
octodns-zone |
core/setups/tf-incus-hosts.nix |
hosting-provider |
validate, plan, sync, verify |
Publish the group's DNS records to its authoritative service (octodns-sync). |
tf-incus-image |
core/setups/tf-incus-image.nix |
dev (hand-bound), hosting-provider, hypervisor, operator |
the tofu verbs |
Run the tf-incus-image operator effect (OpenTofu apply). |
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.
| Attribute | Built from | Verbs | What it does |
|---|---|---|---|
dev-tf-incus-bootstrap |
core/effects/tf/incus/common.nix |
none | Provision the local-dev deployer's incus credentials + image (writes the TF_VAR_* env file at OUT_TF_ENV). |
dev-tf-incus-image |
core/checks/deployment/tf-incus-hosts/setups/image.nix |
the tofu verbs |
Upload the local-dev Incus base image (OpenTofu apply). |
netbox-seed |
core/effects/tf/netbox/seed/effect.nix |
the tofu verbs |
Seed a NetBox instance with the cluster, cluster type and attribution tag the incus deploy reads (OpenTofu apply). |
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.
| Deployment method | Setup | Verbs | What it does |
|---|---|---|---|
ssh |
core/setups/ssh-hosts.nix |
none | Deploy to machines that already exist, over SSH (nixos-rebuild-style); provisions nothing. |
tf |
core/setups/tf-hosts.nix |
the tofu verbs |
Deploy to existing machines through OpenTofu, so the deploy is state-tracked and replayable. |
tf-incus |
core/setups/tf-incus-hosts.nix |
the tofu verbs |
Provision the group's Incus containers and deploy onto them, in one OpenTofu graph. |
tf-incus-operator |
core/setups/tf-incus-operator-hosts.nix |
the tofu verbs |
As tf-incus, and additionally mints the group's per-tenant valkey/openbao resources; only meaningful for operator. |
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. 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
| Variable | Default | Description |
|---|---|---|
ADMIN_EMAIL |
The option default. | The address a deployment states as its administrative contact. |
ADMIN_SOURCES |
Permissive: a node publishes :22 instead of gating it, and the deployment has no operator lane. |
Comma-separated addresses or CIDRs, dual-stack, that every node admits to every port it serves. |
CD_OIDC_ISSUER |
No CD role: the issuer and the repository are required together, and half a pair reads as none. | The forge Actions issuer whose CI may authenticate to this deployment's OpenBao. |
CD_OIDC_REPOSITORY |
No CD role: the issuer and the repository are required together, and half a pair reads as none. | The owner/name whose runs that role accepts. |
DNS_API_TOKEN_FILE |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. |
Path on the deployer to that service's API token, read at run time so the token never reaches the store. |
DNS_DOMAIN |
No zone, and with no zone there is nothing to publish. | The zone the deployment publishes its names in. |
DNS_PROVIDER |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. |
The octoDNS provider that reaches that service (powerdns, desec, ...). |
DNS_SERVER_URL |
The self-hosted path: the deployment's own bind node holds the zone. |
The authoritative-DNS API that serves the group's zone, with scheme, host and port; it also selects the external path. |
DNS_TSIG_SECRET_FILE |
The publisher reads the key out of the deployment's own KV, which is the ordering a cold walk needs. | Path on the deployer to the RFC2136 TSIG secret that authenticates a publish to the deployment's own named. |
ENVIRONMENTS |
Derived from the roster, with a HOSTING_CONFIG .environments section merged on top. |
JSON escape hatch that replaces the roster-derived environments set; a consumer override belongs on the extraModules rail instead. |
HOSTING_CONFIG |
No curation, so the operator form offers every leaf and no effect default is fixed. | Path to the file curating the operator deployment as data, in an .environments section and an .effect-defaults section (core/lib/hosting.nix). |
HOSTING_ENV_CONFIG |
No override: an in-tree run passes the same module through render's extraModules seam instead. |
Path to a .nix, .toml or .json file that render re-expresses as the environments module a hosting provider hooks its existing resources into. |
INTERNAL_HOSTS |
Derived from the group's roster, in the same way. | JSON map of app name to the internal FQDN the app answers at. |
OPENBAO_ADDR |
The deployer reads nothing back from KV, and an effect skips the records that would have come from it. | The deployment's own OpenBao, with scheme, host and port. |
OPENBAO_CACERT_FILE |
The option default. | Path on the deployer to the CA certificate that validates that OpenBao. |
OPENBAO_KV_MOUNT |
The option default. | The KV mount the nodes' vars-openbao writes under. |
OPENBAO_KV_PREFIX |
The option default. | The path prefix inside that mount. |
OPENBAO_TOKEN_FILE |
The option default. | Path on the deployer to the OpenBao token, read at run time so no token value reaches the store. |
OPERATOR_MODULE_SOURCE |
No separate pin, which is the common case. | A fetchTree-compatible JSON pin of a separately-pinned operator source, for the deploying-vs-deployed boundary. |
PUBLISHED_HOSTS |
Derived from the group's roster, scoped by the namespace where the group states fqdnFor. |
JSON map of app name to the public FQDN the app answers at. |
SELF_MODULE_SOURCE |
The source floats, which is acceptable for an unreproducible local build. | A fetchTree-compatible JSON pin of the repository's own revision, which freezes a deployment submitted with no module_source to it. |
SSH_PRIVATE_KEY_FILE |
No key file, so the deploy uses the deployer's own ssh configuration. |
Path on the deployer to the private key the deploy reaches the nodes with. |
VERSION_LAYERS |
provider. |
The newest-of-two decision for the contested layers (core/resources, core/effects), resolved in api/ Python and threaded in as JSON. |
Read by some deployment methods
| Variable | ssh |
tf |
tf-incus |
tf-incus-operator |
|---|---|---|---|---|
BOOTSTRAP |
-- | yes | yes | yes |
INCUS_HOST_SSH_KEY_FILE |
-- | -- | yes | yes |
INCUS_HOST_SSH_OPTS |
-- | -- | yes | yes |
INCUS_HOST_SSH_USER |
-- | -- | yes | yes |
INCUS_NIX_SIGNING_KEY_FILE |
-- | -- | yes | yes |
INCUS_SHARED_STORE |
-- | -- | yes | yes |
NETBOX_API_TOKEN_FILE |
-- | -- | yes | yes |
NETBOX_CLUSTER_NAME |
-- | -- | yes | yes |
NETBOX_CUSTOM_FIELDS |
-- | -- | yes | yes |
NETBOX_PREFIX_SELECTOR |
-- | -- | yes | yes |
NETBOX_RANGE_SELECTOR |
-- | -- | yes | yes |
NETBOX_SERVER_URL |
-- | -- | yes | yes |
NETBOX_TAGS |
-- | -- | yes | yes |
NETBOX_TENANT |
-- | -- | yes | yes |
OPENPROVIDER_BASE_URL |
-- | -- | yes | yes |
OPENPROVIDER_PASSWORD |
-- | -- | -- | yes |
OPENPROVIDER_PASSWORD_FILE |
-- | -- | yes | -- |
OPENPROVIDER_USERNAME |
-- | -- | -- | yes |
OPENPROVIDER_USERNAME_FILE |
-- | -- | yes | -- |
OPERATOR_DNS_API_TOKEN_FILE |
yes | yes | yes | -- |
OPERATOR_DNS_PROVIDER |
yes | yes | yes | -- |
OPERATOR_DNS_SERVER_URL |
yes | yes | yes | -- |
OPERATOR_REGISTRAR_MAX_COST |
-- | -- | yes | -- |
OPERATOR_REGISTRAR_OWNER_HANDLE |
-- | -- | yes | -- |
PUBLIC_UPLINK |
-- | -- | yes | yes |
PUBLIC_UPLINK_GATEWAY |
yes | -- | yes | yes |
PUBLIC_UPLINK_GATEWAY6 |
-- | -- | yes | yes |
PUBLIC_UPLINK_HOST_ADDRESS |
yes | -- | yes | -- |
PUBLIC_UPLINK_PARENT |
yes | -- | yes | yes |
TF_HTTP_ADDRESS |
-- | yes | yes | yes |
TF_VAR_namespace |
-- | -- | -- | yes |
What each of those variables is for, and what applies when it is not set:
| Variable | Default | Description |
|---|---|---|
BOOTSTRAP |
The apply goes straight to the stated backend. | 1 selects the local-then-migrate state path in tf/common/bootstrap-apply.sh. |
INCUS_HOST_SSH_KEY_FILE |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. No key file reads as no way into the store. |
Path on the deployer to the private half of that identity, which also tells the operator lane it has a way into the store. |
INCUS_HOST_SSH_OPTS |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. core/effects/incus/run.sh applies its own defaults. |
Space-separated ssh options for that hop, such as a ProxyJump, a ConnectTimeout or a pinned host key. |
INCUS_HOST_SSH_USER |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. A provider deploying its own hypervisor reaches it as root, the identity it deployed it with. |
The user this deployer reaches the Incus host's filesystem as, which is what a shared-store node needs. |
INCUS_NIX_SIGNING_KEY_FILE |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. |
Path on the deployer to the key that signs the closures it copies into the Incus host's store. |
INCUS_SHARED_STORE |
Derived from whether INCUS_HOST_SSH_KEY_FILE names a way into the host's store. |
0 forces every container onto the image path; any other non-empty value forces the shared store. |
NETBOX_API_TOKEN_FILE |
Resolves the token from OpenBao KV; TF_VAR_netbox_api_token wins over both. |
Path on the deployer to the NetBox API token, read at apply time so the token never reaches the store. |
NETBOX_CLUSTER_NAME |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. |
The NetBox cluster that holds this deployment's virtual machines, which is per-deployment: NetBox keys a virtual machine's uniqueness on cluster, tenant and name together. |
NETBOX_CUSTOM_FIELDS |
No custom fields. | JSON custom fields keyed by object kind then field name, for an instance that refuses a create without them; a literal $node becomes the node's name. |
NETBOX_PREFIX_SELECTOR |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. |
Which NetBox prefixes to allocate addresses from, as <kind>:<value> -- tag:<slug>, id:<n>[,<n>...] or cidr:<a.b.c.d/n>. |
NETBOX_RANGE_SELECTOR |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. |
Which NetBox IP ranges to allocate from, in the same <kind>:<value> shape. |
NETBOX_SERVER_URL |
Discovers the self-hosted node's URL from published TF state, which exists from the second apply onward. | The NetBox API, with scheme, host and port. |
NETBOX_TAGS |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. [] stays distinct from unset. |
JSON list of the tags the deploy puts on the objects it creates. |
NETBOX_TENANT |
The option default, or a HOSTING_CONFIG effect-defaults leaf, which core/render/env.nix merges per leaf. |
The NetBox tenant that owns this deployment's objects, which separates two deployments sharing one cluster. |
OPENPROVIDER_BASE_URL |
The production API. | The Openprovider API, with scheme, host and port. |
OPENPROVIDER_PASSWORD |
The operator deploy registers no domain. | The registrar account's password, taken from the environment by the same provider. |
OPENPROVIDER_PASSWORD_FILE |
The option default. | Path on the deployer to the account's password, staged by cd-env.sh. |
OPENPROVIDER_USERNAME |
The operator deploy registers no domain. | The registrar account's user name, which the openprovider provider takes from the environment (operator/registrar.tf). |
OPENPROVIDER_USERNAME_FILE |
The option default. | Path on the deployer to the account's user name, staged by cd-env.sh. |
OPERATOR_DNS_API_TOKEN_FILE |
The option default. | Path on the deployer to that service's API token, which the provider's deploy publishes to KV for the api node to forward. |
OPERATOR_DNS_PROVIDER |
The option default. | The octoDNS provider that reaches that service. |
OPERATOR_DNS_SERVER_URL |
The curation follows the provider's own dns result. |
The DNS API that operator deploys publish their app names to, when that is not the provider's own service. |
OPERATOR_REGISTRAR_MAX_COST |
Operator deploys register no domain. | The switch for operator domain registration, and the bound in EUR cents on any one registration. |
OPERATOR_REGISTRAR_OWNER_HANDLE |
The option default. | The registrar account contact that a registration names as the owner. |
PUBLIC_UPLINK |
nat: an alias on a NAT-only bridge, delivered nowhere. |
How a public address reaches a container: nat, bridged (the segment is on PUBLIC_UPLINK_PARENT) or routed (the prefix is routed to the Incus host). |
PUBLIC_UPLINK_GATEWAY |
The option default. | The IPv4 first hop for addresses on the public segment. |
PUBLIC_UPLINK_GATEWAY6 |
The option default. | The IPv6 first hop for addresses on the public segment. |
PUBLIC_UPLINK_HOST_ADDRESS |
The bridge stays addressless, the shape the test suite and CI get. | The address the bridging host answers on, as a CIDR whose prefix length tells the kernel which neighbours are on-link. |
PUBLIC_UPLINK_PARENT |
The option default. | The host interface that carries the public segment. |
TF_HTTP_ADDRESS |
http://localhost:8080/state/project1/example, unpinned: the migrate derives the reachable incus-bridge lease. |
The HTTP backend that holds the deployment's OpenTofu state, with scheme, host and port. |
TF_VAR_namespace |
Un-namespaced, which is what the hosting provider's own graph and grants use. | The deployment id an operator apply is scoped with, which names its instances, buckets and KV paths. |
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 or takes its input at run time, which is outside what this page describes: these are the variables each attribute's evaluation reads.
| Effect | Variables |
|---|---|
octodns-zone |
the tf-incus set |
tf-incus-image |
TF_INCUS_IMAGE_ALIAS, TF_INCUS_IMAGE_NODE |
dev-tf-incus-bootstrap |
none |
dev-tf-incus-image |
none |
netbox-seed |
NETBOX_API_TOKEN_FILE, NETBOX_CLUSTER_NAME, NETBOX_CLUSTER_TYPE_NAME, NETBOX_SEED_STATE, NETBOX_SERVER_URL, NETBOX_TAGS, NETBOX_TENANT |
What each of those variables is for, and what applies when it is not set:
| Variable | Default | Description |
|---|---|---|
NETBOX_API_TOKEN_FILE |
The effect's own default (core/effects/tf/netbox/seed/effect.nix). |
The file holding the API token the seed authenticates with. |
NETBOX_CLUSTER_NAME |
The effect's own default (core/effects/tf/netbox/seed/effect.nix). |
The cluster the deploy files its virtual machines under. |
NETBOX_CLUSTER_TYPE_NAME |
The effect's own default (core/effects/tf/netbox/seed/effect.nix). |
The type of the cluster the seed creates. |
NETBOX_SEED_STATE |
A keyed local file. | Names the HTTP backend the seed keeps its state in -- not TF_HTTP_ADDRESS, which is the deploy's own state key. |
NETBOX_SERVER_URL |
None: the seed still evaluates and tofu fails on the empty URL, rather than contacting some default host. |
The NetBox instance the seed creates its objects in. The one required coordinate. |
NETBOX_TAGS |
The effect's own default (core/effects/tf/netbox/seed/effect.nix). |
The attribution tags the seed creates, as a JSON array. JSON rather than a separated list, because the empty list has to be expressible: an instance whose token may not create tags needs NETBOX_TAGS='[]', distinct from an unset variable. |
NETBOX_TENANT |
The effect's own default (core/effects/tf/netbox/seed/effect.nix). |
The tenant that scopes the deploy's virtual machines within the cluster. |
REGISTRAR |
The whole registrar surface is absent -- a deployment whose apex somebody else registered has no such effect to offer. | Names the registrar the applies act on. |
REGISTRAR_DNSKEY |
No DNSKEY, for the reason REGISTRAR_DS has none. |
The same key as REGISTRAR_DS, in the form a registry takes when it derives the DS itself, which INWX and Openprovider both do. |
REGISTRAR_DS |
No DS, which keeps the publish behind the mint: a DS naming a key nobody holds is the whole domain SERVFAIL. |
The apex DS, read off the node that holds the key (/var/lib/named/<domain>.ds, written by named-apex-ds). |
REGISTRAR_MAX_COST |
The registration is off the surface and the rest stays. | The spending bound, in US cents. An apply that spends money is asked for by stating the ceiling it refuses itself above; the records under an already-registered domain cost nothing. |
REGISTRAR_OWNER_HANDLE |
No owner is stated. | The contact a registration is held by, as a handle made once in the registrar's account. A handle rather than the person: an owner held as data would put a name, an address and a telephone number into the module and into the state file. |
REGISTRAR_STATE |
The whole surface is absent, as for REGISTRAR itself, rather than falling back to a local file. There is no local key per leaf -- every generated module keys as generated-module -- so a fallback would put all four applies in one state file. |
Names the HTTP backend these applies keep their state in, as NETBOX_SEED_STATE does for the seed -- not TF_HTTP_ADDRESS, which is the deploy's own state key. Each leaf derives its own key from it, so the registration and the records under it are separate applies (setups/hosts-common.nix). |
TF_INCUS_IMAGE_ALIAS |
The effect's own default name. | The alias the built image is filed under. |
TF_INCUS_IMAGE_NODE |
The group's first node. | Which node to build the image from. |
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.
| Variable | Default | Description |
|---|---|---|
ADMIN_EMAIL |
The option default. | The address a deployment states as its administrative contact. |
BIND2_IPV4 |
No second nameserver, so the fleet keeps one. | The IPv4 address of a second nameserver node (ns2); a stated address is what makes the group stand that node up. |
BIND2_IPV6 |
The second nameserver answers on IPv4 alone. | The IPv6 address of the second nameserver node. |
BIND_IPV4 |
The address the group states (core/setups/groups/hosting-provider.nix). |
The IPv4 address of the first nameserver node (ns1), which NetBox allocates and the zone publishes. |
BIND_IPV6 |
The address the group states. | The IPv6 address of the first nameserver node (ns1). |
DEPLOYMENT |
The baked default-configuration stands, which is the hosting provider's own deploy. |
The JSON deployment the panel submits, which merges over the baked default-configuration at apply time to give the applications, the domain and the contact address. |
DNS_APEX_NAMESERVERS |
The group's own nameserver nodes, so the zone delegates to ns1.<domain>. and to ns2.<domain>. where that node stands up. |
Comma-separated FQDNs the self-held zone publishes as its apex NS set, and an Openprovider registration hands its delegation to. |
DNS_DOMAIN |
No zone, and with no zone there is nothing to publish. | The zone the deployment publishes its names in. |
DNS_SECONDARIES |
No outside secondary, so the zone grants no transfer key and notifies the group's own nameservers alone. | Comma-separated <tsig key name>=<address>[+<address>] entries for the outside secondaries that transfer the self-held zone. |
DNS_SECONDARIES_BY_ADDRESS |
Each secondary transfers with its key. | The subset of the DNS_SECONDARIES key names that transfers by address, for an incumbent that cannot hold a TSIG key. |
DNS_SIGN_APEX |
The apex is served unsigned, and its DS waits for the registrar hand-off. |
Set to 1 to sign the self-held apex with DNSSEC; the key is minted as soon as the apex is ours, whatever this states. |
HOSTING_ENV_CONFIG |
No override: an in-tree run passes the same module through render's extraModules seam instead. |
Path to a .nix, .toml or .json file that render re-expresses as the environments module a hosting provider hooks its existing resources into. |
OPERATOR_MODULE_SOURCE |
No separate pin, which is the common case. | A fetchTree-compatible JSON pin of a separately-pinned operator source, for the deploying-vs-deployed boundary. |
SELF_MODULE_SOURCE |
The source floats, which is acceptable for an unreproducible local build. | A fetchTree-compatible JSON pin of the repository's own revision, which freezes a deployment submitted with no module_source to it. |
VERSION_LAYERS |
provider. |
The newest-of-two decision for the contested layers (core/resources, core/effects), resolved in api/ Python and threaded in as JSON. |
How many attributes each family contributes
| Family | Shape | Attributes |
|---|---|---|
| Deployment runs | <group>-<deployment-method>-<machine> |
148 |
| Deployment verbs | <group>-<deployment-method>-<machine>-<verb> |
1221 |
| Standalone effects | <group>-<effect>[-<verb>] |
41 |
| Hand-bound standalone effects | <name>[-<verb>] |
25 |
| Other packages | (no pattern; listed below) | 9 |
| Total | packages |
1444 |
Other packages
- api-deployments: JSON list of the deployment attributes (
<group>-<effect>-<machine>) this source exposes, for api/'s detect-at-submit guard. - api-renames: The operator form's structured option-rename table (
{ from; to; }entries), for migrating a stored configuration across renames. - api-schema: The operator form's JSON schema as api/ validates submissions against it:
frontend-configuration-schemawith this build'sPIN_EFFECTcollapse andHOSTING_CONFIGleaf prune applied. - core-docs: Generate static site docs of nix options
- frontend-configuration-schema: The front-end configuration JSON schema (the operator form the panel/api render and validate against).
- inwx-provider-schema: The pinned INWX provider's resource schemas, filtered to the types the
tf-inwx-*effects wrap. - netbox-provider-schema: The pinned NetBox provider's resource schemas, filtered to the types the
tf-netbox-*effects wrap. - 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.
Checks
- 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:
credentialscontract 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-filesecrets-hardcoded-secret: NixOS test:
fileSecretscontract with hardcoded-secret provider. - contracts-generatefiles-vars: NixOS test:
generateFilescontract withvarsprovider. - contracts-generatefiles-vars-independent: NixOS test:
generateFilesinstance growing a file withindependent = true. - contracts-generatefiles-vars-openbao: NixOS test:
generateFilescontract withvars-openbaoprovider. - contracts-ldap-lldap: NixOS test of the lldap-backed
ldapcontract provider. - contracts-ldap-openldap: NixOS test:
ldapcontract with the openldap reference provider. - contracts-oidc-dex: NixOS test:
oidccontract with the dex reference provider. - contracts-postgresql: NixOS test of the postgres-backed
postgresqlcontract provider. - contracts-postgresql-rotation
- contracts-redis-valkey:
rediscontract behavior test with the referencevalkeyprovider (ACL-isolated namespaces). - contracts-s3-minio: NixOS test:
s3contract with the minio reference provider. - contracts-secrets-openbao: NixOS test: the
secrets-openbaoenvSecrets/fileSecretsproviders. - contracts-smtp-maddy:
smtpcontract behavior test for the maddy-backed relay provider. - contracts-smtp-opensmtpd: NixOS test:
smtpcontract 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.
- 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.
- 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-nixos-hosts: Sanity-check direct NixOS deployment of a trivial host.
- deployment-remote-path-fallback: Unit-test the
PATHfallback a remote command carries, which is what reaches a node whose ownPATHresolves nothing. - deployment-ssh-hosts: Sanity-check SSH-based deployment of a trivial host.
- 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-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 on a shared garage node and publish the pair into OpenBao KV over the
:8200TLS listener. - deployment-tf-self-state-reachable: Unit-test the netbox self-state reachability probe (fresh-provider DHCP fallthrough, #833/#882).
- deployment-unit-parsers: Unit-test the readers of the shared deploy body that turn
systemctloutput 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=0keeps the name and drops the exit code; a verdict-only pass judges the node without deploying to it; and the sweep revives a unit parked instart-limit-hitonce what it waited for has arrived. - 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 declaredDEPLOY_LOOP_BUDGETdelays 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, and a unit cycled by something other than systemd is named with no restart to show for it. - 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=resourceswith nothing said about spawning keeps its ordinary attribution, and a verdict-only pass retries the fault and reports the recovery. - integrations-apex-key-mint: Runs the apex signing key's
generateFilesgenerator 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 theKSK:/ZSK:rolesdnssec-policyadopts 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-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-deployerrole 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-typedbound_claimssent as a string, or abound_subjecta 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: apull_requestrun, 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
failedrather than holdingswitch-to-configuration's lock open forever, whilespire-agentis 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
destroyof 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-dns-key-render: NixOS test that a
fediversity.dns-masterTSIG key render fails rather than emittingsecret "";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, leavingnamedreloaded onto an empty key with the unit green andcmpmatching 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-incus-shared-store: NixOS test that an imageless incus container boots off the host's own
/nix/store, bind-mounted read-only the waynixos-containerdoes 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-publishproves 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-migrate-after-failed-apply: A cold
bootstrap-apply.shwhose 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_SSHwhen it is waiting on a host-internal bridge lease, and stays quiet when it is not. - integrations-octodns-bind: NixOS test of the OctoDNS bind provider into our own
namedover 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, andverifyfinding 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-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_WITHDRAWALSleaves 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-challengedelegation 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
ownershipover zones that already hold records nobody here wrote -- the unowned sibling and apexNSsurvive, 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.sslprovider. - integrations-plan-does-not-apply: A
planagainst an effect that declares no HTTP backend stays a plan, even withTF_HTTP_ADDRESSset. - 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.
- integrations-publish-records-named: NixOS test of the operator graph's record publisher over its RFC2136 lane, against the provider's own
namedprimary 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-published-names: The apply re-derives which nodes to stand up, each node's
published_names, and the effect's variables that follow the domain, from the submitted configuration, replacing what the setup eval baked. - integrations-reclaim-own-lock: A steady-state
bootstrap-apply.shwithTF_RECLAIM_OWN_LOCK=1releases 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 execmessage covers. - 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-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-lost-state: A steady-state
bootstrap-apply.shrefuses to apply when the backend holds no state for a key this deployer has a fleet's worth of local state for. - nix-unit-components-incus-store-identity: Unit test holding the store-serve identity constants the windmill worker's
_jobenv.pyrestates toincus-store-identity.nix, the file its nix-side consumers read. - 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 api node's
netboxanddnsrequests resolved; a self-hostednamedopens 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-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
dischargePropertiescopy 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-effects-common-lib: Unit tests for the common deployment-effect helpers.
- 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 = destroyprovisioner 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. - nix-unit-effects-tf-provider-pins: Guard test asserting the OpenTofu provider versions written into
tf/still match the npins pins (derivedrev/constraint, and the one hand-maintained HCL literal). - nix-unit-effects-tf-registrar-render: Guard test forcing each registrar effect's generated OpenTofu module to evaluate, which no other check does: a registrar apply spends money at a real registry, so these effects reach no integration test.
- nix-unit-effects-write-config: Guard test asserting the deploy-time
configuration.nixkeeps its store path across runs differing only in the deployer's credential-staging directory. - 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
getEnvkeys are declared in itsenvKeys(thecore.lib.deployEnvKeysDRY invariant). - nix-unit-lib-data-model: Unit tests for the data model (
core/lib/data-model.nix). - 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, 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, and a selected name the structure does not have throwing.
- nix-unit-lib-renames-for-source: Unit tests for structured option-rename extraction and schema pruning.
- 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 api 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-resources-firewall: Unit tests for the firewall resource: dual-stack source classification, which ports are published rather than merely served, the fail-closed guards, and the component-request / environment-policy split.
- 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
varsprovider wiring andfileSecretsbridge. - nix-unit-resources-otel: Unit tests for the OpenTelemetry resource module.
- 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
fileSecretsrouting. - 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, 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
namedmints 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
bindnode for the unit placing the apex signing key: scoped to a signed apex we hold, fail-closed againstnamedbecause 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
403on a live deploy. - nix-unit-setups-delegated-zones: Unit tests on the realised
bindnode 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 a panel-initiated deploy reads back: which deployer publishes (the provider's own, holding a token) and which does not (an operator graph, a cold walk), and that the deployer policy is widened to exactly the three published keys.
- nix-unit-setups-dns-routing: Unit tests for the DNS self-hosted-vs-external gate: roster filtering, contract provider routing, the
_acme-challengezones delegated inward to the deployment's ownnamedfor 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, and the rest of the central KV stays read-only from the UI.
- 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.
- 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, and the mail-authentication records -- including the SPF landing at a CNAME's target rather than the alias.
- 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.targetdoes 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, no TPM is left as the host's hardware-RNG source, and the shared-store login identity lingers. - 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.
- 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.
- nix-unit-setups-ldap-grant: Unit tests on the realised hosting-provider
openbaonode 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-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, and that the pair renders where the import reads it.
- 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
bindanyway. - nix-unit-setups-operator-config: Unit tests on the realised operator application nodes: each runs the spire-agent it logs in to OpenBao with, and carries the
get_tpm_pubhashthe operator deploy execs to allow-list its TPM. - 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.
- nix-unit-setups-pixelfed-trust: Unit tests for the pixelfed node's PKI trust seam: php-fpm's
clear_envdrops the manager'sSSL_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-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
DSreads 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-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-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-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
sshdeployment method resolves: the setup's own defaults, the operator map's defaults over them, and the per-node entry over both -- field by field, withsshOptsoverriding rather than appending and the operator-facingkeyFilerenamed to the submodule'skey-file. - 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-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
sslrequest at all. - 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
defaultline at every start, and saves theapppassword it repairs. - 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, and reads each address back from exactly the KV path that namespace's valkey node publishes it to.
- 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-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-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.
- 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
namedover RFC2136 under a TSIG key) -- including the apex delegation, which a self-held zone must state or plan for deletion. - 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.
- resources-secrets-agenix:
fileSecretscontract conformance test for the agenix provider. - test-forgejo-anubis-allow: NixOS test that the forge's 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 -- the consumers of those paths run no JavaScript, so a proof-of-work challenge can only break them. - 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-bindaccount in the lldap directory (mint, real bind, rotation survival). - test-lldap-admin-release: NixOS test that a changed
adminUserreleases 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, and a live authenticated send under its identity.
- 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 a deliberately failed backup unit drives its rule to
Alerting. - 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, and assert each vendored schema still matches its provider.
- treefmt: Check that the project tree is formatted
Repo-root checks
- treefmt: Check that the project tree is formatted