ronald → ~/lokilabs $ whoami
Do it twice?
I’ll automate it
from TypeScript to Kubernetes: i build the tooling that keeps software boring to deploy, and write down what breaks along the way.
about/
$ whoami --verbose15 years of frontend and fullstack at Coolblue, Mendix, and Oliver IT. The part I loved was never the UI — it was the pipelines and infrastructure underneath. A health break at the end of 2024 turned into the pivot: I started retraining on platform work in dec 2024, and since mid-2025 (fully cleared) I'm all-in on it.
in practice
- Raspberry Pi CM5 Kubernetes cluster, three HA control planes, run like production — GitOps with FluxCD (repo)
- Prometheus + Grafana observability; Longhorn, MetalLB, Renovate
- Daily: Arch Linux, Docker, CI/CD design, cluster operations
Ready to bring 15+ years to a Platform or DevOps role. Get in touch →
away from the keyboard
Rally Chief Official and Rescue Marshal at KNAF rallies; Event Traffic Controller at village events in Fijnaart. Different kind of incident response.
writing/
$ ls ~/lokilabs/writing — posts open right hereprojects/
$ lokictl get projects — click one to open itronald lokers
ronald@lokilabs.nl · linkedin.com/in/ronaldlokers
A health break turned pivot: retraining started dec 2024, full-time on platform work since mid-2025. Built a multi-node Kubernetes cluster (Raspberry Pi CM5) run like production — GitOps with FluxCD, full Prometheus/Grafana observability. Fully cleared and eager to get back to work.
Full-stack internal applications for enterprise clients — Node.js, TypeScript, React; CI/CD pipelines with GitHub Actions.
Mendix Studio's Page Editor — developer tooling at platform scale. Reusable React components used by thousands of developers; large TypeScript codebase; CI/CD with Jenkins and GitHub Actions.
Webshop frontend through explosive growth (~20 to 100+ engineers). Cut frontend build times from 2m45s to seconds; led SMACSS CSS modularization; built a React + TypeScript customer-service tool.
Frontend and email templates in a .NET environment for Landal GreenParks, Van der Valk, Kia, Domino’s Pizza, and North Sea Jazz.
Built and managed websites and newsletters.
Websites and newsletters for SMBs (valid XHTML!), plus SEO/SEA advisory.
Side business building websites for local clients, long before it was called freelancing.
education
$ echo "still reading? let's talk."
from frontend to platform
Fifteen years of frontend and fullstack work — Coolblue, Mendix, Oliver IT — and a pattern I could no longer ignore: every project, I’d finish the UI work and then drift toward the build config. The webpack setup nobody wanted to touch. The flaky pipeline. The deploy that took forty minutes and failed at minute thirty-nine. That was the part I looked forward to.
A health-related career break forced the question directly: if I get to choose again, what do I choose? (Health is fully under control — this isn’t that kind of post.) The answer wasn’t “more UIs.”
So I built production at home
Since mid-2025 I’ve gone all-in on platform engineering. Not with a course and a certificate — with a cluster:
- Kubernetes on Raspberry Pi CM5 hardware — three HA control planes, because if it can’t survive a node dying, it’s a toy
- GitOps with FluxCD — every workload, every config, declared in Git. The cluster state is the repo (see for yourself)
- Observability that answers questions — Prometheus and Grafana with real dashboards and real alerting, not a default install
- Longhorn for replicated storage, MetalLB for load balancing, Renovate so dependencies never rot
Daily driver is Arch Linux. Everything I learned about developer experience in fifteen years of frontend now goes into pipelines other developers would actually enjoy using.
Why “lokilabs”
Loki from Lokers, labs from what this actually is: a lab. This site is where I write down what the lab teaches me. Expect posts about the cluster, CI/CD design, AI tooling, and the occasional thing that caught fire.
If you’re hiring for a Platform or DevOps role and want someone who’s seen both sides of the deploy button: ronald@lokilabs.nl.
building four apps with claude code
Every project on this site was built with Claude Code in the loop: a treadmill controller, a job-hunt tracker, a glucose TUI, and the site you’re reading. Four very different stacks. Some honest notes.
What changes
The graveyard shrinks. Every developer has a folder of side projects that died at 30%. The boring middle — the settings page, the error states, the CI workflow — is where they die. That’s exactly the part AI is relentless at. Projects reach done now.
Scope stops scaring me. WalkFit speaks a Bluetooth protocol to a physical treadmill and renders a survey-exact 400m athletics track in 3D. Past me would have filed that under “someday”. It shipped — with CI, E2E tests, and deploys.
Unfamiliar stacks stop being a wall. sugarrush is written in Rust. I’m not a Rust developer — Claude wrote it, out of my interest in the stack. The gap between “I don’t know this language” and “working software I trust” used to be months; now it’s an evening plus careful review.
What doesn’t change
Taste is still the job. The model will happily build the wrong thing beautifully. Deciding what to build, what not to build, and when the answer is “delete it” — that’s still on me.
Review is still the job. Everything gets read. The dotfiles repo I built by hand over years, and I extend it with Claude Code the way I’d take PRs from a fast colleague: gratefully, but with eyebrows engaged.
Ownership is still the job. Zenith runs on Cloudflare’s free tier. When something breaks at the platform level, no model saves you — understanding your own architecture does.
The uncomfortable summary
The bottleneck moved. It’s no longer typing speed or stack familiarity — it’s judgment: knowing what good looks like and insisting on it. Fifteen years of building things turns out to be excellent training for exactly that.
The tools got faster. The standards didn’t drop. That combination is the whole game.
blood glucose in the terminal
I have diabetes. I wear a continuous glucose monitor, and its readings land in Nightscout — the open-source, self-hosted CGM platform that the diabetes community built years before “own your data” was a slogan.
I also spend my whole day in a terminal. Alt-tabbing to a phone app to check a number felt wrong. So: sugarrush — a terminal UI for Nightscout data, written in Rust with Ratatui.
Why a TUI
A glucose reading is one number, a trend arrow, and a bit of history. That’s not an app; that’s a status line. The terminal is where I already live, and a TUI has exactly the right properties:
- Glanceable. Current value, trend, and a sparkline of the last hours, in a pane that’s always one keystroke away.
- Calm. No push notifications, no login screens, no loading spinners. It’s the same data my phone shows, minus the ceremony.
- Mine. It talks to my Nightscout instance. No vendor cloud in the loop deciding what I’m allowed to see.
Why Rust — and who wrote it
Full honesty: I didn’t write the Rust — Claude Code did. I picked the language out of interest: a TUI should start instantly and sip resources, and Rust + Ratatui is the obvious modern stack for that. My job was the product side — what to show, what to skip, does the trend arrow feel right — plus reviewing code in a language I don’t write myself. I’m not a Rust developer. I am the guy who depends on this thing before lunch, which turns out to be a very motivating QA role.
The bigger point
Diabetes is a data problem you carry in your body. The community understood that early — Nightscout exists because patients refused to wait for vendors. Building my own window into my own data is the same instinct that runs the rest of this site: self-host it, script it, own it.
Also, let’s be honest: watching your glucose curve flatten out in a crisp little terminal sparkline is deeply satisfying. Different kind of observability stack.
three control planes on a stack of raspberry pis
Most homelabs are a single node with a note that says “don’t touch”. Mine has three control planes. People ask why. The answer is the whole point of the lab: if it can’t survive a node dying, I’m not learning anything.
The hardware
Raspberry Pi CM5 modules, running k3s. Three of them form the control plane —
control-plane,etcd roles on every node:
ronald → homelab $ kubectl get nodesNAME STATUS ROLES AGE VERSIONcm5-01 Ready control-plane,etcd 212d v1.33.6+k3s1cm5-02 Ready control-plane,etcd 212d v1.33.6+k3s1cm5-03 Ready control-plane,etcd 211d v1.33.6+k3s1ronald → homelab $ Three isn’t a random number. etcd needs quorum: with three members you can lose one node and keep a majority. Two nodes would actually be worse than one — lose either and the whole cluster freezes. The smallest honest HA setup is three, so three it is.
The rules
The cluster runs like production, which means production rules:
- Everything is declared in Git. FluxCD reconciles the cluster from the
repo. Nothing is ever
kubectl apply’d by hand. If it’s not in Git, it doesn’t exist. - Storage is replicated. Longhorn keeps three replicas of every volume, so a dead node doesn’t take data with it.
- There’s a real load balancer. MetalLB hands out addresses, because
NodePortis not a personality. - Dependencies don’t rot. Renovate opens PRs for every chart and image update. I review and merge like it’s a team repo, because future me is the team.
- There’s a staging environment. A k3d cluster mirrors production, because you don’t test in prod. Not even at home.
What it actually teaches
Pulling the plug on a node and watching the cluster shrug is the lesson you can’t get from a course. Workloads reschedule, Longhorn rebuilds replicas, etcd keeps quorum, and the Grafana dashboards show you exactly what happened and when.
And when something doesn’t shrug — when a reconciliation loop gets stuck or a volume won’t reattach — that’s the good part. Production incidents at home cost nothing and teach everything.
The pile of Pis is small. The habits it builds aren’t.
homelab
production
A multi-node Kubernetes homelab that refuses to behave like a homelab.
- Production: three HA control planes (k3s) on Raspberry Pi CM5 hardware, Longhorn replicated storage, MetalLB load balancing
- Staging: a k3d cluster that mirrors production, because you don’t test in prod — not even at home
- GitOps end to end: FluxCD reconciles the cluster from this repo. Nothing is applied by hand; the Git history is the change log
- Observability: Prometheus and Grafana with dashboards and alerting
- Renovate keeps every chart and image current via automated PRs
This is where the platform engineering pivot lives in practice: every concept I want to learn gets deployed, monitored, broken, and fixed here first.
walkfit
beta
The result
A browser tab drives a physical treadmill. Belt speed, guided workouts, heart-rate-steered pacing, a survey-exact 3D athletics track — no app store, no account, no backend. Everything runs client-side and ships from a static host.
The problem
The Dreaver Motion One is a walking pad with a basic vendor app. I wanted structured weight-loss workouts, heart-rate control, and progress tracking — and I wanted to own the data instead of feeding another fitness cloud.
The approach
- Web Bluetooth speaks the treadmill’s FitShow FS-BT-T4 protocol directly from the browser — the tab is the controller
- HR control loop: connect any BLE heart-rate source (chest strap, broadcasting watch) and the app nudges belt speed to hold a target zone
- A virtual 400m track: survey-exact IAAF geometry — real lane staggers, relay zones, waterfall start — walkable as a 2D lap ring or first-person 3D scenic walk with a distance-driven day/night cycle
- Local-first: all state lives in the browser; optional one-tap Strava upload and Withings weigh-in sync
- Production discipline: CI, E2E tests, and deploys via GitHub Actions
The constraints
Web Bluetooth only exists in Chromium browsers — Safari and Firefox don’t ship it, so the controller is Chrome/Edge-only by platform reality, not by choice. And a control loop for a physical belt someone is standing on gets tested very, very carefully.
Built with Claude Code.
zenith
beta
The result
A complete SaaS — kanban pipeline, sourced-listings inbox, CV builder, analytics — running entirely on Cloudflare’s free tier. Live at zenith.lokilabs.nl, invite-only.
The problem
A job search is a pipeline: applications advance through stages, stall, convert, or ghost. Spreadsheets don’t show momentum, and the tracker SaaS options want your data on their terms. I was job hunting anyway — so the tracker became the project.
The approach
- Pipeline as kanban: five stages (interested → applied → screening → interview → offer), drag-to-restage, filters, saved views, archive
- Sourced-listings inbox: pulls fresh roles every 6 hours from Adzuna and any Greenhouse/Ashby boards you follow, filtered by role keywords — swipe to triage
- Analytics that answer questions: conversion funnel, response rate, median time-in-stage, ghost rate — where do deals stall?
- CV builder with multi-language support and PDF export
- Privacy by default: no analytics, no tracking, invite-only accounts
The constraints
The whole thing is designed inside Cloudflare’s free-tier quotas — compute, storage, and scheduled jobs all budgeted to cost exactly €0. Free-tier architecture is a real discipline: every feature gets designed twice, once for the product and once for the quota.
Built with Claude Code.
sugarrush
daily use
Blood glucose monitoring belongs in the terminal like everything else. sugarrush renders Nightscout CGM sensor data as a TUI — live readings, trends, and history without leaving the shell.
Written in Rust with Ratatui. Built with Claude Code.
dotfiles
daily use
The same GitOps instinct as the homelab, applied to the workstation: the whole machine setup lives in Git, managed with chezmoi. Templates for per-machine differences, age-encrypted secrets, tooling pinned via mise.
Base built by hand over the years; extended with Claude Code.
lokilabs.nl
live
The site you’re reading. Markdown in, static HTML out — zero client-side JavaScript shipped.
- Astro 7 with typed content collections: blog and project frontmatter validated by zod at build time, so a bad date fails the build instead of the page
- Fira Code self-hosted, brand tokens as CSS custom properties, and a pixelized headshot as the mark
- RSS feed and sitemap generated at build
- Deployed on Cloudflare Pages: push to
main, preview deploys per PR
Designed in Claude Design, built with Claude Code.
ronald lokers
ronald@lokilabs.nl · linkedin.com/in/ronaldlokers
A health break turned pivot: retraining started dec 2024, full-time on platform work since mid-2025. Built a multi-node Kubernetes cluster (Raspberry Pi CM5) run like production — GitOps with FluxCD, full Prometheus/Grafana observability. Fully cleared and eager to get back to work.
Full-stack internal applications for enterprise clients — Node.js, TypeScript, React; CI/CD pipelines with GitHub Actions.
Mendix Studio's Page Editor — developer tooling at platform scale. Reusable React components used by thousands of developers; large TypeScript codebase; CI/CD with Jenkins and GitHub Actions.
Webshop frontend through explosive growth (~20 to 100+ engineers). Cut frontend build times from 2m45s to seconds; led SMACSS CSS modularization; built a React + TypeScript customer-service tool.
Frontend and email templates in a .NET environment for Landal GreenParks, Van der Valk, Kia, Domino’s Pizza, and North Sea Jazz.
Built and managed websites and newsletters.
Websites and newsletters for SMBs (valid XHTML!), plus SEO/SEA advisory.
Side business building websites for local clients, long before it was called freelancing.
education
$ echo "still reading? let's talk."