AI
The All-Nighter That Started Everything
Niklas Frick sat down one late summer evening in 2023 intending to spend an hour on Docker. He watched Fireship’s “Docker in 100 Seconds” and NetworkChuck’s “You Need to Learn Docker Right Now,” then started building his own Docker images. Docker networking was harder than expected. He found Kubernetes, kept reading, and looked up to find it was 4 a.m. He’d spent nearly a decade building digital products and hadn’t touched infrastructure since his systems engineering apprenticeship. That one night changed that.
Building a Cluster From Scavenged Hardware
Frick had old hardware in his basement and decided to try Kubernetes on it. The cluster: an old workstation PC from his bank apprenticeship, his MacBook Pro, a friend’s MacBook Air, a lab machine that turned out to have only a broken screen (the computer worked fine), and a Raspberry Pi from a university IoT project. He ran Ethernet cables around his apartment, unplugged his Apple TV to free one. His MacBook Pro wouldn’t connect via Wi-Fi, so a friend lent a USB-C docking station to solve it.
Failing Forward: cgroups, Certificates, and Self-Hosting
He chose K3S because it came up first in search results. It worked on most nodes but not the Raspberry Pi. He suspected an ARM vs x86 mismatch. The real problem: cgroups were disabled by default. One line in a config file fixed it. Certificates caused equal trouble. He swapped tokens for certificates, couldn’t join nodes, then discovered K3S generates both when you delete the manual attempts. Self-hosting Outline Wiki then forced him through Longhorn, Helm charts, Postgres, Redis, MinIO, Traefik, cert-manager, Prometheus, Grafana, and Argo CD, in that order.
Home Lab vs Production: Where Skills Transfer and Where They Don’t
The core Kubernetes primitives transfer fine: pods, services, ingress, declarative config, and troubleshooting instincts. Frick estimates the overlap at 60/40, not 80/20. Production adds architecture planning before touching the keyboard, security, multi-tenancy across teams and clients, real blast radius when things break, alerting that people actually respond to, on-call rotations, maintenance windows, and cost awareness beyond an electricity bill. At home you’re a generalist. In production you’re a platform builder, deploying IDP golden paths and developer portals for developers who are your actual users.
Getting Hired as a Platform Engineer: Interview Lessons From a Home Lab
Less than three years ago, Frick didn’t know what a cluster was. The home lab landed him a platform engineering job. In interviews, every Kubernetes question he faced was something he’d actually broken and fixed. His advice: be specific about what you built and why you chose one tool over another, bridge home lab to production scale, own gaps honestly (“I haven’t managed 200 nodes, but here’s what I’d expect”), and show your incident mindset. The biggest gap: at home you’re the only user. In production, developers are consuming the platform you build.
Notable Quotes
I look up and it’s 4:00 a.m. in the morning. Niklas Frick · ▶ 1:48
I wouldn’t even say it’s a 8020. I would think it’s more 6040 Niklas Frick · ▶ 22:50
you can’t really fake something you have broken uh and you fixed it when you have done it Niklas Frick · ▶ 23:44
Key Takeaways
- Enabling memory cgroups with one config line fixed K3S on the Raspberry Pi after hours of wrong debugging.
- Frick estimates 60% of home lab skills transfer; people, processes, and blast radius only appear in production.
- Answering interview questions from lived experience, including what you broke and fixed, beats theoretical knowledge.
About the Speaker(s)
Niklas Frick is a Platform Architect and Engineer at The Platform Engineering Company. He works on cloud-native platforms focused on developer experience and operational reliability. His background spans Systems Engineering (Network Security) and Digital Business Management, which he uses to connect security, engineering, and stakeholder outcomes.