I’m a software engineer focused on highly scalable infrastructure — decentralized, open source, and built to last.
I co-founded Five Binaries, building products and infrastructure on top of distributed systems.
Outside of engineering, I’m interested in governance models — particularly liquid democracy and how decentralized decision-making can work at scale.
A Midnight node is a Cardano partner chain, which means it has to watch the Cardano main chain to do its job. It reads token registrations, stake distributions, governance UTXOs and bridge transfers from Cardano and folds them into its own blocks. The documented way to do that is to run cardano-node next to it, plus cardano-db-sync, plus the PostgreSQL database db-sync fills. On mainnet that’s 64GB RAM and a machine that takes days to sync before your Midnight node has even started. It’s an absurd amount of infrastructure to hang off a Raspberry Pi. But is it really needed? ...
Few days ago I built a CI pipeline that flashes AutoSD onto a Raspberry Pi 4 and tests it on real hardware. It builds the image, flips an SD-Wire mux, power-cycles the board through a smart plug, waits for SSH, and runs a pytest suite — on every push. That was the fun part. This is the sequel, and it has a sillier premise: what if the same pipeline also tested my actual car? ...
This started as a weekend project. I had a Raspberry Pi 4, some spare hardware lying around, and a question: could I set up a fully automated CI pipeline that builds an automotive Linux image and validates it on real hardware — end to end, no manual steps — in a single day? And how many club-mates would it take? The answer is 4, and here’s how it works. The testbench. SD Wire circled at the bottom — this is what lets the runner flash the card without touching it. Shelly Plug S circled at the top — smart outlet for remote power control. AutoSD is the CentOS Automotive SIG’s Linux distribution aimed at in-vehicle software. It’s an ostree-based OS with a real-time kernel, built for the kind of reliability requirements you’d find in a car. I wanted a proper test setup: not just “does it boot”, but a fully automated pipeline that builds the image, flashes it to real hardware, and runs a test suite on every single push — no manual steps, no “works on my machine.” ...
My Raspberry Pi 5 with 16 GB of RAM had been sitting mostly idle for a few months — running the usual homelab suspects, nothing that really pushed it. Then MicroShift caught my eye. A single-binary OpenShift/Kubernetes distro built for edge devices, maintained by Red Hat, targeting exactly the kind of constrained ARM hardware I had on my desk. I decided to give it a proper shot. Why MicroShift I’ve been working with OpenShift professionally for a while, and the appeal of having a real OCP-compatible cluster at home — one that speaks the same APIs, uses the same RBAC model, and supports the same operator patterns — is hard to overstate. Alternatives like k3s or microk8s are fine, but they diverge enough that you’re always translating. MicroShift is a subset, not a fork. Anything I test locally maps directly to what runs in production. ...