5 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 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?