Terraform on Alwaldend

DNS management in a monorepo

Sun, 13 Sep 2026 00:00:00 +0000

Buying a domain is one of the best purchases you can make because they are very cheap and owning one offers you more independence - you can have your email not tied to a specific provider, you can have a site, etc.

After I bought a domain, I needed a way to manage DNS of that domain. Since using the registrar’s UI to do that is not the best idea, I searched for an IaC tool that can do that for me - I settled on DNSControl.

Dns

Mon, 01 Jan 0001 00:00:00 +0000

DNS records live in each owner’s dnsconfig.json. Each owner manages its records through the reusable Terraform DNS module from its designated tf_setup or tf root. This component’s dnsconfig.json owns shared apex and mail records.

Declaration pages

Cloudflare DNS and Mikrotik DNS list the records this repository declares for each destination view, with the owning declaration for every record. They are generated from dnsconfig.json:

bazel_agent bazel run //infra/dns/cmd/dump -- --write

//infra/dns:config_test fails when a checked-in page is out of date, so the pages cannot drift from the declarations they project.

OpenHands

Mon, 01 Jan 0001 00:00:00 +0000

OpenHands deploys as separate components because each owns a distinct responsibility and trust boundary:

Component	Responsibility
Agent Canvas	Browser client for conversations, files, settings, backends, automations
Agent Server	Runs conversations, agents, tools, and workspace operations
Automation Server	Stores schedules and triggers, tracks runs, dispatches conversations

The agent server runs directly on the host with the service account’s permissions. Its workspace is a working directory; operating-system account permissions define its access to the host. Treat the agent server host as trusted infrastructure.

Org1

Mon, 01 Jan 0001 00:00:00 +0000

Pve vm qemu

Mon, 01 Jan 0001 00:00:00 +0000

Shared DNS Terraform

Mon, 01 Jan 0001 00:00:00 +0000

This root consumes the canonical common declarations through the reusable DNS module. It uses the src_infra_dns AppRole and its existing Vault-backed HTTP state. Both Cloudflare and RouterOS credentials are injected through the tf=1 stage label.

Shared apex and mail records were adopted on 2026-09-13. dns_enabled now defaults to true; reconciliation against the adopted state and unchanged declarations must propose no record changes. The adoption evidence records 60 imports and preservation of both complete provider inventories.

Terraform setup

Mon, 01 Jan 0001 00:00:00 +0000

Use this package’s dns.plan, dns.show, and dns.apply targets for the scoped DNS adoption workflow.

These targets select dns=1 and target module.dns with the existing src_infra_forgejo_runner AppRole and setup backend. Plan declared imports, inspect the saved plan with dns.show, and apply only the reviewed file with dns.apply. Ordinary setup commands retain their tf=setup flow.

dns_enabled defaults to true after verified adoption. Keep it enabled to retain existing records; disabling it would propose deletion. The adoption record contains the import, follow-up plan, inventory, and DNS verification evidence. The shared cutover procedure owns prerequisites and recovery. Scoped DNS checks do not establish VM or runner service health.

Tf

Mon, 01 Jan 0001 00:00:00 +0000

This package configures Forgejo organizations, repositories, and access from the shared repository catalog. The catalog owns named administrators, developers, repository identities, and destination names. Its Terraform module supplies the consumer’s repository projection. First-party names remain stable across forges; external fork and mirror names retain their original upstream identity.

Before applying, provision the Vault OIDC authentication source with Ansible and set TF_VAR_vault_oauth_source_id to its verified positive numeric ID. Obtain the ID from forgejo admin auth list on the instance using the service’s config and work path; confirm that the vault source is active and uses OpenID Connect with the expected Vault issuer. Do not assume source IDs survive instance recreation.

Tf

Mon, 01 Jan 0001 00:00:00 +0000

Tf

Mon, 01 Jan 0001 00:00:00 +0000

Use this package’s dns.plan, dns.show, and dns.apply targets for the scoped DNS adoption workflow.

DNS ownership is enabled by default after the verified 2026-09-13 adoption. The adoption evidence records four imports, a no-change follow-up plan, and preserved provider inventories. The DNS wrappers select dns=1 and module.dns within this root and backend; their validation covers DNS and its dependencies. Apply requires a reviewed saved plan, and ordinary ingress service authentication remains separate.

Tf

Mon, 01 Jan 0001 00:00:00 +0000

Use this package’s dns.plan, dns.show, and dns.apply targets for the scoped DNS adoption workflow. They select dns=1 and target module.dns in this root, retaining the src_infra_dc1_pve1 AppRole and existing backend. Use the owner preparation and import procedure for declarative import maps and reviewed saved-plan apply.

