Show HN: Pipenet – A Modern Alternative to Localtunnel
Posted by punkpeye 4 days ago
Hey HN!
localtunnel's server needs random ports per client. That doesn't work on Fly.io or behind strict firewalls.
We rewrote it in TypeScript and added multiplexing over a single port. Open-source and 100% self-hostable.
Public instance at *.pipenet.dev if you don't want to self-host.
Built at Glama for our MCP Inspector, but it's a generic tunnel with no ties to our infra.
Comments
Comment by ollybee 4 days ago
Comment by punkpeye 4 days ago
Added https://github.com/anderspitman/awesome-tunneling/pull/214
Comment by wahern 4 days ago
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.
Comment by evgen 4 days ago
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.
Comment by Trufa 4 days ago
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.
Comment by punkpeye 4 days ago
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.
Comment by punkpeye 4 days ago
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.
Comment by otabdeveloper4 4 days ago
Simply using 4096 bit RSA instead of 2048 is enough to cause a denial of service attack.
Comment by Ingon 4 days ago
Comment by kxbnb 3 days ago
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.
Comment by lizimo 4 days ago
Comment by punkpeye 4 days ago
I did this morning in a rush. Didn't expect anyone to compliment it. Thank you!
Comment by oakesm9 4 days ago
Comment by punkpeye 4 days ago
Comment by qudat 4 days ago
Comment by punkpeye 4 days ago
Comment by 8964689797595 4 days ago
Comment by punkpeye 4 days ago
I was expecting this to be the first comment.
Comment by armeet 4 days ago