At the beginning, most of this setup lived in my head, in shell history, or in blog posts describing what I wanted the platform to become.

That was useful for thinking, but it was not yet operational.

The big shift was moving the Vault work into a dedicated repo:

What Changed

The repo now acts as the operational source of truth for:

  • the offline-root and intermediate PKI workflow,
  • Vault server TLS issuance,
  • admin client certificate issuance,
  • per-app and per-proxy Vault Agent setup,
  • CA-chain distribution,
  • certificate checks and mini audit scans.

That matters because the system is no longer defined by memory or by one successful test on one evening.

It is defined by:

  • stable script entry points,
  • tracked config shape,
  • explicit environment boundaries,
  • and repeatable onboarding steps.

Why A Separate Repo Helped

The older blog posts captured the design:

  • offline root,
  • Vault intermediates,
  • HTTPS + mTLS,
  • one user per component,
  • short-lived credentials,
  • automated agent flows.

The repo forced that design to become concrete.

Once I had to write things down as scripts and config, vague ideas became real questions:

  • Which paths are canonical?
  • Which values belong in config, and which should stay local?
  • Which script names are stable enough to call directly?
  • How do I keep old implementations without breaking the current entry point?
  • How do I avoid leaving secrets or tokens in git?

The Structure That Emerged

The current layout is simple but important:

  • infra/ contains the wrapper scripts I actually call,
  • infra/versions/ contains versioned implementations,
  • infra/config/apps.example.yaml is the tracked template for env and app metadata,
  • infra/config/apps.yaml stays local and untracked,
  • sensitive runtime material stays outside git.

This is a much better shape for long-term operations than calling randomly named historical scripts directly.

The Real Upgrade

The real improvement is not just cleanliness.

It is that the security model and the operating model now line up:

  • the Unix-user split matches the Vault identity split,
  • the PKI hierarchy matches the environment split,
  • the automation matches the certificate lifecycle,
  • and the repo layout matches how I actually work on the system.

That is when a lab starts to feel less like a pile of experiments and more like a platform.