UpTrajectory Review

Vincent Bernat's post walks through building your own HTTP tunnel using nothing more than SSH and Nginx — the same trick services like ngrok or Cloudflare Tunnel sell as a managed product, reconstructed from two tools most operators already run. The premise: when you need to expose a local service to the internet — a demo on a laptop, a webhook receiver behind NAT, a staging box in a home lab — you can lean on SSH's built-in TCP forwarding and let Nginx handle the public-facing termination and routing, rather than hand a third party the middle of your traffic. Bernat is a long-time network engineer whose blog posts tend to be exhaustive and production-tested, and this one is circulating on Hacker News because it scratches an itch many small operators have: paying a subscription for something that feels like it should be infrastructure.

For a small-business operator, the appeal is partly cost and partly control. ngrok's free tier has tightened over the years, and commercial tunnel services charge per hostname, per tunnel, or per seat — real money if you run several environments. More importantly, every managed tunnel is a third party that can see your traffic metadata, impose rate limits, or change terms. Rolling your own means the only intermediaries are servers you already pay for and SSH you already trust. It also fits a pattern worth internalizing: the modern default is to rent a hosted abstraction of a solved problem, and a surprising number of those abstractions dissolve under an afternoon of configuration.

What is genuinely useful here is not the novelty — SSH port forwarding is decades old — but the completeness. Tutorials for raw SSH tunnels usually stop at 'ssh -R works,' leaving you to discover the failure modes yourself: Nginx needs to trust forwarded headers, SSH sessions die and need autossh or systemd supervision, and a single forwarded port per SSH connection gets clumsy fast. Bernat's writeups characteristically address exactly these rough edges, which is why they get bookmarked rather than skimmed. We are mildly skeptical of one thing: self-hosted tunnels trade vendor lock-in for operational burden. If you are not already comfortable running Nginx and debugging TLS, the subscription fee is buying you uptime, not just convenience.

The second-order effects cut in both directions. On one side, every operator who internalizes this pattern becomes less dependent on SaaS middlemen, which compounds: the same SSH-plus-reverse-proxy setup covers internal dashboards, CI webhooks, and IoT devices, not just developer demos. On the other side, tunnels are also how attackers exfiltrate — a compromised internal host with outbound SSH can punch a reverse tunnel straight past your firewall, so if you run a network with more than a handful of machines, this post is also a reminder to audit outbound SSH and monitor for unexpected forwarding listeners. The skill and the threat model are the same diagram read from opposite sides.

If you run anything behind NAT or CGNAT — a home-lab NAS, a branch-office server, a contractor's staging environment — this is worth an hour of your time this week. Reproduce Bernat's setup against a cheap VPS, put it under systemd so it survives reboots, and document it in your runbook before you need it for a client demo. Then do the defensive pass: check your firewall rules for unrestricted outbound SSH, and consider whether your network would notice a rogue reverse tunnel. The best time to learn this pattern is calmly, on your own infrastructure — not at 4pm when a webhook integration needs to go live and ngrok is rate-limiting you.

Takeaway: Self-hosted SSH-plus-Nginx tunnels replace a paid ngrok subscription with infrastructure you already run — but audit outbound SSH, since the same trick is an exfiltration path.