Infra

This tree contains infrastructure as code. Tracked source follows the repository’s public-source policy. Infrastructure facts are not confidential merely because they are operational, generated, or live. Reports may include them unless they contain credentials, other secrets, or personal information. Inspect raw state, plans, inventories, and decrypted configuration because those artifacts can contain prohibited content; do not track the artifacts themselves.

Each infrastructure project owns its specifications and maintained changes in <project>/openspec/. Use the pinned OpenSpec workflow with that project selected. These specifications describe checked-in definitions; they do not establish deployed state or authorize infrastructure operations.

Requirements

• Bazel targets MUST use repository-internal visibility.
• Infrastructure definitions MUST NOT be published as production artifacts.
• Infrastructure targets MUST NOT be dependencies of production build targets.
• Public checked-in documentation MAY be included in the repository documentation site, including non-secret, non-personal operational facts.

New project

The commands below are state-changing operator examples. An agent must use bazel_agent, apply the repository Terraform and secret-handling procedures, and receive explicit authority for the exact operation and environment before running an equivalent command.

• Create an approle: example
• Add it to approles: example
• Run apply:

  bazel_agent bazel run //infra/vault/tf:tf.apply
  

• Update Yandex Cloud folders:

  bazel_agent bazel run //infra/yandex_cloud/org1/tf:tf.apply
  

• Update Proxmox resource pools:

  bazel_agent bazel run //infra/pve/tf:tf.apply
  

• Update Xen Orchestra AppRole resource sets:

  bazel_agent bazel run //infra/xcp_ng/tf:tf.apply
  

• Set up al config: example
• Configure the component’s Terraform state through the existing Vault HTTP backend flow. The tf_backend plugin creates state and lock KV entries on first use.