This is nice and for those who's asking, it's different from ngrok and the others in that you don't need a separate client, (almost) everyone has ssh installed.
To the author, I wish you best of luck with this but be aware (if you aren't) this will attract all kind of bad and malicious users who want nothing more than a "clean" IP to funnel their badness through.
serveo.net [2] tried it 8 years ago, but when I wanted to use it I at some point I found it was no longer working, as I remember the author said there was too much abuse for him to maintain it as a free service
Even the the ones where you have to register like cloudflare tunnels and ngrok are full of malware, which is not a risk to you as a user but means they are often blocked.
Also a little rant, tailscale has their own one also called funnel. It has the benefit of being end-to-end encrypted (in theory) but the downside that you are announcing your service to the world through the certificate transparency logs. So your little dev project will have bots hammering on it (and trying to take your .git folder) within seconds from you activating the funnel. So make sure your little project is ready for the internet with auth and has nothing sensitive at guessable paths.
As someone who has launched something free on HN before, the resulting signups were around 1/3rd valid users doing cool things and checking things out, and 2/3rds nefarious users.
Do you have funding to cover the paying the bandwidth costs which will ultimately result from this? Or if you're running this from a home network, does anyone know if OP should be concerned of running into issues with their ISP?
Yeah, this is the next step. I first wanted to understand if this gets any traction. I think I will provide a dockerized version for the server part that you can just run with a simple command and maybe some interface to create api keys and distribute them to your users.
Fair enough from a business standpoint, but seeing as there are massive privacy/security risks involved in exposing your data to an opaque service, the open source component is probably a non-optional aspect of the value prop.
You should also consider grouping your random hostnames under a dedicated subdomain. e.g. "xxx-xxx-xxx.users.tunnl.gg", that separates out cookies and suchlike.
I run a similar site (https://pico.sh) with public urls and thought the same thing for us. The public suffix has some fuzzy limits on usage size before they will add domains (e.g. on the scale of thousands of active users).
I don’t have tunnl.gg usage numbers but I’m going to guess they are no where near the threshold — we were also rejected.
"We cooperate with law enforcement agencies when required by law. While we do not inspect traffic content, we will provide connection logs and IP address information in response to valid legal process (such as a subpoena or court order) to assist in investigations regarding illegal activity."
I used ngrok when it was the to-go answer for serving localhost (temporarily, not permanent) to the public, but the last time I searched for alternatives I stumbled upon the following jewel.
> tailscale funnel 3000
Available on the internet:
https://some-device-name.tail12345.ts.net/
|-- proxy http://127.0.0.1:3000
Press Ctrl+C to exit.
I've tailscale installed on my machine anyway for some connected devices. But even without this would convince me using it, because it's part of the free tier, dead simple and with tailscale it's coming from kind of a trusted entity.
Hey, I didn't mean to sell another tool over yours! It's just an experience that popped into my mind and I wanted to share. I appreciate your work and contributing to the problem space of exposing a local service. Thank you.
Thats a fair point, there are some protections in place for abuse already. I will have a look at what ngrok does for browser warnings. Thanks a lot for the suggestions.
Be aware of threat actors, too: you're giving them an easy data exfil route without the hassle and risk of them having to set up their own infrastructure.
Back in the day you could have stood up something like this and worried about abuse later. Unfortunately, now, a decent proportion early users of services like this do tend to be those looking to misuse it.
I'm not who you asked, but essentially, when you write malware that infects someone's PC, that in itself doesn't really help you much. You usually want to get out passwords and other data that you might have stolen.
This is where an exfil (exfiltration) route is needed. You could just send the data to a server you own, but you have to make sure that there are fallbacks once that one gets taken down. You also need to ensure that your exfiltration won't be noticed by a firewall and blocked.
Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
> Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
A permanent SSH connection is not exactly discreet, though...
That's actually a fair defence against this kind of abuse. If the attacker has to get some information (the tunnel ID) out of the victim's machine before they can abuse this service, then it is less useful to them because getting the tunnel ID out is about as hard as just getting the actual data out.
However, if "No signup required for random subdomains" implies that stable subdomains can be obtained with a signup, then the bad guys are just going to sign up.
I've seen lots of weird tricks malware authors use, people are creative. My favorite is that they'd load up a text file with a modified base64 table from Dropbox which points to the URL to exfiltrate to. When you report it to Dropbox, they typically ignore the report because it just seems like random nonsense instead of being actually malicious.
Not that you'd usually need this if you have IPv6 but might still be useful to bypass firewalls or forward access for IPv4 clients from your newer IPv6-only resources.
I can't promise anything this is a pet project. I might turn it into an open source project, and I might also provide some kind of service for a few bucks if it gets traction.
Good luck with your future mim data sniffing or selective takeovers, I guess? Not sure what the business model would be, unless you’re planning on injecting ads, which would be funny.
Unless the author is insanely rich, they probably don't want to spend increasingly large amounts on hosting unless they have a way to make money back (even if it's just to break even).
That is wrong (and I need to update any docs that mention this), the traffic is not encrypted end to end, we do TLS termination on our side. From that point on traffic is forwarded back as plain HTTP. However I would in any case not suggest to host any production applications using this service. It is mostly for local dev testing.
If you’re in the EU or have users in the EU, that distinction matters, and you should be more precise. You likely have a solid legitimate use case for collecting IPs under the GDPR, but only if you’re fully transparent.
On the VPS we use:
- 80 (standard http)
- 443 (standard https)
- 22 (obv for standard ssh)
- 9090 (metrics / internal so I can have an idea of the generic usage like reqs/s and active connections)
Client-Side: The -R 80:localhost:8080 Explained
The 80 in -R 80:localhost:8080 is not a real port on the server. It's a virtual bind port that tells the SSH client what port to "pretend" it's listening on.
No port conflicts - The server doesn't actually bind to port 80 per tunnel. Each tunnel gets an internal listener on 127.0.0.1:random (ephemeral port). The 80 is just metadata passed in the SSH forwarded-tcpip channel. All public traffic comes through single port 443 (HTTPS), routed by subdomain.
So What Ports Are "Available" to Users?
Any port - because it doesn't matter! Users can specify any port in -R:
ssh -t -R 80:localhost:3000 proxy.tunnl.gg # Works
ssh -t -R 8080:localhost:3000 proxy.tunnl.gg # Also works
ssh -t -R 3000:localhost:3000 proxy.tunnl.gg # Also works
ssh -t -R 1:localhost:3000 proxy.tunnl.gg # Even this works!
The number is just passed to the SSH client so it knows which forwarded-tcpip requests to accept. The actual routing is done by subdomain, not port.
Why Use 80 Convention?
It's just convention - many SSH clients expect port 80 for HTTP forwarding. But functionally, any number works because:
- Server extracts BindPort from the SSH request
- Stores it in the tunnel struct
- Sends it back in forwarded-tcpip channel payload
- Client matches on this to forward to correct local port
- The "magic" is that all 1000 possible tunnels share the same public ports (22, 80, 443) and are differentiated by subdomain.
This is nice and for those who's asking, it's different from ngrok and the others in that you don't need a separate client, (almost) everyone has ssh installed.
To the author, I wish you best of luck with this but be aware (if you aren't) this will attract all kind of bad and malicious users who want nothing more than a "clean" IP to funnel their badness through.
serveo.net [2] tried it 8 years ago, but when I wanted to use it I at some point I found it was no longer working, as I remember the author said there was too much abuse for him to maintain it as a free service
I ended up self-hosting sish https://docs.ssi.sh instead.
Even the the ones where you have to register like cloudflare tunnels and ngrok are full of malware, which is not a risk to you as a user but means they are often blocked.
Also a little rant, tailscale has their own one also called funnel. It has the benefit of being end-to-end encrypted (in theory) but the downside that you are announcing your service to the world through the certificate transparency logs. So your little dev project will have bots hammering on it (and trying to take your .git folder) within seconds from you activating the funnel. So make sure your little project is ready for the internet with auth and has nothing sensitive at guessable paths.
[2] https://news.ycombinator.com/item?id=14842951
A few other options as well: https://github.com/anderspitman/awesome-tunneling
Thanks for the kind words. I hope I won't have to close this service in a few days due to abuse but its a weird world we live in.
As someone who has launched something free on HN before, the resulting signups were around 1/3rd valid users doing cool things and checking things out, and 2/3rds nefarious users.
a bit better benevolent:malicious ratio than the real world
Dare I ask how much bandwidth it is consuming?
Do you have funding to cover the paying the bandwidth costs which will ultimately result from this? Or if you're running this from a home network, does anyone know if OP should be concerned of running into issues with their ISP?
It would be nice to have an open-source version that you can self-host. That would solve the abuse problem. Maybe with a service to create API keys.
Yeah, this is the next step. I first wanted to understand if this gets any traction. I think I will provide a dockerized version for the server part that you can just run with a simple command and maybe some interface to create api keys and distribute them to your users.
Fair enough from a business standpoint, but seeing as there are massive privacy/security risks involved in exposing your data to an opaque service, the open source component is probably a non-optional aspect of the value prop.
We're using pgrok for that in our organization. A small EC2 instance serves as the public endpoint.
If you keep this up you'll want to add yourself to the public suffix list:
https://publicsuffix.org/
You should also consider grouping your random hostnames under a dedicated subdomain. e.g. "xxx-xxx-xxx.users.tunnl.gg", that separates out cookies and suchlike.
I run a similar site (https://pico.sh) with public urls and thought the same thing for us. The public suffix has some fuzzy limits on usage size before they will add domains (e.g. on the scale of thousands of active users).
I don’t have tunnl.gg usage numbers but I’m going to guess they are no where near the threshold — we were also rejected.
I just want to say that I love pico.sh <3
much appreciated!
"We cooperate with law enforcement agencies when required by law. While we do not inspect traffic content, we will provide connection logs and IP address information in response to valid legal process (such as a subpoena or court order) to assist in investigations regarding illegal activity."
https://tunnl.gg/assets/index-Bjpn0hFX.js
If the requesting party knows it's possible they might ask for traffic to be logged
I used ngrok when it was the to-go answer for serving localhost (temporarily, not permanent) to the public, but the last time I searched for alternatives I stumbled upon the following jewel.
I've tailscale installed on my machine anyway for some connected devices. But even without this would convince me using it, because it's part of the free tier, dead simple and with tailscale it's coming from kind of a trusted entity.I am also using tailscale for a few projects as well. Feel free to use whatever you trust more or works for you.
Hey, I didn't mean to sell another tool over yours! It's just an experience that popped into my mind and I wanted to share. I appreciate your work and contributing to the problem space of exposing a local service. Thank you.
This is a great idea but I'm a bit concerned about your bandwidth costs and illegal/malicious content being hosted used under your domain.
For the second point, you might want to implement some kind of browser warning similar to what Ngrok does.
Thats a fair point, there are some protections in place for abuse already. I will have a look at what ngrok does for browser warnings. Thanks a lot for the suggestions.
Be aware of threat actors, too: you're giving them an easy data exfil route without the hassle and risk of them having to set up their own infrastructure.
Back in the day you could have stood up something like this and worried about abuse later. Unfortunately, now, a decent proportion early users of services like this do tend to be those looking to misuse it.
What's a "data exfil route"?
I'm not who you asked, but essentially, when you write malware that infects someone's PC, that in itself doesn't really help you much. You usually want to get out passwords and other data that you might have stolen.
This is where an exfil (exfiltration) route is needed. You could just send the data to a server you own, but you have to make sure that there are fallbacks once that one gets taken down. You also need to ensure that your exfiltration won't be noticed by a firewall and blocked.
Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
> Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
A permanent SSH connection is not exactly discreet, though...
Thanks!
Though the public address is going to be random here so how will the hacker figure out which tunnl.gg subdomain to gobble up?
That's actually a fair defence against this kind of abuse. If the attacker has to get some information (the tunnel ID) out of the victim's machine before they can abuse this service, then it is less useful to them because getting the tunnel ID out is about as hard as just getting the actual data out.
However, if "No signup required for random subdomains" implies that stable subdomains can be obtained with a signup, then the bad guys are just going to sign up.
I've seen lots of weird tricks malware authors use, people are creative. My favorite is that they'd load up a text file with a modified base64 table from Dropbox which points to the URL to exfiltrate to. When you report it to Dropbox, they typically ignore the report because it just seems like random nonsense instead of being actually malicious.
Is this any different from localtunnel? Nice thing about that one is that its oss, actually we forked it in my company to do some more custom stuff.
Any plan to make it oss?
https://github.com/desplega-ai/localtunnel-server
I am actually thinking about making it open source yes, probably after I adjust the code a little bit :D maybe today or in a couple of days.
Shell function;
``` tunnl() { if [ -z "$1" ]; then echo "Usage: tunnl <local-port>" return 1 fi
} ```There's also https://tunnelmole.com but requires binary or npm install
How do the Certs work for https?
I'd assume it uses a single wildcard certificate.
How is it different to ngrok? Genuinely curious, I might switch.
Not really that different, besides any kind of time limitations or number of request limitations.
Built another localhost tunneling tool because I kept forgetting my ngrok auth token.
What it does:
- Expose localhost to the internet (HTTP/TCP/WebSockets) - Zero signup – just works immediately - Free
Nothing groundbreaking, just scratching my own itch for a no-friction tunnel service. Written in Go.
Link: https://tunnl.gg
Happy to answer questions or hear how you'd improve it.
Seemingly lacking IPv6 support?
Not that you'd usually need this if you have IPv6 but might still be useful to bypass firewalls or forward access for IPv4 clients from your newer IPv6-only resources.
Indeed there is no IPv6 support yet.
How are you able to host it for free?
I am paying for it out of pocket. Its free for you to use, but not for me to host it :)
The question is, how is it sustainable? Nobody likes being rug pulled. Why not charge money for it?
I'd rather pay a few dollars for a service that will be around 5 years from now, than pay nothing and have to deal with churn.
I can't promise anything this is a pet project. I might turn it into an open source project, and I might also provide some kind of service for a few bucks if it gets traction.
Good luck with your future mim data sniffing or selective takeovers, I guess? Not sure what the business model would be, unless you’re planning on injecting ads, which would be funny.
Why does everything have to be a business model?
Unless the author is insanely rich, they probably don't want to spend increasingly large amounts on hosting unless they have a way to make money back (even if it's just to break even).
I am not rich and I don't need to be to keep this service up and running at least for the near future.
To keep this up and running for 2-3 years, you probably do need to be rich, or to find a way to monetize.
It's possible when it gets to be a drain, even charging pennies for the service could drive off the bad actors making it unsustainable though.
For the foreseeable future and unless there is massive abuse, which I am trying to contain, it will remain free.
...", Russian FSB manager, 2025
Thanks, but I don't have such plans, lol.
You are mentioning it's encrypted end-to-end; please explain how your server is unable to read the contents of the stream?
That is wrong (and I need to update any docs that mention this), the traffic is not encrypted end to end, we do TLS termination on our side. From that point on traffic is forwarded back as plain HTTP. However I would in any case not suggest to host any production applications using this service. It is mostly for local dev testing.
Why not just buy trial or cheap VM? Are devs that lazy now? Or is this aimed on vibe "devs"? :D
To some people (students, people in low income countries) there are no cheap hosted VMs.
Love the approach, simplicity and concept. SPA works fine if entry point is / if /terms /privacy greated with 404.
Hey, thanks for the comment. I am having a look with my own apps and it seems to work with pages and nextjs middleware as well.
I have used serveo.net in the past for the same use case, this looks cool !
It's bit less convenient, but I have access to a vps and a dns with a custom domain.
I can create any subdomain I want and tunnel the connexion to any port on my computer.
=> I can spinup a new subdomain in seconds, no data leakage, url that doesn't change, and it's cost nothing.
Whatever works for you best :)
How does this compare to cloudflare or even a self-hosted tailscale tunnel?
Also do you collect any data? Privacy says
> We do not collect, store, or sell your personal data.
But I guess personal data is a bit ambiguous. You're at the very least collecting my IP (which is fine, I'm just curious)
Yes that is true (the IP is collected), what I meant is that we don't explicitly collect data on purpose.
If you’re in the EU or have users in the EU, that distinction matters, and you should be more precise. You likely have a solid legitimate use case for collecting IPs under the GDPR, but only if you’re fully transparent.
I updated the terms, thanks for the heads up.
Interesting! How do you handle port conflicts? What ports for public exposure are available?
On the VPS we use: - 80 (standard http) - 443 (standard https) - 22 (obv for standard ssh) - 9090 (metrics / internal so I can have an idea of the generic usage like reqs/s and active connections)
Client-Side: The -R 80:localhost:8080 Explained The 80 in -R 80:localhost:8080 is not a real port on the server. It's a virtual bind port that tells the SSH client what port to "pretend" it's listening on.
No port conflicts - The server doesn't actually bind to port 80 per tunnel. Each tunnel gets an internal listener on 127.0.0.1:random (ephemeral port). The 80 is just metadata passed in the SSH forwarded-tcpip channel. All public traffic comes through single port 443 (HTTPS), routed by subdomain.
So What Ports Are "Available" to Users?
Any port - because it doesn't matter! Users can specify any port in -R: ssh -t -R 80:localhost:3000 proxy.tunnl.gg # Works ssh -t -R 8080:localhost:3000 proxy.tunnl.gg # Also works ssh -t -R 3000:localhost:3000 proxy.tunnl.gg # Also works ssh -t -R 1:localhost:3000 proxy.tunnl.gg # Even this works!
The number is just passed to the SSH client so it knows which forwarded-tcpip requests to accept. The actual routing is done by subdomain, not port.
Why Use 80 Convention?
It's just convention - many SSH clients expect port 80 for HTTP forwarding. But functionally, any number works because:
- Server extracts BindPort from the SSH request - Stores it in the tunnel struct - Sends it back in forwarded-tcpip channel payload - Client matches on this to forward to correct local port - The "magic" is that all 1000 possible tunnels share the same public ports (22, 80, 443) and are differentiated by subdomain.
Nicely done! Thanks for the detailed answer ;)
Curious about this as well.
That's really cool. I guess this is an alternative to ngrok (which I like but hate due to having to sign in).
Yes, its free to use and does not require any clients (but you need to have ssh client installed)
Not many people know that you can use cloudflare tunnels without signing up.
I sure did not! How would that work? Manually pointing the domain as a CNAME to the tunnel ID? But how would one get that ID without signing up?
I have a demo with working GitHub runner workflow code here: https://github.com/BrowserBox/ariadne
Specifically: https://github.com/BrowserBox/ariadne/blob/f07e3b0d445f5d4a8...