Building a Cost-Effective Kubernetes Lab on Hetzner with Terraform and K3s

I wanted a practical Kubernetes lab environment that felt close to a real cloud setup but without paying managed-cluster pricing for experimentation. I also wanted something more realistic than local-only tools for this specific learning journey.

That led me to a simple setup:

• Use Hetzner Cloud for affordable compute
• Use Terraform to provision infrastructure as code
• Use K3s for a lightweight Kubernetes control plane

The result is a low-cost, repeatable lab that I can rebuild quickly whenever I want to test deployments, GitOps flows, TLS, and platform tooling.

Why I Chose Hetzner Instead of Local Kubernetes

Tools like Kind and Minikube are excellent for many use cases, but I specifically wanted to practice in an environment that includes:

• Remote SSH access and server hardening
• Public networking and DNS considerations
• Real Linux host operations
• Infrastructure lifecycle management with Terraform

Hetzner gave me a strong price-to-performance ratio, which made it ideal for a personal lab that I can run continuously without breaking the budget.

Architecture Overview

At a high level, the setup looks like this:

1. Terraform creates the Hetzner cloud server and related infrastructure.
2. Cloud-init or post-provision scripts prepare the host.
3. K3s is installed on the server.
4. kubectl from my local machine connects to the cluster.
5. Workloads are deployed for learning and testing.

Even this single-node pattern is enough to practice core Kubernetes workflows:

• Namespace and RBAC basics
• Deployments, services, and ingresses
• Secrets management patterns
• Backup and restore drills
• CI/CD and GitOps experiments

As the lab evolved, I also added:

• IP-restricted firewall rules for SSH and Kubernetes API access
• Local Windows kubectl access using a dedicated kubeconfig context
• cert-manager with Let’s Encrypt for TLS certificates
• Argo CD exposed through ingress for remote access
• Argo CD access hardening with Traefik IP whitelist middleware

Terraform for Repeatability

The best part of this setup is repeatability. Instead of manually clicking through a cloud portal, Terraform captures infrastructure as code so the environment can be recreated consistently.

provider "hcloud" {
  token = var.hcloud_token
}

resource "hcloud_server" "k3s_lab" {
  name        = "k3s-lab"
  server_type = "cx22"
  image       = "ubuntu-24.04"
  location    = "fsn1"
  ssh_keys    = [hcloud_ssh_key.main.id]
}

Key benefits I noticed immediately:

• Version control for infrastructure
• Fast rebuilds after experiments
• Clear drift detection
• Less human error

Installing K3s

K3s is a lightweight Kubernetes distribution that is perfect for labs, edge environments, and smaller clusters.

curl -sfL https://get.k3s.io | sh -
sudo kubectl get nodes

Once K3s is running, you can extract kubeconfig, update the server endpoint, and manage the cluster from your local machine just like any other Kubernetes environment.

Local kubectl Workflow from Windows

One useful improvement was making cluster management clean from my local machine:

• Copy kubeconfig from the VM
• Replace localhost endpoint with the VM endpoint
• Rename the context (for example, hetzner-k3s) to avoid collisions
• Merge kubeconfigs so switching contexts is simple

This made day-to-day operations much faster and reduced mistakes when moving between clusters.

Security Approach

I also wanted this lab to follow basic production-style security practices. One of the first controls I added was a firewall policy to limit inbound access to only my public IP address where possible.

This significantly reduces exposure for services like SSH and helps keep the lab locked down while I experiment.

I later tightened this further by using Traefik middleware IP whitelisting for Argo CD access, so cluster tooling is not broadly exposed.

Because home IPs can change, I added a PowerShell helper script to quickly update IP allowlists in both Terraform and Kubernetes manifests. That made security maintenance much easier.

TLS with cert-manager and Let’s Encrypt

I also added certificate automation so services can use HTTPS with managed certificates:

• Installed cert-manager in the cluster
• Created staging and production ClusterIssuers
• Validated certificate requests and challenge flow
• Secured Argo CD ingress with managed TLS certificates

This gave me practical experience with certificate lifecycle management, not just application deployment.

Cost and Practicality

One reason this approach works so well for a learning lab is cost control. With Hetzner, you can keep monthly spend low while still getting a real remote Kubernetes environment. In my case, the total comes to less than £20 per month.

This means you can:

• Keep the lab running for ongoing practice
• Tear down and recreate resources without worrying too much about cost
• Iterate on infrastructure and cluster patterns more frequently

Lessons Learned

A few practical takeaways from this project:

• Start with a simple single-node cluster and expand later.
• Automate early with Terraform so your setup is reproducible.
• Treat your lab like production from day one (security, access control, TLS, backups).
• Document every command and decision while building.

What I Plan to Add Next

My next iteration of this lab includes:

• Experimenting with GitOps tools
• Ingress and TLS with cert-manager, plus experimentation with Gateway API as Ingress NGINX is now retired
• Backup strategy for cluster state
• Multi-node expansion for scheduling and resilience tests

Final Thoughts

Building a Kubernetes lab on Hetzner with Terraform and K3s gave me exactly what I wanted: a cost-effective, realistic environment to sharpen DevOps and platform engineering skills.

I now have a strong foundation set up for a lab environment, which gives me the freedom to continue experimenting with GitOps and related tooling in my own time.

If you are in a similar position, this is a great path to gain hands-on Kubernetes experience without the overhead of a full managed platform.

---

If you are also building a self-hosted cloud lab, focus first on reproducibility and security. A small, well-managed setup will teach you far more than a large but fragile one.