This is Part 3 of my multi-arch K3s home lab series.
In Part 1, I shared the motivation and hardware setup. In Part 2, I walked through networking, storage, remote access, and how I deployed my apps.
Now it’s time for the fun part: what broke, what I learned, and how I’d do it differently next time.

Multi-Arch K3s Home Lab Series:

Hosting CTFs on My Own Infrastructure

One of the main motivations for this cluster was CTF hosting.

I had started a CTF team, and I noticed:

  • Many other teams had their own CTF platforms.
  • It felt natural to want a platform of our own, instead of relying only on third-party hosting.

I explored options like:

  • AWS / GCP instances.
  • CTFd’s own managed hosting.

They all worked—but they all cost real money over time.

Meanwhile:

  • I had hardware at home sitting idle.
  • I wanted to learn more about infrastructure anyway.

So I decided to:

  • Self-host CTFd on my K3s cluster.

This gave me:

  • Full control over the platform.
  • A perfect excuse to experiment with Kubernetes in a real scenario.
  • The satisfaction of running a CTF environment on my own hardware.

In the future, I’d like to:

  • Spin up per-challenge deployments.
  • Use separate namespaces for different events.
  • Harden the setup with network policies, better observability, and clearer isolation between challenge infrastructure and core services.

What This Home Lab Taught Me

This project taught me much more than just “how to install K3s”.

1. Keeping Multiple Devices in Sync Is Real Work

Managing several devices together is not just about turning them on.

It means:

  • Checking dependencies across nodes.
  • Keeping software updated and consistent.
  • Tracking down faults in both:
    • Hardware (like the Pi’s failing Wi‑Fi).
    • Configuration (YAML, networking, storage, services).

It feels like a tiny version of real production operations:

  • Things drift out of sync.
  • Something that “worked yesterday” suddenly doesn’t.
  • You learn to build small habits around monitoring, documentation, and backups.

2. Home Labbing Is an Amazing Way to Learn Infra

Running a home lab forces you to touch many layers at once:

  • Networking – IPs, DNS, ingress, VPNs, tunnels.
  • Storage – local disks, distributed volumes, performance trade-offs.
  • Infrastructure design – deciding:
    • Where things should run.
    • What should be redundant.
    • What you’re okay with losing if something dies.

Because it’s your own stuff, it’s:

  • Low-stakes enough to experiment.
  • High-motivation because the services are actually useful to you and your friends.

3. Containers + K3s Feel Like a Safety Net

One of the nicest feelings is knowing that:

  • If a container crashes, another one will spin up automatically.
  • If a node reboots, Kubernetes will try to reschedule workloads somewhere appropriate.

This gives a different level of confidence:

  • Services are less likely to disappear quietly.
  • When something breaks, there’s usually a predictable path to fix it.

Even in a small home lab, that safety net makes a difference—especially when you’re hosting something like a CTF where people are depending on uptime.

How I Operate the Cluster Today

Right now, my operations workflow is very CLI-based:

  • kubectl get nodes – quick health check on all nodes.
  • kubectl get pods -A – see what’s running and what’s failing.
  • kubectl logs – dig into issues when something looks off.

I still don’t have a full monitoring stack like:

  • Prometheus + Grafana for metrics.
  • Loki for logs.
  • Uptime Kuma for simple uptime checks.

So far, the cluster has been stable enough that I haven’t been forced to add them—but I know that:

  • As I add more services.
  • As more people use the CTF platform.
  • As I start depending on it more daily.

…those observability tools will become more important.

My plan is to:

  • Add monitoring + logging as a next phase, not an afterthought.
  • Use them to:
    • Catch problems earlier.
    • Visualize how the cluster behaves under load.
    • Understand the impact of changes (new apps, new nodes, upgrades).

What I’d Do Differently Next Time

If I rebuilt this exact setup today, I would change a few things.

1. Bring Proxmox into the Picture

I’d like to:

  • Experiment with Proxmox as a base layer.
  • Use it to manage:
    • VMs.
    • Possibly LXC containers.

That would give me:

  • More flexibility in how I slice resources across workloads.
  • A cleaner separation between:
    • The underlying virtualization layer.
    • The K3s/Kubernetes layer on top.

2. Set Up Backups and Logging from Day One

In my current journey:

  • Observability and backups came closer to the end of the process.

If I started over, I’d:

  • Put backups and logging/metrics into the first phase:
    • Make it easy to trust the cluster long-term.
    • Reduce the chance that I lose important configs or data.
    • Make debugging feel less like guesswork.

3. Design Storage with Future Growth in Mind

I’d also think earlier about:

  • A more robust storage story for when I eventually:
    • Add a more powerful node.
    • Introduce a dedicated NAS or shared storage box.

Right now, Longhorn + the laptop HDD works well enough, but:

  • A more intentional storage design would make it easier to:
    • Scale.
    • Replace nodes.
    • Move data around without fear.

Final Thoughts

The most surprising part of this whole journey was realizing that home labbing is actually fun and not as scary as it looks—especially if you already have a bit of background with computers and hardware.

What started out as:

  • A single overworked Raspberry Pi running Docker and running out of space

Turned into:

  • A multi-arch K3s cluster hosting:
    • My CTF platform.
    • My personal cloud.
    • My media and file sync stack.

All of it powered by:

  • A couple of Raspberry Pis.
  • One old laptop that finally found a purpose.

And the best part: I now have a playground where I can keep learning—about Kubernetes, infrastructure, home lab design, and how all the pieces of a real system fit together.

Want to see the actual cluster files and a “how to replicate this” guide? Check out my k3s_cluster GitHub repo—the README has a full walkthrough! I’ll keep adding architecture diagrams and monitoring dashboards as the project evolves.