Build in Public · ~5 min · Origin Story

The frustration that
became HLE

I've been self-hosting for over a decade. And for most of that time, the hardest part was never setting up the service — it was accessing it from anywhere else.

The beginning

The ritual

Every project starts the same way. You find a cool self-hosted app, spin it up, get it running on localhost:8096 or whatever port it picks, and it works. It works great, actually. You're impressed with yourself.

Then you think: "I want to check this from my phone. From work. On the road."

And that's where the real work begins. The part that has nothing to do with the thing you actually wanted to run.

The options

The usual suspects

You know the options. I've cycled through all of them over the years.

Port forwarding — the classic. Open a port on your router, pray your ISP doesn't block it, set up dynamic DNS because your IP changes every few days. Hope nobody scans it before you remember to close it. We've all seen the articles — exposed dashboards, open databases, cameras streaming to the internet. A brief mention is enough. We all know.

Reverse proxies — set up your preferred proxy server, configure virtual hosts, manage SSL certificates, renew them, debug config syntax at midnight when something stops working. It's powerful, but it's infrastructure work on top of the thing you actually wanted to do.

VPNs — solid for personal access, but try sending someone a link to something you're hosting. "First, install this VPN client, then import this config file, then..." They've already stopped reading.

Basic auth — the quick-and-dirty layer you throw on when you don't fully trust the app's built-in authentication. Which, honestly, is often. But then you're typing xK9#mP2$vL on a phone keyboard while standing in a grocery store, and you question every decision that led you here.

Each approach works. None of them are simple. And there's always this low-grade anxiety in the background: is this actually secure? Did I configure it right? Is that port still open from three months ago when I was testing something?

The turning point

The accumulated frustration

There was no single breaking point. No dramatic incident. Just years of the same cycle:

Spin up a service
Spend twice as long making it reachable from outside
Half-trust the result
Sometimes just… not bother

That last one is the real cost. The projects you don't share. The demo you don't give. The dashboard you only check when you're home. Self-hosting is supposed to give you control, but the access problem quietly takes some of that control away.

At some point — I genuinely can't tell you when — the frustration crystallized into a question: what if it were just simple?

Point it at a local port. Get a secure URL. No DNS, no certs, no firewall rules, no proxy configs. Done.

The evolution

How it grew

HLE started as the most basic thing imaginable: a WebSocket tunnel that could forward HTTP requests to a local service. One connection out from your machine, no ports to open. That was v0.4.0 — a CLI you could install with pip, three commands, and a lot of rough edges.

Then I started sharing it with a handful of friends who run their own home labs, and their feedback — combined with what I kept running into myself — started shaping it.

Self-signed certificates Nearly every home lab service — Proxmox, Unraid, TrueNAS — uses self-signed SSL. The tunnel kept choking on cert verification errors. So SSL verification got flipped to off-by-default, with an opt-in --verify-ssl flag. A small change, but the first time I thought: this tool has to meet home labs where they are, not where textbooks say they should be.
The Host header saga Services behind virtual-host proxies route by the Host header. When HLE forwarded requests, the header said my-app.hle.world instead of what the local service expected. Result: 502 errors. It took three iterations to get right — stripping the header, auto-detecting whether to forward it, then making the detection sticky so it only costs one request per session.
Chunked streaming Video feeds, large file downloads — anything that didn't fit in a single response body caused 504 timeouts. The fix: split responses into 512KB chunks, send them over the tunnel as they arrive, reassemble on the other end. A new wire protocol version, three new message types, full backward compatibility.
Auth kept evolving First it was just API keys for tunnel authentication. Then I wanted to share tunnel URLs with people — and realized I needed to protect them. So Basic Auth went in, then PIN codes, then email-based access rules, then full SSO with Google and GitHub. Each layer came from me thinking "I wouldn't feel safe sharing this link yet."
The platform grew outward What started as a Python CLI became a Home Assistant addon, then a Docker image, then a Homebrew formula, then a Kubernetes operator. Each distribution channel came from the same question: "Where am I — and where are my friends — already running things?" The answer was everywhere, so HLE had to be everywhere too.

Looking back at the changelog, seventeen versions shipped in about three weeks. Not because of some sprint mentality, but because every time I tested something new, or a friend tried it on their setup and pinged me back, there was another rough edge to smooth out. Each fix made the tool closer to what I'd always wanted.

Why it exists

That's why HLE exists

It's the tool I wished I had ten years ago, when I was forwarding ports at midnight and hoping for the best. It's not trying to replace your reverse proxy or your VPN or your entire networking stack. It's the thing you reach for when you just want a URL that works, right now, without the ritual.