alt.hn

1/19/2026 at 4:10:28 PM

Show HN: Pipenet – A Modern Alternative to Localtunnel

 https://pipenet.dev/

by punkpeye

1/19/2026 at 11:01:53 PM

PipeNet is also the name of the scheme independently invented by Wei Dai contemporaneously with USNRL's Onion Routing: http://www.weidai.com/pipenet.txt Onion Routing is what Tor is based on. I'm not sure if the original Tor author(s) knew about PipeNet, but I wouldn't be surprised if they were familiar.

PipeNet was conceived in 1996 (https://cryptome.org/jya/pipenet.htm), before the USNRL work was made public in 1997 (IIRC), so definitely independent, in as much as these things are ever truly independent. Both are derivative of Chaum Mixes (1979), which had become popularized as anonymous e-mail remailers in the 1990s.

P.S. Not a comment about project name clashing, just thought it would be interesting to point out. Wei Dai's PipeNet is all but forgotten these days. But I had came across it (on sci.crypt?) before stumbling on the Onion Routing web page.

by wahern

1/20/2026 at 12:06:35 PM

Sherman, set the wayback machine....

Definitely a blast from the past. One of the things that made PipeNet very interesting compared to its contemporary peers (e.g. onion routing) was that it used fixed size pipes with constant traffic. An observer would be unable to know when traffic was being sent down the pipe so correlation attacks become significantly more difficult. Pair it with some probabilistic encryption like Blum-Blum-Shub and you can party like a late 90s cypherpunk.

by evgen

1/19/2026 at 6:50:38 PM

Nice, just today, I was trying ngrok, localtunnel, and a couple more, they all were pretty slow, fair enough for the free tier, but I'm interested in knowing is there something architecturally hard or expensive with having fast traffic?

I love this and will definitely try it.

I would honestly love to have it with a dockerized version with something like caddy that manages ssl so I can basically just run a docker command have it up and running.

Thank you very much! Great stuff will give it a try.

by Trufa

1/19/2026 at 6:59:58 PM

You might need to define 'fast'.

This should not add more latency than your average VPN, since the overhead of websocket is minimal and roundtrip time is about the same.

At the moment, this is running on a single-instance with no load-balancing. The intended use case was to enable streaming of MCP SSE traffic, which is very lightweight. I would expect this to be able to handle a lot of traffic just like that, but if people start using the public instance for other use cases, I will need to think of ways to scale it.

by punkpeye

1/19/2026 at 7:08:10 PM

I am keeping one eye on how this is scaling.

At the moment there are 5 active tunnels and CPU is at 2%.

I would therefore expect that this can scale quite a bit before it becomes some sort of bottleneck.

Who knows though – maybe I am underestimating the demand. Didn't expect this to get to the front page of HN.

by punkpeye

1/20/2026 at 5:51:12 AM

The overhead of encryption is huge, comparatively speaking.

Simply using 4096 bit RSA instead of 2048 is enough to cause a denial of service attack.

by otabdeveloper4

1/20/2026 at 12:53:41 AM

connet [1] works in p2p fashion and is pretty quick if it can establish direct connection. Most other solutions do route through a separate node, so if your direct to node latency is low it should be comparable to directly hitting that node. It also has a docker release on ghcr. There is also a saas version [2], if you just wanna try it without running the control plane.

[1] https://github.com/connet-dev/connet

[2] https://connet.dev

by Ingon

1/19/2026 at 6:09:16 PM

Cool website! Did you use any web framework or just plain HTML/CSS?

by lizimo

1/19/2026 at 6:11:24 PM

Just plain HTML/CSS.

I did this morning in a rush. Didn't expect anyone to compliment it. Thank you!

by punkpeye

1/19/2026 at 5:05:23 PM

Would this be able to support TCP and UDP in the future?

by oakesm9

1/19/2026 at 5:08:39 PM

The current implementation is HTTP-focused as that was the primary use case. TCP tunneling is possible architecturally but not something I've had in mind. I suggest start by raising an issue on GitHub and adding thumbs up. If it receives enough attention, I will prioritize it. I am less familiar with what would supporting UDP entail, so cannot answer that right now.

by punkpeye

1/19/2026 at 7:26:28 PM

There are other tunneling solutions that support both and https, websockets using ssh tunnels for the communication. For example I use https://tuns.sh which is a managed sish instance

by qudat

1/19/2026 at 7:40:34 PM

Indeed, there are more mature solutions. The primary reason I made Pipenet is because I needed something that can be embedded in Node.js client.

by punkpeye

1/19/2026 at 8:37:35 PM

PiperNet?

by 8964689797595

1/19/2026 at 8:43:23 PM

So funny how no one picked up on this.

I was expecting this to be the first comment.

by punkpeye

1/20/2026 at 12:18:20 AM

haha nice name :)

by armeet

1/20/2026 at 2:40:00 PM

The multiplexing over a single port is a nice touch - solves the random port allocation pain point that makes localtunnel tricky to deploy in restrictive environments.

Curious about the WebSocket overhead in practice. Have you measured latency compared to SSH-based tunnels like bore or rathole? The TypeScript/node.js stack makes it easy to embed, which is appealing for dev tooling integrations.

The fact that you built this for MCP Inspector work is interesting - I've been working on MCP tooling myself and the local dev workflow definitely needs better tunneling options. Nice to see more infrastructure pieces for that ecosystem.

by kxbnb