Secrets Are Not Configuration

.env files were fine until migrations, rotations, Kubernetes, OIDC, and app sprawl turned them into a liability.

Original work date

June

The problem

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.

The environment

• App: Infisical, k3s, various apps
• Host:
• Cluster / namespace:
• Version:
• Relevant config: .env files

What failed

Suddenly, secrets were not just “configuration.” They were scattered operational risk.

The fix

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.

Final state

What I learned

A secret copied everywhere is not really a secret.

Useful commands / config

paste commands here

Moving From Docker Hosts to Kubernetes Without Burning the House Down

The migration was not just putting apps into pods. It was separating application workloads from the core infrastructure those workloads depend on.

Original work date

June

The problem

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.

The environment

• App: Kubernetes (k3s), Docker
• Host: Kaveh, Thoma, Navia, Chiori, Shenhe, Ningguang, yelan, kirara, albedo
• Cluster / namespace:
• Version:
• Relevant config:

What failed

But the important decision was what did not move into k3s.

The fix

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.

Final state

What I learned

Kubernetes was not the boss fight. Storage, secrets, databases, ingress, and rollback were the boss fight.

Useful commands / config

paste commands here

Was moving to Proxmox a mistake?

Mid-migration made the new architecture look worse because the overhead arrived before the benefits did.

Original work date

June

The problem

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.

The environment

• App: Proxmox / Ceph / k3s
• Host: Nahida, Furina, Venti
• Cluster / namespace:
• Version:
• Relevant config:

What failed

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 fix

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.

Final state

What I learned

The middle of a migration is where everything costs more and nothing feels better yet.

Useful commands / config

paste commands here