dns_enabled defaults to true after the completed adoption. Reconciliation against adopted state and unchanged declarations produces no DNS changes. DNS targeting covers DNS and its dependencies; it does not establish PVE host, API, or service health. Ordinary Terraform commands retain their existing Proxmox authentication.

Tf

Mon, 01 Jan 0001 00:00:00 +0000

Tf

Mon, 01 Jan 0001 00:00:00 +0000

DNS identities

Missing DNS-owner AppRoles compose the existing reusable AppRole module with an owner-specific DNS policy in approles/<name>/. DNS access grants read-only access to the existing provider credentials for the owner’s views. Existing component identities receive these policies through their existing module declarations.

DNS-only group membership adds no policies. These identities retain their own state and named shared-secret access without joining the general infrastructure AppRole group or receiving cloud provisioning, SSH, or PKI permissions.

Tf

Mon, 01 Jan 0001 00:00:00 +0000

Tf

Mon, 01 Jan 0001 00:00:00 +0000

This service stage consumes the project DNS declaration through the shared global DNS module. The DNS workflow uses the project’s AppRole, HTTP state backend, and Cloudflare credentials. This public-only module does not require RouterOS. Ordinary service commands retain their tf=main authentication, including PVE login.

Operational commands require the project AppRole and Vault provider fields in the migration prerequisites. dns_enabled defaults to true after verified adoption. Keep it enabled to retain existing records; disabling it would propose deletion. The zone input remains optional.

Tf

Mon, 01 Jan 0001 00:00:00 +0000

Tf

Mon, 01 Jan 0001 00:00:00 +0000

Tf backend

Mon, 01 Jan 0001 00:00:00 +0000

The plugin tracks each running backend for shutdown, including backends created before a later call fails. Shutdown drains HTTP requests before revoking the backend’s invocation-owned Vault credentials. If the shutdown deadline expires, connections are forcibly closed and the timeout is reported. Normal HTTP server closure is not an error. Vault requests use their incoming request context.

Tf modules

Mon, 01 Jan 0001 00:00:00 +0000

This project contains reusable Terraform modules for Vault configuration, Proxmox virtual machines, backup storage, and related infrastructure. The module collection is still in progress.

Features

Terraform modules

Tf modules

Mon, 01 Jan 0001 00:00:00 +0000

Reusable Terraform modules for Vault configuration, Proxmox virtual machines, backup storage, and related infrastructure. The collection is still in progress.

Status

In progress. The module collection is not yet complete.

Features

Vault configuration modules
Proxmox virtual machine and storage modules
Shared patterns reused by infrastructure stages

Tf setup

Mon, 01 Jan 0001 00:00:00 +0000

This root owns the Flux DNS declaration. DNS ownership defaults to enabled after verified adoption; keep it enabled to retain the managed records.

Use //infra/flux/tf_setup:dns.plan, :dns.show, and :dns.apply for scoped DNS reconciliation. These targets retain the setup backend and src_infra_flux AppRole, select dns=1, and target module.dns. Apply requires a reviewed saved plan. Reconciliation of unchanged declarations must produce no DNS changes.

The ordinary setup targets retain their service authentication behavior. DNS checks do not establish PVE VM or service health; current aggregate source validation remains part of repository delivery.

Tf setup

Mon, 01 Jan 0001 00:00:00 +0000

This package creates a Xen Orchestra VM in the src_infra_dc1_forgejo1 resource set. infra/forgejo/al.lua authenticates with Forgejo’s own Vault AppRole and the packaged XO OIDC login plugin. The plugin supplies a temporary XO token and revokes it on shutdown; no infrastructure administrator token is loaded. The setup HTTP backend remains owned by the same Forgejo config.

Before running this package, bootstrap the AppRole’s XO OIDC user and apply its resource-set membership and existing VM ACL through infra/xcp_ng/tf. Subjects are matched by immutable Vault entity UUID under the configured OIDC issuer, not by login name or AppRole group membership. See XO authentication.

Tf setup

Mon, 01 Jan 0001 00:00:00 +0000

This root owns the Harbor DNS declaration. DNS ownership defaults to enabled after verified adoption; keep it enabled to retain the managed records.

Use //infra/harbor/tf_setup:dns.plan, :dns.show, and :dns.apply for scoped DNS reconciliation. These targets retain the setup backend and src_infra_harbor AppRole, select dns=1, and target module.dns. Apply requires a reviewed saved plan. Reconciliation of unchanged declarations must produce no DNS changes.

