Overhauling a Jekyll blog — dark mode, code blocks, and all the small things

This blog has been running on Jekyll since 2015. The content changed, the stack around it changed, but the blog itself? Same minima theme, same default code blocks, same flat archive page. It was time to fix that.

qubitcoin — a post-quantum Bitcoin rewrite, and why silent RPC failures matter

There’s a particular class of bug I hate more than crashes: the API that quietly returns nothing when you give it garbage input. No error, no 400, just an empty result that looks exactly like a valid-but-empty result. This surfaced while working on qubitcoin, a post-quantum Bitcoin rewrite I’ve been building — so let me introduce that first, then get to the bug.

x402 - HTTP payments that actually work

HTTP 402 Payment Required. It’s been sitting in the spec since 1991 — literally the first version of HTTP that had status codes. “Reserved for future use.” For decades, every web developer has scrolled past it and thought “huh, wonder when that’ll be a thing.”

Well, it’s a thing now. x402 is an open protocol that revives that dusty status code into actual payment infrastructure. Coinbase’s Developer Platform team built the initial implementation, but this isn’t just a Coinbase product — Cloudflare, Polygon, and Solana are backing it as part of a broader push for “agentic payments.” The idea is that any HTTP endpoint can become a digital vending machine: request a resource, get a price, pay on-chain, receive the goods. No accounts, no API keys, no invoicing.

I wired it into one of my projects. The integration is absurdly simple.

mcp-http-tools - any HTTP API as an MCP tool, zero code

I run a bunch of services on a single server. Prometheus for metrics, Loki for logs, PM2 for process management. Checking on them usually meant opening terminals and curling endpoints. I wanted Claude to be able to do that for me — but writing a custom MCP server for every API felt like too much work. So I built mcp-http-tools: a generic MCP server where you define tools in YAML and it proxies requests to any HTTP API.

macosx-audit - know what's running on your Mac

In the last post I teased this one — so here it is! macosx-audit is a single-file bash script that audits your Mac’s security posture. No agents, no daemons, no root required for most checks. Just run it and see what’s there.

bioenv - Touch ID for your environment variables

I haven’t been around here for quite some time. 6 years to be exact! Life got busy, work got busy, everything got busy. But I’m back and I have something cool to share. Let’s get to the point.

Self-hosted GitHub Actions runners — setup, gotchas, and when it's worth it

GitHub-hosted runners are convenient until you look at the bill, or until you need something they don’t offer — a specific OS version, access to internal services, a macOS runner for iOS builds. Self-hosted runners solve all of that at the cost of running your own infrastructure. I’ve got both Linux (on a VPS) and macOS runners running now, and the setup is simpler than I expected. The gotchas, less so.

Self-hosting Supabase on a VPS — what you actually need

Supabase Cloud is genuinely good. Managed Postgres, row-level security, Auth with social providers, Realtime subscriptions, Storage — all wired up, all maintained by someone else. The free tier is generous. So why would anyone self-host it? Cost, mostly. And control. And the fact that your data isn’t sitting on someone else’s hardware if that matters to you. Here’s what actually running Supabase on a VPS looks like, past the “just run docker-compose” step.

SQLite as the production database — when it's actually fine

Every time someone mentions using SQLite in production, the response is predictable: “it doesn’t scale,” “no concurrent writes,” “use Postgres.” And they’re right — if you’re building the next Twitter. But most of us aren’t. Most of us are running apps that serve hundreds of requests per minute, not thousands per second. And for that, SQLite is not just fine — it’s better.

Spot instances on EKS — cutting costs without cutting reliability

Our EKS bill was growing faster than our traffic. Most of it was compute — on-demand t3.medium and t3a.medium instances running 24/7 for services that could tolerate occasional restarts. Spot instances are 60-70% cheaper than on-demand, but the trade-off is AWS can reclaim them with 2 minutes notice. The question was: which services can handle that, and how do you set it up without making the cluster fragile?