skip to content
kleb

Leon Stöwer, aka kleb.

Software and infrastructure engineer (broke it first, understood it second) in Germany. I am interviewing myself here - the questions are real; the interviewer is not.

Who?

Leon Stöwer - kleb on the internet, born 1999. I am an idiot with enough scar tissue to recognize the same bad problem twice. I build tools that take something annoying (shit that bugs me) and make it simple (the hard kind of simple) enough to operate, then I run the infrastructure they live on.

What does the stack look like?

TypeScript on the surface - terminal UIs, local-first desktop tools, and small web applications, mostly on Bun. Debian 13 underneath, virtualized with Proxmox VE (open-source platform for running VMs and containers). I prefer straightforward Linux systems, systemd services, and deployable binaries over orchestration (yes, that means k8s) the workload doesn't need.

exhibit a - the rack

Two environments - one local, one hosted - joined by a site-to-site VPN (a private routed connection between two networks). Services talk over private networks, public traffic enters through one boundary, and nothing management-shaped faces the internet.

Local

  • virtualization hosts running the private workloads
  • network storage and the backup targets
  • internal DNS, reverse proxies (a server that receives requests and forwards them to internal services), monitoring, VPN and a growing pile of application VMs

Hosted

  • a virtualization host for the public-facing roles
  • public traffic terminates at the reverse proxy here
  • internal services stay on private subnets
ingress
reverse proxies terminate TLS and route domains
dns
internal name resolution, run in both environments
monitoring
one system watching both sides
backups
layered - VM backups plus filesystem snapshot replication
workloads
git hosting, mail, agents, media, and the applications on this site

That is deliberately the whole map - roles, not hostnames. The longer version lives in a note.

Why self-host (because fuck the cloud) this much when managed services would be easier?

Understanding and controlling the whole system is part of the point. Self-hosting isn't always cheaper and rarely means less work. It lets me connect systems that managed services make awkward, expensive, or impossible. Networking, storage, mail, security, and reliability stop being diagrams and become practical experience (the expensive kind).

VM, container, or systemd service?

The cheapest boundary that still isolates it - that one rule places almost everything. The goal is understandable failure and predictable recovery (usually a reboot), not maximum isolation everywhere. The long version, with the flowchart and the Docker rant, is in a note.

exhibit b - the toolchain

  • Git and Forgejo
  • SSH
  • Bun, TypeScript and Node.js
  • Docker, where containers earn it (they rarely do)
  • Codex CLI and Claude Code
  • Python, Go and shell for automation

I do most development, deployment, and troubleshooting directly in the terminal. If the rest disappears, I keep Git, SSH, Bun, Forgejo, and the coding-agent CLIs.

Most important lesson the homelab has taught you?

A backup I have never restored is a rumor (learned the hard way). I layer backups, keep infrastructure reproducible where practical, and rehearse the restore path before an outage does the scheduling for me.

exhibit c - the eras

  1. A KVM slice - a small BuyVM instance, bought for a Minecraft server. Broken multiple times before it ever started properly - the breaking taught more than the starting.

  2. Static HTML - simple hand-written pages, hosted from that same slice. A public surface, technically.

  3. The VMware detour - six months. Brief on purpose.

  4. Proxmox on real hardware - a Kimsufi box - actual metal, no longer someone else's virtualization. Improvised services become workloads with dedicated roles.

  5. Hetzner - same Proxmox, bigger metal. Three root servers worn through so far.

  6. The local cluster - two compute nodes and a storage server with the NAS (network-attached storage shared across machines) as backend, joined to the hosted side over the VPN.

  7. Debian and TypeScript settle in - the standard platform underneath, the daily language on top.

  8. Tools for other people - planning, review, utility, time-tracking and gateway applications - internal and public.

  9. AI-assisted development - roughly 2025 onward: agents wired into development and operations, including dedicated model-routing and code-review services.

exhibit d - the metal

The local cluster, itemized. Roles stay abstract; the hardware (overkill is the point) doesn't have to.

server-01 / server-02

compute

cpu
Intel Core i5-12600
ram
64GB DDR5 (2x 32GB)
network
10GbE
storage
2x 256GB Transcend 220S

server-03

storage

cpu
AMD Ryzen 5 5600G
ram
128GB DDR4 (4x 32GB)
network
10GbE
storage
8x 4TB Samsung 870 Evo - RAIDZ2 (ZFS RAID that survives two disk failures), ~22.6TB
4x 14TB Seagate Exos X16 - RAIDZ1 (ZFS RAID that survives one disk failure), ~47TB

Where does everything live?

Everything publishable (the rest is classified) is in the open on git.kleb.sh/kleb(opens in new tab). Mail reaches me at leon [at] stoewer [dot] one. The highlights are on /projects; longer thoughts land in /notes.

Seriously though, who?

the dude, the paradox, a cosmic glitchexistence's inside joke wandering reality's punchlinesurfing chaos with a grin