10 posts
Most personal projects and homelab services don’t need to be public, but they do need to be reachable. I want to access my dev tools, internal dashboards, and side projects from anywhere, on any of my own devices, without opening ports, exposing IPs, or worrying about who might stumble across them on the internet.
This post walks through how I built an everywhere-accessible but publicly invisible ingress engine using Tailscale, Docker, Caddy, and DNS rewrites. The result is a private, domain-based setup that behaves like a small cloud. It has HTTPS, clean hostnames, and reverse proxying, but is only accessible to me, lives on my own machine, and never touches the public internet.
I wanted a Docker setup for my Eleventy resume project that also generates a PDF using Puppeteer. I assumed this would be straightforward. It wasn’t.
Here’s the real path, from zero to working, with the errors along the way and what each one actually meant.
I wanted first-party analytics on my blog without handing traffic data to a SaaS vendor. Umami checked every box: open source, self-hostable, and friendly to privacy. I already keep a small VPS online 24/7, so dedicating a slice of that machine to Umami felt like a perfect fit.
Analytics turned into a blind spot once I shut off the usual trackers. I needed something:
Rust is one of the most thoughtfully designed languages of our time — but setting it up on macOS can feel oddly opaque. The standard advice is to run a one-liner like curl https://sh.rustup.rs | sh, which works beautifully but hides a lot of what’s happening behind the scenes. For developers who are more security-conscious or just prefer to know what’s being installed and where, this default approach can feel like a black box.
This post explores the different ways to install and manage Rust on macOS — from the convenience of Homebrew to the flexibility of rustup, and the transparency of manual or containerized setups. The goal is simple: give you control and understanding without sacrificing practicality.
Recently, a few hours after setting up Umami with Docker and Nginx on my VPS, I stumbled into a misconfiguration that left the admin dashboard exposed to the public web. Thankfully, there was no immediate danger. Since right after creating Umami's docker instance, I have updated the admin username and password immediately, and locked it down before anything bad could happen. Still, it was a stressful reminder that small mistakes in deployment can have big consequences.
Here’s the story of what happened and what I learned along the way.
Like a lot of developers coming from Linux or a server environment, I hit some confusion when setting up Docker on my Mac. On Linux, you just install Docker and it works natively. On macOS, it’s a bit different — there’s no native Docker Engine because we don’t have a Linux kernel. That’s where tools like Docker Desktop and Colima come in.
Let me walk through what I’ve learned.
I spent the better half of today getting Umami analytics to cooperate with a static blog served through Cloudflare and an Nginx proxy. The tracking script was having issue in Safari (CORS) and Firefox (nothing showed up in the Developer Tools' Network tab).
This is the story of following the trail from mysterious redirects to CORS ghosts and finally to Firefox’s stealthy sendBeacon API.
Over the past few weeks, I’ve spent quite a bit of time experimenting with Tailscale, and it has quickly become one of my favorite tools.
If you haven’t heard of it, Tailscale is a secure, easy-to-use mesh VPN built on WireGuard. It lets your devices talk to each other as if they were on the same local network, no matter where in the world they are.
What started as a simple question — "Why can’t I reach my MacBook over Tailscale from my iPhone on mobile data?" — turned into a deep dive into NAT types, relay servers, and the hidden power of IPv6. This post documents the technical journey, the dead ends, and the final conclusion.
So the mystery: why do VPS connections work, but Mac connections fail?