.envĀ files were fine until migrations, rotations, Kubernetes, OIDC, and app sprawl turned them into a liability.
June
At small scale,Ā .envĀ files felt good enough. Then the environment grew. Apps moved hosts. Docker gave way to k3s. OIDC secrets regenerated. Databases stayed external. App configs needed to be restored, moved, and updated.
.envĀ filesSuddenly, secrets were not just āconfiguration.ā They were scattered operational risk.
Infisical became part of the platform foundation before the k3s app migration. Secrets could be stored centrally and delivered into Kubernetes through the operator instead of recreating the sameĀ .envĀ sprawl in a new format.
A secret copied everywhere is not really a secret.
paste commands here
The lab outgrew static diagrams and scattered dashboards, so HexMap became the live, agentless infrastructure map that shows what exists, where it runs, and what depends on what.
July
The homelab reached the point where a service list was not enough. Infrastructure truth was spread across Proxmox, k3s, DNS, routes, backups, monitoring, storage, manifests, and notes. A dashboard could show what was red. A diagram could show what used to be true. A command could show one slice of reality. None of that showed the whole system.
None of the existing tools showed the whole system or stayed current as the environment changed.
HexMap was built to make the lab visible as a connected environment: hosts, VMs, containers, Kubernetes services, storage, tunnels, monitoring, and dependency paths in one live view. The important part is that it does not require agents or installs on tracked systems. It builds from live infrastructure sources so the map can stay current as the environment changes.
If I have to check six places to understand one service, the map is already broken.
paste commands here
The migration was not just putting apps into pods. It was separating application workloads from the core infrastructure those workloads depend on.
June
The lab moved from scattered Docker hosts toward a k3s-based application platform. Kaveh and Thoma stopped being the center of the app world. Workloads moved into Kubernetes. The platform started to look more intentional.
But the important decision was what did not move into k3s.
DNS stayed in LXCs. PostgreSQL and MariaDB stayed external. Storage stayed on Zhongli. Backups stayed separate. Pangolin/Newt continued handling public access. Infisical handled secrets. Traefik handled internalĀ .fndhomeĀ ingress. That separation kept the cluster from depending on itself for the things it needs to survive.
Kubernetes was not the boss fight. Storage, secrets, databases, ingress, and rollback were the boss fight.
paste commands here
Mid-migration made the new architecture look worse because the overhead arrived before the benefits did.
June
During the bare-metal Docker to Proxmox plus k3s migration, the resource picture looked ugly. Proxmox added overhead. Ceph added overhead. VMs had fixed allocations. The old Docker hosts still existed. Workloads had not fully moved into k3s yet. So for a while, the new platform looked like a regression.
That was the ugly middle. Nahida was carrying old Thoma workload, Furina was carrying old Kaveh workload, and Venti had room that the old architecture was not really using yet.
The architecture only started making sense once the apps moved into k3s, old Docker VMs could be decommissioned, and workloads could spread across the cluster.
The middle of a migration is where everything costs more and nothing feels better yet.
paste commands here