标签：#tunnel

Every internal tool I need sits behind SSH. Grafana, Prometheus, the staging clusters, internal AI tooling—none of it answers on a public address, and the only door is a bastion I have a key for. That is the right setup for anything with real data behind it, and I wouldn't change it. What I did change is typing ssh -N -L 3000:localhost:3000 -J bastion prod-1 from memory four times a day across three different machines. So one weekend, I started writing SSH Config Manager . It is a native macOS app that edits ~/.ssh/config without wrecking formatting, saves tunnels as presets, and opens those tunnels in-process instead of shelling out to ssh . I wrote it for my own workflow first. Putting it on the App Store came later, once it was genuinely useful to me and I figured others were struggling with the exact same friction. The VPN Question The first thing people ask is: why not run a VPN and be done with it? Fair question, but the honest answer is that SSH is the tool I already understand inside and out. I have configured sshd enough times to know what PermitRootLogin no and PasswordAuthentication no actually change. When a connection stops working, I can usually name the exact line that broke it. A VPN introduces a whole second network layer underneath, complete with its own credentials, its own background daemon to keep patched, and its own unique failure modes to debug at 2:00 AM when production is down. SSH is already on every Linux server I touch and every developer machine I own — there is nothing new to roll out and nothing new to secure. The tradeoff is real, and I would rather acknowledge it up front. Operating without a VPN means no transparent network routing: every internal service I want to reach must be explicitly forwarded to a local port in advance, and a colleague without my config reaches none of them. Still, I would far rather maintain a clean list of port forwards than maintain another background daemon. Shell Aliases Do Not Survive Three Machines Th

If you've ever needed to let a third-party service talk to your local dev environment, you've probably reached for ngrok. I've been moving some of that over to Tailscale Funnel instead — here's what works, what broke, and how it stacks up against Cloudflare Tunnel. Key takeaways Tailscale Funnel exposes a local dev server to the public internet, similar to ngrok or Cloudflare Tunnel — useful for testing webhooks, payment callbacks, or anything a third party needs to reach on your machine. It's free for solo/small use, with no device limit on the Personal plan (up to 6 users). tailscale serve is tailnet-private; tailscale funnel is what actually makes something public — easy to mix up. Getting it working behind Caddy + Symfony in Docker means fixing two separate redirect loops (one from Symfony, one from Caddy's own auto-HTTPS) and explicitly telling Symfony to trust the proxy. The one real trade-off versus Cloudflare Tunnel: no custom domain with a valid cert — you're stuck with the ts.net hostname unless you accept a browser cert warning. This isn't a "ngrok / local tunnel / Cloudflare tunnel is bad" post. It's a "here's another tool that does the same job, and here's exactly what broke when I set it up" post. Why bother? A few reasons I looked at Tailscale instead of just defaulting to ngrok again: Stable hostname. ngrok's free tier gives you a random URL that changes every time you restart it. Tailscale Funnel gives you a fixed hostname tied to your machine ( your-machine.your-tailnet.ts.net ) that doesn't change. Genuinely free for solo/small use. Tailscale's free Personal plan covers up to 6 users with no device limit at all — plenty for a solo dev juggling a laptop, a desktop, and a couple of test machines. No "3 device" ceiling to bump into. Already in my toolchain. I use Tailscale for other things, so there's no new account, no new pricing tier to think about. Automatic HTTPS. Tailscale handles certificate provisioning for you — no separate cert step. The tr