Skip to main content
One engine, one control plane, and one native runtime secret path.

​
Decision

  • OpenTofu is the only IaC engine used by active repos.
  • Terrakube executes plans and applies, stores state versions, and locks one run per workspace.
  • OpenBao supplies dynamic provider credentials and ephemeral KV values through native integrations.
  • Homelab mirrors serve OpenTofu releases, providers, modules, and images so normal control-plane operation needs no public internet route.
Repos carry a cloud {} block and use plain tofu commands. Static checks run locally and in CI with tofu init -backend=false. Credentialed plans and applies run on the Terrakube executor.

​
Why the wrapper was removed

The former wrapper generated backends and providers, merged input files, decrypted secrets, and ran post-apply hooks. Native components now own each job: Removing the wrapper also removes generated files, hidden input precedence, a second command vocabulary, and shell-level credential injection.

​
Normal workflow

The last two commands submit remote work. The workspace’s complete plan stays inside the homelab control plane and must be reviewed before apply.

​
Secrets and offline operation

Terrakube service secrets use native paths under the platform’s OpenBao namespace. Each workspace receives a least-privilege OpenBao identity. Secret values are never copied into a Terrakube workspace variable, a CI secret, or a developer keychain for normal runs. An offline-ready platform mirrors every artifact needed to start the stack and execute a pinned workspace. External providers such as AWS or GitHub still need their target API when a plan manages those services, but the Terrakube control plane itself does not need public package or image downloads.

​
State migration rule

Move existing state once with a reviewed tofu init -migrate-state procedure. Preserve a pre-migration snapshot and compare resource addresses before and after. Never create a second empty workspace and apply into it.