​

Decisions

Two records explain most of the current shape of the homelab. Both live in the Hill90 repository as the authority; this page summarises them.

​

Infra/app separation

Status: implemented. Decided 2026-07-11, implemented 2026-07-26. Hill90 had grown into a combined repository — infrastructure automation alongside an eight-service AI agent application. In June 2026 the production VPS was destroyed and rebuilt on AlmaLinux 10 as a deliberate scope reduction; only the infrastructure and observability stacks were redeployed, and the application stack was left undeployed. The decision made that permanent: Hill90 becomes a homelab domain rather than an application host, and the AI agent application is shelved. Carried out across four pull requests — the eight application services and their compose files, workflows, tests and secrets removed; Keycloak, Postgres and MinIO removed, which also cost the vault its OIDC SSO; documentation rewritten; observability configuration reworked. What remains is three stacks and ten containers. services/dns-manager was kept. It is live infrastructure — the DNS-01 ACME webhook Traefik depends on — not application code. The application is preserved two ways: the archive/app-stack-final tag on the Hill90 repository, and the hill90-app repository, which holds the eight services extracted with full history. Deviations from the original decision, recorded honestly in the source: Hill90 was not archived as the decision anticipated. It stayed live and had the application removed in place, because the infrastructure and observability stacks are still deployed and still wanted. The generic boilerplate repositories the decision envisaged (docker-infra-template, k8s-cluster-template) are a separate, parallel effort. The decision also settled kubeadm over k3s for the future Kubernetes boilerplate — identical API and tooling either way, but kubeadm gives hands-on exposure to etcd, CNI and certificate management, and an etcd backup/restore story that k3s’s SQLite datastore would not provide. → docs/decisions/infra-app-separation.md

​

Vault versus SOPS

Status: open. Raised 2026-07-26. The call is Jon’s. The vault is running but empty; SOPS is what every deploy actually reads. See Secrets for the current state in full. The recorded recommendation is that SOPS remains the operative store and the vault should earn its place by having a concrete consumer, rather than being filled because it exists. Two things have already been done rather than deferred:

• The weekly vault-sync-to-sops schedule is disabled. It had failed every Monday since 2026-06-01 and could not succeed; a weekly alert that always fires carries no information. Manual workflow_dispatch is kept, and the change is reversible in one line.
• The OpenBao image tag is pinned to 2.6.1, so nothing is on fire and no upgrade can arrive by surprise.

What remains is a real constraint: OpenBao’s file storage backend is deprecated, and the vault cannot move past 2.6.x without switching to raft. That migration is well-understood — bao operator migrate works at the storage layer, the existing unseal key stays valid, and nothing about sealing or auto-unseal changes — but for this vault it is the wrong move, because a faithful migration would preserve an empty, permanently unconfigurable vault. If the vault is reinitialized anyway, switching storage in the same pass costs essentially nothing, which is the strongest argument for deciding both questions together. There is no deadline, but there is a decision, and it resurfaces the first time a security fix lands in a version the current pin cannot reach. → docs/decisions/vault-vs-sops.md