Why I built my own reverse tunnel

I've kept a reverse tunnel within reach for years. When I want to show someone a site running on my laptop, or point a webhook at something half-written, it's the quickest way to give a local port a public URL without touching my router. ngrok was my default, and I get why it's most people's: polished, a genuinely useful request inspector, and it mostly just works. What wore on me was everything around the tunnel. An account and an auth token before I could start, a warning page in front of anyone I sent a link to, and the parts I wanted most behind a paid plan. All reasonable for a business. It just meant a URL for a port came wrapped in more than I wanted to carry.

So I looked around. localtunnel is the simplest version there is: open source, a free server, one command, no account. But it's bare, no way to password-protect a tunnel and no view of the traffic, so the moment I wanted to hand a link to one person and know only they could open it, I was on my own again. Pinggy fixes that cleverly. It runs over plain SSH, so there is nothing to install, and it does raw TCP and TLS on top of HTTP. The catch was that I was routing traffic through a service I couldn't see inside or run myself, with the parts I wanted most behind the paid tier. I kept wishing I could just read the thing.

That wish is what led me to build viaduct. I wanted something in the gap: small enough to read in an afternoon, simple enough to run on one cheap server, honest enough to trust with my own traffic. So I wrote one, a few thousand lines of Python, with a free hosted version and no accounts, mostly so I'd actually reach for it.

Here's the part I didn't expect. I assumed the tunnelling would be the hard bit, splicing bytes from a public URL back to my laptop. It was the easy half. The half that taught me something was the connections I couldn't see. A tunnel keeps a pool of connections open and idle, waiting for the next request, and I kept hitting a failure where a tunnel left running would go quiet, hang, then recover on its own. It took me too long to work out they weren't dying cleanly. Something in the middle, a NAT or a firewall, was quietly dropping them while both ends still believed they were fine.

What surprised me was how ordinary and how invisible that is. Every tunnel has some version of it. The only reason I could find and fix it was that I could open the code and watch what the connections were doing, instead of filing a ticket and hoping. That's when it clicked: the thing I valued most about building my own wasn't a feature I could put in a table. It was being able to look inside when something behaved in a way I didn't understand.

viaduct isn't the right choice for everyone. If you need a database port tunnelled, or nothing installed at all, the others fit better, and the table below shows where each wins. But building it left me wondering how many tools we treat as black boxes out of habit, and how differently we'd use them if reading the source was the first step instead of the last. For a reverse tunnel, that turned out to be the whole point.

Side by side

Same story as a table. ngrok for the polished hosted default if you don't mind an account, localtunnel for the simplest open tunnel, Pinggy for zero-install and raw protocols, viaduct to read, run, and gate it yourself.

Compared August 2026. Free tiers, paid features, and regions move around, so check each provider's current plans before you lean on a row.

If reading it and running it yourself is the part you want, viaduct is open source on GitHub, and the docs get you started in two commands.

← All articles