Building infrastructure: The road to Platform Engineering!
Working at Rutgers OSS put me in front of Kubernetes, GitOps, and production deployments more than any personal project had. I wanted that knowledge to live somewhere I fully owned, not just somewhere I'd used it once under someone else's runbook. So I started building the same shape of platform at home, on a production VPS and a homelab machine, with one rule attached to it: it has to stay something one person can actually run.
Two nodes, on purpose
The setup is a VPS named astatide-prod-1 acting as the single k3s control plane, and a homelab machine named sohim joining as a Tailscale worker. sohim carries a NoSchedule taint, so nothing lands on it by accident, only what I've deliberately decided belongs there. An earlier machine, OVHcloud VPS, got retired after I realized using Coolify was cheating and I should learn kubernetes.
Terraform provisions the external resources, Ansible bootstraps the hosts, and Argo CD reconciles everything inside the cluster from Git. I don't try run one-off kubectl commands to change a workload; if it's not in the GitOps repo, it doesn't count as the real state.
Learning better practices
Every decision here is taken as an attempt to learn the right way to do things: hosts bootstrap from code, desired state is versioned, images are immutable, and recovery shouldn't depend on me remembering an undocumented machine at 2am.
The deadline
I gave this a hard stop: September 1, 2026. By then it needs to demonstrate real deployment, networking, observability, secrets handling, backups, and recovery, and after that date it's meant to become job-application evidence instead of an ongoing project I keep expanding because the infrastructure itself is fun to build. Homelabs are good at eating unlimited time for no additional proof. As much as I love infrastructure as the next person I would like to use it and building things running of it. That doesn't go to say that I won't be improving it when the need presents itself.