An ngrok Alternative That Gives You a Real IP
ngrok is the best tool there is for putting a laptop on the internet for twenty minutes. It is the wrong tool for something that has to still be there in a year. Here is what actually replaces it — including three replacements that cost nothing.
What ngrok is genuinely good at
It is worth being clear about this before criticising it, because most articles with this title are dishonest about the tool they are replacing.
If you are testing an OAuth callback, a Stripe webhook, or a Slack slash command against code running on your own machine, ngrok is the fastest path in existence from "my server is on localhost" to "a public URL that reaches it". One command, no account required to start, a TLS certificate you did not have to think about, and a request inspector that lets you replay the webhook you just fumbled instead of triggering it again from the vendor's dashboard. Nothing on this page is faster for that job, including us.
The problem is not ngrok. The problem is that people reach for it for development, it works, and then the thing they built quietly becomes permanent.
How it works, so the limits make sense
The mechanism is the same one every tunnel service uses. An agent on your machine opens an outbound connection to ngrok's edge and holds it open. Because your machine initiated it, your router's NAT — and your ISP's, if you are behind CGNAT — both have a mapping for it, so return traffic is allowed back. When a request arrives at the public URL, ngrok's edge accepts it, wraps it up, and sends it back down the connection your agent already established. Your machine never has to accept an unsolicited inbound packet, which is exactly why it works from behind a router you do not control.
Everything that follows is a consequence of that shape. The connection terminates at ngrok, not at you. TLS is decrypted there. The client's connection is to their infrastructure, and what reaches you is a relayed copy.
The three things that make it wrong for production
The URL is not yours. On the free tier you get a random subdomain that changes when the agent restarts, which is fine for an afternoon and fatal for anything a third party has stored. Paid plans give you a reserved domain, which fixes it — but the domain still lives inside their namespace unless you bring your own, and the whole thing stops the day the subscription does.
The address the world sees is theirs. This is the one that bites unexpectedly. Any connection to your service arrives at ngrok's edge, so as far as the rest of the internet is concerned your service lives at an ngrok address, shared with every other tunnel on that edge. You cannot hand it to a vendor to allowlist. You cannot set reverse DNS on it. You cannot put it in an SPF record. And if something else behind that edge behaves badly, the reputation attached to the address moves without you doing anything.
It is shaped around HTTP. ngrok can carry raw TCP, but the product, the pricing and the tooling are all built around web traffic. If what you are exposing is a game server, a DNS resolver, a mail submission port or a bare TCP protocol, you are pushing against the grain of the tool for the whole life of the deployment.
What to replace it with
Keep paying ngrok
Genuinely the right answer more often than the rest of this list. If your thing is HTTP, a hostname is acceptable, and a reserved domain solves your instability, then upgrading is the cheapest possible fix measured in hours of your life. Switching tools to save a few dollars a month is a bad trade if the tool fits.
Cloudflare Tunnel, if it is HTTP and you have a domain
Free, and for web traffic it is a straight upgrade on ngrok's free tier: the hostname is on your domain, the TLS certificate is issued for your name, and you inherit caching and DDoS absorption on the way through. Same tunnel mechanism, so it works from behind CGNAT identically. The longer comparison is here, including where it stops fitting.
Tailscale, if the audience is your own devices
If the things connecting to your service are your laptop, your phone and a box at a friend's house, you do not need a public URL at all and should not have one. A private mesh gives every device a stable address on a network only your devices can join, and nothing is exposed to the internet. Free at that scale, and a security posture no public tunnel can match. Where its public-facing mode stops being enough is here.
Self-host the tunnel
ngrok's mechanism is not proprietary. Rent a small VPS, put frp, rathole or plain ssh -R on it, and you have the same architecture with a public address that belongs to your rental. This carries arbitrary TCP and UDP, costs a few dollars a month, and nobody can change the terms on you.
What it costs is not the rental. You now run an internet-facing machine: patches, a firewall you wrote, keys to rotate, and a forwarding configuration you will have to re-derive in a year when it breaks at an inconvenient moment. Plenty of people consider that a fair trade, and they are not wrong.
A routed address
The last option changes what arrives rather than where it terminates. Instead of a provider relaying requests to you, a network assigns you one of its own public addresses, announces it to the internet by BGP, and routes the traffic for it down a tunnel to your machine. Your machine still dials out, so it works from behind CGNAT for exactly the same reason ngrok does — but the far end is a whole address rather than a hostname, and connections reach you rather than terminating at somebody's edge.
When you actually need an address
The honest test is whether anything in your system refers to you by address rather than by name.
A vendor allowlist does. Corporate firewalls do. SPF records do. Game server browsers do. Reverse DNS does, by definition. If a partner has ever said "send us the IP you'll be calling from" or "we'll open our firewall to your address", a tunnel with somebody else's shared edge address cannot satisfy that request, and no amount of paying for a nicer hostname will change it.
The second test is protocol. If it is not HTTP and never will be, the HTTP-shaped tools are a permanent tax.
If neither test trips, you do not need an address, and one of the free options above is a better use of your money than anything we sell.
Where TunnelNet fits
We lease one public IPv4 address out of our own 23.187.152.0/24, announced by BGP from AS396500, and route it to a machine you already own — Linux, WSL, macOS, Windows, or a phone. It is $10 per month for one address, an IPv6 /56 comes with it, and setup is a token from your dashboard and a single install command. We announce from two US cities, Chicago and Newark, on anycast, so traffic reaches you through whichever is closer. SSH is open by default; everything else stays closed until you open a port, and that is enforced at our edge rather than on your machine. Unlike a relay, connections arrive at an address that is yours — you can give it to a vendor, and you are the only person behind it.
The limits, up front. The base plan is inbound only; your outbound traffic still leaves via your ISP unless you take the $20 plan. Outbound port 25 is blocked, so this is not a way to run a mail server. Failover between our two hubs is automatic but takes minutes, not seconds, because the WireGuard rekey dominates recovery — if you need sub-second failover, we are not it. And we publish no availability figure, because we have not run long enough to have measured one, and inventing a number would be worse than saying so.
It is also not a VPN and not anonymity — the address is permanently and deliberately attributable to you. If what you actually needed was a nicer hostname, go and pay ngrok or use Cloudflare Tunnel; both are better at that than we are. If you need the address itself, the plans are here.