Terraform State of Mind

Terraform State of Mind
Photo by David von Diemar / Unsplash

ClickOps Anonymous, Day 12

So, I started this blog recently to document my adventures in self-hosting and homelabbing—and this week’s entry takes us straight into the world of Terraform.

That’s right, I’ve stepped away from manually clicking around in Proxmox and started describing my infrastructure in code. It’s all part of my effort to bring more consistency, automation, and let’s be honest, fewer “wait...how did I set that up again?” moments to my homelab.

Why Terraform?

Terraform lets you define your infrastructure using configuration files instead of manually setting things up. Want to create a new VM? Write a few lines of code, run a command, and boom—it’s live. Want five? Change a variable. Want to tear everything down and start fresh? One command. Terraform makes it possible.

For someone like me, who’s always tweaking and rebuilding their homelab, it’s a dream come true.

Terraform + Proxmox = 💻💥💾

Now, Proxmox isn’t officially supported by HashiCorp’s Terraform providers, but there’s a solid community-maintained one that works great with a little elbow grease. I’m now using Terraform to spin up VMs from templates on my Proxmox cluster, automate settings like CPU, RAM, disk, and even cloud-init configs. It’s basically magic.

Early Lessons and Light Bumps

Let’s just say there is a learning curve. A few things I’ve run into so far:

  • Terraform State Files: These files track what’s deployed, and Terraform uses them to figure out what needs changing. They’re important. As in, “don’t lose this or you’re rebuilding things manually again” important.
  • Proxmox Provider Quirks: Not everything is as plug-and-play as the AWS or Azure providers. Expect some trial and error.
  • Mental Shift: Going from "make changes live in the GUI" to "change it in code and reapply" takes a bit of unlearning—but it’s worth it.

My Setup

Since I’m not using S3 or any commercial cloud backend, I’ve set up my own self-hosted cloud on my HL15. I keep my Terraform state files backed up there with versioning and off-site sync for peace of mind.

Why? Because this is a homelab—and we build our own clouds here.

Looking Ahead: Kubernetes as Code

Once my VM deployments are fully automated, the next step is a big one: reworking my Kubernetes cluster with Infrastructure as Code.

Right now, my cluster setup is… functional. But not exactly repeatable. I want to get to a point where I can wipe the whole thing and rebuild it—networking, control plane, worker nodes, everything—just by running a few commands. Terraform will handle the infrastructure, and I’m eyeing GitOps tools like Flux or ArgoCD for cluster state management.

Terraform Tips (From a Beginner Still Figuring It Out)

  • Always run terraform plan before you apply changes. Surprises are for birthdays, not infrastructure.
  • Back up your state file—seriously, even if you’re just testing. It’s the one source of truth Terraform relies on.
  • Modularize when it gets messy—once you’re writing more than a few resources, break things into chunks. Future you will be grateful.
  • Use version control for your .tf files. A git repo is the best changelog you’ll ever have.

What I’ve Learned So Far

  • Infrastructure as Code brings order to chaos—especially in a constantly evolving homelab.
  • Self-hosting is flexible but not without quirks—and that’s part of the fun.
  • Automating your stack doesn’t mean losing control—it means gaining it in a scalable, repeatable way.

Terraform has already made a big difference in how I manage my homelab. Instead of repeating manual steps every time I want to tweak something, I can just update my code, run a command, and let the system handle the rest.

There’s still a lot to learn—and I’ll keep documenting it here as I go. Stay tuned for the Kubernetes chapter. Until then, may your applies be safe, your drifts minimal, and your homelab as overengineered as your heart desires.