The ordinary setup targets retain their service authentication behavior. DNS checks do not establish PVE VM or service health; current aggregate source validation remains part of repository delivery.

Tf setup

Mon, 01 Jan 0001 00:00:00 +0000

This package creates Xen Orchestra VMs in the src_infra_openhands resource set for the three OpenHands components that run off host-bot: Agent Canvas, the agent server, and the automation server. infra/openhands/al.lua authenticates with OpenHands’ own Vault AppRole and the packaged XO OIDC login plugin. The plugin supplies a temporary XO token and revokes it on shutdown; no infrastructure administrator token is loaded. The setup HTTP backend remains owned by the same OpenHands config.

Tf setup

Mon, 01 Jan 0001 00:00:00 +0000

Use this package’s dns.plan, dns.show, and dns.apply targets for the scoped DNS adoption workflow.

DNS ownership is enabled by default after the verified 2026-09-13 adoption. The adoption evidence records 12 imports, a no-change follow-up plan, and preserved provider inventories. The DNS wrappers select dns=1 and module.dns within this setup root and backend; their validation covers DNS and its dependencies. Apply requires a reviewed saved plan, and ordinary service authentication remains separate.

Tf setup

Mon, 01 Jan 0001 00:00:00 +0000

This root owns Vault’s canonical DNS declaration and retains its existing src_infra_dc1_vault AppRole and setup state backend. Use //infra/vault/tf_setup:dns.plan, dns.show, and dns.apply for the scoped DNS workflow. They select dns=1 and module.dns; apply requires a reviewed saved plan. Ordinary setup and service wrappers retain their existing authentication flow.

dns_enabled defaults to true after verified adoption. Keep it enabled to retain existing records; disabling it would propose deletion. The adoption record contains the import and verification evidence. Targeted DNS checks do not establish the health of other resources in the root.

Vault

Mon, 01 Jan 0001 00:00:00 +0000

Deployment

bazel run //infra/vault/tf_setup:tf.apply # Create VMs (requires an active Vault host)
bazel run //infra/vault/ansible # Set up hosts (BM and VMs)
bazel run //infra/vault/tf:tf.apply # Configure vault

Backup

bazel run //infra/vault:backup

Unseal

With a working Vault:

bazel run //infra/vault:unseal

Without a working Vault:

bazel run //infra/vault:unseal_standalone

Fix quorum

bazel run //infra/vault/ansible:fix_quorum

Set up only VMs

bazel run //infra/vault/ansible:ansible.vm # Set up only VMs

Set up only bare metal

bazel run //infra/vault/ansible:ansible.bm # Set up only bare metal

Tf

Plan:

Vault approle

Mon, 01 Jan 0001 00:00:00 +0000

Vault approle

Mon, 01 Jan 0001 00:00:00 +0000

Vault OIDC provider

Mon, 01 Jan 0001 00:00:00 +0000

Vault pki server

Mon, 01 Jan 0001 00:00:00 +0000

Vault transit key

Mon, 01 Jan 0001 00:00:00 +0000

XCP-ng

Mon, 01 Jan 0001 00:00:00 +0000

Terraform in tf manages a Xen Orchestra resource set for every entity in Vault’s approles group, following infra/pve/tf. Resource sets are the XO grouping and delegation mechanism; XCP-ng host pools represent physical clusters and are not created per AppRole.

resource_set_inventory assigns a pool, template, storage repository and network by name to each AppRole. Native provider lookups resolve their IDs and reject ambiguous matches. Forgejo and OpenHands have assignments by default; other sets remain empty. Subjects are the exact synchronized OIDC users selected by Vault issuer and immutable AppRole entity UUID. Bootstrap has synchronized the 18 AppRole users; new AppRoles need their first OIDC login before Terraform can bind their sets. resource_set_cpu_limit defaults to 32 CPUs per set. Creating a set does not allocate CPUs or storage.

Terraform on Alwaldend

DNS management in a monorepo

Dns

Declaration pages

OpenHands

Org1

Links

Pve vm qemu

Shared DNS Terraform

Terraform setup

Tf

Tf

Tf

Tf

Tf

Tf

DNS identities

Tf

Tf

Tf

Tf

Tf backend

Tf modules

Links

Features

Tf modules

Status

Features

Tf setup

Tf setup

Tf setup

Tf setup

Tf setup

Tf setup

Vault

Links

Deployment

Backup

Unseal

Fix quorum

Set up only VMs

Set up only bare metal

Tf

Vault approle

Vault approle

Vault OIDC provider

Vault pki server

Vault transit key

Links

XCP-ng