DEV Community: InstaTunnel

Funnels vs. Tunnels: Rethinking ngrok, Tailscale, and Cloudflare for Zero-Trust Infrastructure

InstaTunnel — Mon, 27 Jul 2026 04:54:36 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
Funnels vs. Tunnels: Rethinking ngrok, Tailscale, and Cloudflare for Zero-Trust Infrastructure
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

Funnels vs Tunnels: Replacing ngrok with Tailscale Funnel: quick comparison answer
Choose the tunnel tool based on the network model: public HTTPS URLs for webhooks and demos, private mesh access for internal apps, and managed infrastructure when policy controls matter most.

Which tunnel tool is best for public webhook testing?
Use a public HTTPS localhost tunnel with stable URLs. InstaTunnel focuses on webhook testing, demos, OAuth callbacks, and MCP endpoint workflows.

When should I choose a private network tool instead?
Choose a private mesh or Zero Trust tool when every user and service should stay inside a controlled private network.

For years, tools like ngrok were the default answer to “how do I get this local server on the internet.” Run one command, get a public HTTPS URL, done. That convenience is real, but it comes with a tradeoff that platform and security teams have grown less comfortable with: a classic tunnel creates a public, unauthenticated endpoint the moment it’s live.

The alternative gaining ground is identity-based mesh networking — private overlay networks like Tailscale, with narrow, audited “funnel” mechanisms for the rare cases that genuinely need public access. This isn’t really a story of one tool replacing another; it’s two different answers to two different questions. ngrok answers “how do I expose this to anyone on the internet?” Tailscale answers “how do I connect my team’s devices without exposing anything?” Funnel features exist precisely because real teams need both answers, sometimes in the same afternoon.

How Traditional Tunneling Actually Works A tool like ngrok runs a lightweight agent on your machine that opens an outbound connection to ngrok’s cloud edge. That cloud edge hands back a public URL, and any request to that URL gets routed back down the tunnel to your local port. ngrok http 8080 and you’re live in seconds — that ease of use hasn’t changed.

The architecture is service-centric: reaching the URL is the access control. There’s no identity check built into the tunnel itself unless you add one. That has a few practical consequences for teams:

It bypasses the firewall by design. That’s the point of a tunnel — but it also means an unsanctioned tunnel is an unmonitored path into the network.
Random-looking URLs aren’t a security boundary. They’re guessable-by-scanner over time, and if the backing service has no auth of its own, whoever finds the URL has access to it.
It can quietly become Shadow IT. Data flowing through a tunnel a security team doesn’t know about complicates SOC 2, HIPAA, or GDPR compliance conversations.
None of this makes ngrok unsafe to use — it makes it a tool best pointed outward (public demos, customer webhooks) rather than inward (internal staging environments, teammate-to-teammate sharing).

The Zero-Trust Shift: Identity-Based Mesh Networking Mesh networking tools like Tailscale take the opposite default. Instead of a public URL that anyone can hit, every device authenticates (usually via your SSO provider) and joins a private overlay network — a “tailnet.” Devices talk to each other over WireGuard, and a device that isn’t authenticated to the tailnet can’t resolve or reach anything on it, let alone see that a service exists.

One nuance worth being precise about: Tailscale traffic is peer-to-peer when NAT traversal succeeds, but it isn’t always a direct hop. When two devices can’t establish a direct path (common behind restrictive NATs or corporate firewalls), Tailscale falls back to its own relay infrastructure — DERP servers — to carry the encrypted traffic. The payload stays end-to-end encrypted either way, but “never touches a centralized server” is a slight overstatement of how the network behaves in practice.

The core value proposition holds regardless: access means tailnet membership, not URL-guessing, and every connection is tied to an authenticated identity rather than an anonymous request.

Tailscale Funnel vs. ngrok: Two Architectures, Two Philosophies ngrok is built for the case where you want the public internet to reach your service — webhook testing, demoing to someone without a VPN client, or accepting inbound connections from customer environments. Its traffic inspector, request replay, and Traffic Policy engine (its programmable rules layer for auth, rewriting, and rate limiting) remain genuinely strong for debugging live API traffic.

Tailscale starts from the opposite premise: private by default, and it’s fundamentally a device-to-device mesh, not a public ingress tool.

Funnel is Tailscale’s answer to the occasional need to cross that boundary: a feature that routes public internet traffic to a specific node on your tailnet. A few things worth knowing if you’re actually going to use it in production:

It’s still a beta feature. As of Tailscale’s own documentation in early 2026, Funnel remains labeled beta — usable and reasonably mature, but without a formal support SLA behind it. Worth flagging to a security team before treating it as a permanent piece of infrastructure.
Ports are hard-restricted. Funnel only listens on 443, 8443, or 10000, and only over TLS. This isn’t a soft default — it’s enforced. Tailscale automatically provisions the TLS certificate for your *.ts.net name.
Bandwidth is capped, and the cap isn’t published. Tailscale describes Funnel traffic as subject to non-configurable bandwidth limits, without stating the number.
The same port can’t run Serve and Funnel at once. Whichever command touched the port last wins — configure it as serve and it’s tailnet-only; configure it as funnel and it’s public. There’s no accidental in-between state.
ngrok has no equivalent port restriction. It supports arbitrary TCP/UDP traffic on essentially any port, which is exactly why it (or specialists in UDP tunneling for gaming/VoIP traffic) still wins for anything outside HTTPS.

Zero-Trust Localhost Sharing: A Practical Workflow Say a frontend developer needs to share localhost:3000 with a QA tester and a PM.

The old way: ngrok http 3000, then paste the URL into Slack. If someone forgets to close the terminal, that URL — and whatever’s running behind it — stays reachable by anyone who finds it, all weekend if need be. (For what it’s worth, ngrok’s free tier doesn’t actually force-close sessions after a fixed time the way it’s often described online — more on that misconception in a moment. The bigger risk here isn’t a timeout, it’s that nothing closes the door for you.)

The zero-trust way, with current CLI syntax: Tailscale changed its Serve/Funnel command syntax in client version 1.52 — older tutorials showing tailscale serve --port 3000 are using the pre-1.52 syntax and will either fail or get auto-translated with a deprecation notice. The current syntax looks like this:

tailscale serve https / http://localhost:3000
This binds the local app to the developer’s own tailnet address (something like https://dev-laptop.tailnet-name.ts.net) — visible only to devices authenticated into that tailnet. Traffic is WireGuard-encrypted end to end, and Tailscale can pass along identity headers so the receiving app knows who’s connecting, without you building an auth layer for internal sharing.

If an external client without Tailscale installed genuinely needs in, you elevate the same port to public:

tailscale funnel 443 on
Now it’s reachable from the open internet on a Tailscale-managed HTTPS endpoint — deliberately, on a fixed port, with a record of the fact that someone turned it on.

Cloudflare Tunnel: The Other Funnel Alternative Cloudflare Tunnel (part of the broader Cloudflare One / Cloudflare Zero Trust platform, which also bundles Access, a Secure Web Gateway, DLP, Remote Browser Isolation, CASB, and email security under one control plane) takes a third approach: instead of a peer mesh, it routes through Cloudflare’s global edge. The cloudflared daemon runs on your machine or server and opens an outbound-only connection to the nearest Cloudflare data center — no inbound ports, ever. Put Cloudflare Access in front of the tunnel and visitors have to authenticate via SSO before they reach your origin at all.

A couple of things have actually changed here recently, worth knowing if you’re running cloudflared today: Cloudflare pulled the proxy-dns command from new cloudflared releases in February 2026 to patch a vulnerability in an underlying DNS library — if you were using it as a DNS-over-HTTPS resolver (a common Pi-hole pairing), that specific use case needs a different tool now; the core tunneling functionality itself wasn’t affected. Separately, Cloudflare has scheduled an API cleanup for October 2026 that drops CIDR-encoded route identifiers and the connections field from Tunnel/Mesh API responses in favor of plain route_id values — relevant if you manage tunnel routes via Terraform or the API rather than the dashboard.

The rough split in practice: Cloudflare Tunnel tends to win for publishing internal apps to a distributed workforce that’s already behind Cloudflare Access; Tailscale tends to win for developer-to-developer and homelab connectivity where true peer-to-peer, low-latency WireGuard matters more than a centralized edge.

Building Secure Team Infrastructure: What Actually Changed in 2026 If you’re planning this migration, a few facts worth building your plan around, because they shifted this year:

SCIM is no longer an enterprise-only feature. Tailscale’s April 2026 pricing overhaul (“pricing v4”) moved automated user provisioning via SCIM, device posture policies, and webhooks down into all paid self-serve plans — previously SCIM required an Enterprise contract. The current tiers are Personal (free, up to 6 users), Standard ($8/user/month), Premium ($18/user/month, adds SSO/SAML, network flow logs, and Funnel among other things), and custom Enterprise pricing. If your last cost estimate for this migration assumed enterprise pricing just to get SCIM working, it’s worth re-checking.

Configuration audit logs are now included on every paid plan too, not gated to the top tier — useful when you’re building the “who turned on Funnel and when” audit trail platform teams actually want.

With that in mind, the rollout shape stays roughly the same:

Deploy the mesh client across workstations, CI/CD runners, and staging servers, wired into your IdP via SSO and SCIM for automatic provisioning/deprovisioning.
Turn on MagicDNS so people reach each other by name instead of IP, and write ACLs so access is scoped by team — frontend can hit staging, only platform can SSH into prod.
Push tunneling traffic to Serve by default, and gate Funnel behind an explicit node attribute in your ACL policy so turning on public exposure requires a deliberate, logged action rather than a developer just running a binary.
Stream flow logs and audit logs to your SIEM so the visibility that ngrok can’t give you (an unmonitored process on someone’s laptop) becomes the default instead of the exception.

When ngrok Is Still the Right Tool This isn’t really a zero-sum comparison, and it’s worth being fair about where ngrok still wins outright:

Cross-organizational connectivity. If your SaaS product needs to reach into a customer’s network, you can’t ask that customer to join your tailnet. Service-centric tunneling is built for exactly this.
Deep traffic inspection. ngrok’s request replay and inspector are still ahead of what mesh tools offer for debugging live webhook or API traffic.
Non-HTTPS, non-TCP protocols. Funnel is HTTPS-only on three fixed ports. If you need public UDP — a game server, VoIP, some IoT protocols — ngrok (or a UDP-specialized alternative) is the tool, not Funnel.
And for the record: the “ngrok free tier times out after 2 hours” claim that circulates widely online is not accurate as of ngrok’s current documentation — the free tier has no session timeout at all; endpoints stay up as long as the process runs, even as a background service. What the free tier does enforce is a 1 GB/month data cap, a hard limit of 3 online endpoints, a mandatory click-through interstitial warning page on browser traffic (bypassable with an ngrok-skip-browser-warning header for API/programmatic use), and no custom domains. Those are real limitations — the 2-hour timeout specifically just isn’t one of them.

A Reality Check: Zero-Trust Isn’t Magically Invulnerable Either It’s tempting to write this comparison as “public tunnels bad, private mesh good” and stop there. Worth resisting that a little. In May 2026, Tailscale’s own security bulletins disclosed a denial-of-service bug (tracked as TS-2026-008) affecting both Serve and Funnel: a malformed HTTP request with a path that didn’t start with / could send the request-matching logic into an infinite loop, pinning a CPU core at 100% indefinitely. It shipped with no timeout to interrupt the spin. Tailscale patched it by making the path-matching logic terminate correctly.

None of that undermines the architectural argument for identity-based access — a DoS bug in the ingress layer is a different failure mode than “anyone who finds this URL gets in,” and Tailscale’s own disclosure process is exactly the kind of transparency you’d want from infrastructure you’re trusting with internal traffic. But it’s a useful reminder that “zero-trust” describes an access model, not immunity from bugs. Whatever ingress layer you choose still needs patching, monitoring, and a plan for when something in it breaks.

Conclusion
The shift from tunnels to funnels is really a shift in what “convenient” means for a team: from “fastest way to get something public” to “fastest way to get something to the right people, with a record of it.” ngrok remains the right call when the point is public exposure — customer connectivity, webhook testing, demoing to someone with no VPN client. Tailscale (or Cloudflare Tunnel, depending on whether your priority is peer-to-peer mesh or a centralized edge) is the better default for everything that’s actually internal.

The practical move isn’t banning one tool for the other — it’s making private-by-default the norm, and treating public exposure as a deliberate, logged exception rather than a habit.

Changelog
Structural changes: - Removed SEO metadata, repeated bolded keyword phrases, and the pseudo-citation reference list from the original draft; rewritten in plain prose. - Added a new section (§8) on Tailscale’s own May 2026 Serve/Funnel DoS disclosure, for balance — the original draft didn’t address that zero-trust tooling has its own vulnerability history.

Corrections against primary sources: - Debunked the “ngrok free tier times out after 2 hours” claim — confirmed via ngrok’s current docs that the free tier has no session timeout; the real free-tier limits are 1 GB/month transfer, 3 online endpoints, and the browser interstitial. - Updated ngrok’s plan structure — current self-serve tiers are Free / Hobbyist ($8–10/mo) / Pay-as-you-go ($20/mo + usage) / Enterprise, replacing the outdated “Personal/Pro/Enterprise” naming and pricing in the draft. - Corrected Tailscale CLI syntax — the draft used pre-1.52 command syntax (tailscale serve --port 3000, tailscale funnel 3000); replaced with the current syntax (tailscale serve https / http://localhost:3000, tailscale funnel 443 on). - Corrected Tailscale’s SCIM/audit-log gating — SCIM, device posture, webhooks, and configuration audit logs moved from Enterprise-only to all paid plans under Tailscale’s April 2026 “pricing v4” update; also updated plan names/prices (Personal free/6 users, Standard $8, Premium $18, Enterprise custom). - Flagged that Tailscale Funnel is still a beta feature as of early 2026 documentation — the original draft implied a more finished/GA feature. - Added the DERP relay nuance — Tailscale traffic isn’t always strictly peer-to-peer; it falls back to Tailscale’s relay servers when direct NAT traversal fails, while remaining end-to-end encrypted. - Added Cloudflare Tunnel’s 2026 changes — the proxy-dns command removal (Feb 2026) and the scheduled October 2026 Tunnel/Mesh API cleanup, both absent from the original draft. - Confirmed as accurate: Funnel’s port restrictions (443/8443/10000, TLS-only), its undisclosed/non-configurable bandwidth cap, and the “last command wins” behavior when Serve and Funnel target the same port.

Sources checked: ngrok documentation (pricing-limits, pricing page), Tailscale documentation (Funnel, Serve, CLI reference, security bulletins, pricing v4 announcement), Cloudflare One / Cloudflare Tunnel documentation and changelog.

Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
InstaTunnel vs Cloudflare Tunnel
Compare quick public localhost tunnels with Cloudflare-managed private access workflows.
InstaTunnel vs Tailscale
Compare public HTTPS tunnel URLs with private mesh networking for remote development.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
Related Topics

Tailscale Funnel vs ngrok, ngrok vs Tailscale, funnels vs tunnels, Tailscale Funnel, Cloudflare Zero Trust, Cloudflare Tunnel vs ngrok, ngrok alternative, best ngrok alternative, enterprise ngrok alternative, secure ngrok alternative, zero trust localhost sharing, zero trust tunneling, zero trust network access, ZTNA tools, private mesh network exposure, identity based mesh networking, secure team infrastructure, tailscale serve vs tailscale funnel, expose localhost securely, secure local server sharing, replace ngrok with tailscale, wireguard mesh network, tailnet public exposure, ngrok security risks, public endpoint vulnerabilities, identity aware proxy, authenticated tunnel, devops infrastructure security, platform engineering security, secure developer access, internal developer platform tools, tailscale funnel setup, tailscale funnel tutorial, encrypted localhost tunnel, secure webhook endpoint, private network tunneling, self hosted zero trust, cloudflared tunnel vs tailscale, zero trust access control, secure reverse proxy, identity based access control, tailscale node exposure, secure API gateway local, developer network security, mesh vpn localhost, tailscale pricing vs ngrok, zero trust dev tools 2026, lock down developer infrastructure, secure port forwarding alternative, tailscale tunnel security, zero trust localhost proxy, private mesh network access

Why Developers Are Ditching Tunneling Binaries for Native SSH

InstaTunnel — Sun, 26 Jul 2026 07:48:27 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
Why Developers Are Ditching Tunneling Binaries for Native SSH
Quick answer

Why Developers Are Ditching Tunneling Binaries for NativeSSH: quick comparison answer
Choose the tunnel tool based on the network model: public HTTPS URLs for webhooks and demos, private mesh access for internal apps, and managed infrastructure when policy controls matter most.

Which tunnel tool is best for public webhook testing?
Use a public HTTPS localhost tunnel with stable URLs. InstaTunnel focuses on webhook testing, demos, OAuth callbacks, and MCP endpoint workflows.

When should I choose a private network tool instead?
Choose a private mesh or Zero Trust tool when every user and service should stay inside a controlled private network.

The modern development lifecycle demands speed and the ability to instantly share progress. Whether it’s showcasing a local web app to a client, debugging a Stripe webhook, or demoing something for QA, developers frequently need to expose a local dev server to the public internet. For years, the default answer was to download a standalone binary — most notably ngrok or Cloudflare’s cloudflared — and run it locally to open a tunnel.

That default is getting harder to rely on. As corporate IT departments push Zero Trust architectures and lock down endpoints, unapproved third-party executables are increasingly blocked outright by Endpoint Detection and Response (EDR) tools like Microsoft Defender or CrowdStrike Falcon. In these environments, downloading an arbitrary .exe to open an outbound tunnel isn’t just discouraged — it’s actively prevented.

This friction is why “zero-install” tunneling — using the native ssh command that already ships with macOS, Linux, and modern Windows — has gained real traction. Tools like Pinggy and Serveo let developers get the same localhost exposure without introducing a new binary to the machine at all.

This piece covers why developers are moving this way, how an SSH reverse tunnel actually works, a current Pinggy vs. Serveo comparison, and — importantly — the limits of the “IT will never notice” pitch, because that part is more nuanced than it’s often presented.

The Security Landscape: Why IT Distrusts Third-Party Binaries
In a modern corporate environment, an employee’s laptop isn’t treated as inherently trusted. Zero Trust Network Access (ZTNA) policies mean every binary and outbound connection is subject to scrutiny.

The problem with standalone tunneling tools
When a developer installs ngrok or a similar tool, they introduce a new executable whose core function — punching a hole from inside the network to the public internet — looks identical whether the intent is legitimate or malicious. Security teams and researchers have taken to calling this class of traffic “dark tunnels”: outbound-only, encrypted connections that route around inbound firewall rules and often blind traditional network inspection. If an attacker breaches a network, standing up a tunneling binary is a common early step toward command-and-control persistence or quiet data exfiltration.

Because of that overlap between legitimate developer use and attacker tradecraft, EDR platforms frequently flag known tunneling binaries, and some security teams now ship detection rules that specifically watch for them — for example, published Microsoft Defender KQL queries that alert on processes reaching out to ngrok.io, trycloudflare.com, loca.lt, and similar domains. Depending on how a security team has configured its EDR policy, an unrecognized tunneling executable can be quarantined and generate an alert to the SOC.

The approval bottleneck
Getting a third-party binary whitelisted usually means filing an IT ticket, justifying the need, and waiting on a security review — a process that can take days or weeks and defeats the point of quick local iteration.

What “Zero-Install” Localhost Sharing Actually Means
It’s exactly what it sounds like: exposing a local server to the internet without installing new software, by relying only on tools already present on the OS. The most useful of these is the SSH client.

SSH’s availability on modern operating systems is close to universal, but it’s worth being precise about what “built in” means in practice:

Linux and macOS ship a working ssh client out of the box, no setup required.
Windows is more nuanced. Microsoft has shipped an OpenSSH client as an in-box optional feature since Windows 10 version 1809, and it carries through to Windows 11 and Windows Server 2019/2022/2025. On most of those releases it still needs to be turned on once — via Settings → Optional Features → Add a feature → OpenSSH Client, or Add-WindowsCapability in PowerShell — it isn’t necessarily enabled by default. Windows Server 2025 is the first release where it’s installed out of the box (though still not auto-enabled). In practice, this is a one-time toggle IT can bake into a standard corporate image, which is still far less friction than getting a foreign .exe whitelisted — but it’s not quite the “already there, zero action needed” story sometimes told.
Because ssh.exe / /usr/bin/ssh is a known, signed, IT-approved binary, it’s far less likely to be blocked wholesale than an unfamiliar tunneling executable — which is the real advantage here, distinct from being undetectable (more on that below).

The Mechanics of an SSH Reverse Tunnel
Standard SSH port forwarding sends local traffic to a remote server. A reverse tunnel flips that: the local machine reaches out to an external server and asks it to listen on a port. Traffic that hits that port on the remote server gets funneled backward through the SSH connection to a service running locally (e.g., localhost:3000).

Command breakdown
ssh -R 8080:localhost:3000 user@remote-server.com
ssh — the native SSH client.
-R — requests a reverse tunnel.
8080 — the port opened on the remote server.
localhost:3000 — where traffic is ultimately routed on the local machine.
user@remote-server.com — the server hosting the public endpoint.
Once running, a request to http://remote-server.com:8080 gets passed through the SSH connection down to the local server on port 3000.

Why this is a security win
The local machine only ever makes an outbound connection. Firewalls are built to block unsolicited inbound traffic — which is why you can’t casually host a public server on home Wi-Fi without configuring NAT — but outbound connections on standard ports are almost always allowed. Because the tunnel is initiated from the inside out, it sidesteps NAT traversal problems without any risky router configuration.

Getting Through Restrictive Firewalls
Some tightly locked-down networks block outbound traffic on non-standard ports, including SSH’s default port 22, allowing only 80⁄443. A standard SSH connection would fail there. Modern tunnel providers have adapted: Pinggy, for instance, accepts SSH connections on port 443.

ssh -p 443 -R0:localhost:3000 free.pinggy.io
To a firewall doing basic port-based filtering, this looks like ordinary encrypted HTTPS traffic. Because it’s a trusted native binary making an outbound connection over a standard web port, it typically passes through without raising flags — though see the caveat on deep packet inspection and command-line monitoring below.

Pinggy vs. Serveo
Serveo: the veteran
Serveo popularized SSH-based tunneling without a client download.

ssh -R 80:localhost:3000 serveo.net
Pros: genuinely zero-install; one command to a public URL; custom subdomains without an account.

Cons: Serveo has a long, documented history of instability tied to abuse of its free, unauthenticated service (phishing, malware hosting), which has led to repeated blocks and outages over the years. As of mid-2026, independent uptime monitors generally show the domain reachable, but scattered user reports of regional outages and connection drops are still common — consistent with that history. It also remains barebones: no web-based request inspector, no built-in debugging UI.

Pinggy: the modern alternative
Pinggy was built to address Serveo-style stability issues while expanding the feature set, without giving up the zero-install model.

ssh -p 443 -R0:localhost:3000 free.pinggy.io
Pros, as of 2026: - Port 443 by default for firewall traversal. - Built-in web debugger for inspecting, replaying, and modifying HTTP requests — accessible via a local port without installing anything. - A sustainable freemium model: the free tier gives unlimited-bandwidth HTTP(S)/TCP/UDP/TLS tunnels with a 60-minute session cap and a random subdomain; Pinggy Pro runs $3/month for persistent subdomains, custom domains, and team features — notably cheaper than ngrok’s comparable personal tier. - Broader protocol support: HTTP/HTTPS, TCP, UDP, and TLS tunnels, all via SSH flags. - For teams that want more than raw SSH, Pinggy also now offers an optional CLI binary, a Docker image, and official Node.js and Python SDKs — none of which are required for the core zero-install workflow, but useful if a project wants tunnel management wired into scripts or CI.

Cons: the 60-minute free-tier cap means longer-running demos need either a restart loop or the Pro plan; as a smaller operator than ngrok or Cloudflare, it doesn’t publish a formal SLA.

The verdict
For a quick, disposable test, Serveo’s simplicity still has appeal. For anyone working under real IT constraints who needs firewall-friendly port 443 access, request inspection, and more predictable uptime, Pinggy is the stronger fit in 2026.

Setting Up a Zero-Install Tunnel

Verify SSH is available

ssh -V
On Linux and macOS this just works. On Windows, if this fails, check Settings → Optional Features for “OpenSSH Client” and install it if it isn’t already there — it’s a native Windows component, not a third-party download.

Start your local server — e.g., a Node.js app on port 3000.
Open the tunnel

ssh -p 443 -R0:localhost:3000 free.pinggy.io

Share the HTTPS URL Pinggy prints in the terminal — for a client demo, a Stripe webhook endpoint, or mobile testing.

Pro tip: add a keep-alive flag so brief network drops don’t hang the session:

ssh -p 443 -o ServerAliveInterval=30 -R0:localhost:3000 free.pinggy.io
Beyond Web Servers
Because reverse tunnels operate at the networking layer, they’re not limited to HTTP:

Databases: give a colleague temporary access to a local Postgres instance by tunneling the TCP port directly: bash ssh -p 443 -R0:localhost:5432 tcp@free.pinggy.io (Note: Pinggy routes tunnel type through a keyword prefix on the username — tcp@, tls@, etc. — rather than a separate hostname.) - Remote SSH access: expose port 22 on a Raspberry Pi or IoT device behind strict NAT, letting you SSH in from anywhere without touching the router. — ## The Caveat: “Zero-Install” Doesn’t Mean Invisible It’s worth being straight about this, since it’s the part most write-ups gloss over. The advantage of ssh is that it’s a trusted, signed binary that’s unlikely to be blocked wholesale — not that reverse tunnels are undetectable. Security teams that actively hunt for “dark tunnels” increasingly write detection rules that match on SSH’s own command-line patterns, not just on known tunneling-tool domains — for instance, flagging any ssh.exe process launched with a -R :: argument, regardless of destination. A well-instrumented EDR/SIEM setup can catch an SSH reverse tunnel just as it would catch ngrok, because the command line itself is the tell. The practical takeaway: native SSH tunneling meaningfully reduces the odds of the binary itself being blocked at the door, and it’s genuinely useful for getting past port-based firewall restrictions. But if your organization runs endpoint monitoring with custom detection content, don’t assume the SSH route flies under the radar — it’s best treated as a lower-friction, IT-approved tool, not a way to route around security policy unnoticed. When in doubt, that IT ticket is still the right call for anything beyond a one-off test. — ## Conclusion The tug-of-war between developer convenience and enterprise security isn’t going away, and tools requiring third-party binaries are an increasingly hard sell to IT. Native SSH reverse tunnels — via Pinggy, Serveo, or similar services — offer a genuinely lighter-weight, less-friction path to sharing local work. Just go in with accurate expectations about what “zero-install” does and doesn’t buy you from a security standpoint. — ## Changelog - Removed SEO subtitle, keyword-stuffed bolding, and “in this comprehensive guide” framing language. - Corrected the claim that Windows ships SSH as a default core feature: per Microsoft’s own documentation, the OpenSSH client is an in-box optional feature on Windows 10 (1809+), Windows 11, and Server 2019⁄2022, requiring manual enablement; Windows Server 2025 is the first release installed by default (though still not auto-enabled). - Corrected the TCP tunnel example: Pinggy routes tunnel type via a tcp@/tls@ username prefix, not a separate tcp.pinggy.io hostname. - Verified current Pinggy facts: 60-minute free-tier cap, unlimited bandwidth on free tier, Pro plan at $3/month, and the addition of a CLI, Docker image, and Node.js/Python SDKs. - Verified Serveo’s continued history of intermittent instability against current uptime-monitor data and user reports (mid-2026). - Added a new section (“Zero-Install Doesn’t Mean Invisible”) citing real-world Microsoft Defender KQL detection content that flags ssh -R command-line patterns directly — an important, previously-missing nuance to the “IT won’t notice” framing. - Softened the “immediately quarantined” EDR claim to reflect that this depends on the specific EDR policy in place, rather than stating it as a universal behavior.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
InstaTunnel vs Cloudflare Tunnel
Compare quick public localhost tunnels with Cloudflare-managed private access workflows.
InstaTunnel vs Pinggy
Compare managed developer tunnel workflows with SSH-style tunnel commands.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
Related Topics

zero install tunneling, native ssh tunnel, ssh reverse tunnel, bypass corporate firewall, no install localhost sharing, pinggy vs serveo, serveo alternative, pinggy alternative, localhost to internet ssh, ssh -r localhost, port forwarding alternative, pinggy ssh tunnel, serveo ssh tunnel, zero install local tunnel, expose localhost ssh, reverse proxy ssh, free native ssh tunnel, bypass it restrictions, bypass binary blocks, minimal footprint tooling, enterprise security tunneling, agentless tunneling, ssh reverse port forwarding, no download reverse proxy, ssh tunnel port 443, local server sharing, share local web server, localcan alternative, cloudflare tunnel alternative, ngrok alternative zero install, secure tunnel localhost, web development tunneling tools, share local api, webhook testing ssh, built in ssh client, macos ssh tunnel, linux ssh tunnel, unapproved third party executables, corporate network bypass, port forwarding without admin, daemonless localhost proxy, pinggy vs localhost.run, serveo vs localhost.run, agentless localhost proxy, reverse tcp proxy, firewall friendly tunneling, free https localhost url, strict it environments localhost, lightweight port forwarding, zero config reverse proxy, expose local dev server, ssh reverse proxy tutorial

Industrial Mirroring: Tunneling Local Sensors to Cloud-Based Digital Twins

InstaTunnel — Sat, 25 Jul 2026 03:56:01 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
Industrial Mirroring: Tunneling Local Sensors to Cloud-Based Digital Twins
Quick answer

ngrok vs Alternatives: Tunneling Local Sensors to Digital Tw: quick comparison answer
Choose the tunnel tool based on the network model: public HTTPS URLs for webhooks and demos, private mesh access for internal apps, and managed infrastructure when policy controls matter most.

Which tunnel tool is best for public webhook testing?
Use a public HTTPS localhost tunnel with stable URLs. InstaTunnel focuses on webhook testing, demos, OAuth callbacks, and MCP endpoint workflows.

When should I choose a private network tool instead?
Choose a private mesh or Zero Trust tool when every user and service should stay inside a controlled private network.

Introduction: Beyond the Webhook
In modern software development, HTTP and its encrypted counterpart HTTPS are the undisputed monarchs of communication. For RESTful APIs, web applications, and standard microservices, stateless request-response architectures are more than sufficient. Step onto a factory floor, a smart-grid substation, or the engine room of an autonomous maritime vessel, though, and the limitations of HTTP become obvious.

Hardware engineers and systems architects working in Operational Technology (OT) don’t have the luxury of bloated headers, slow handshakes, or stateless delays. They deal with raw telemetry — thousands of data points per second measuring vibration, temperature, rotational speed, and fluid dynamics. Pushing this data from local, often legacy, machinery up to a cloud environment requires specialized networking.

This is the domain of industrial mirroring — the real-time, high-fidelity replication of physical assets into virtual environments, commonly known as digital twins. To bridge the gap between the edge and the cloud, engineers increasingly rely on specialized IoT tunneling protocols to bypass restrictive firewalls, work around NAT (Network Address Translation), and establish bi-directional, low-latency communication.

This article covers the technical mechanics of industrial mirroring, the roles of UDP and TCP tunneling, reverse-proxy digital twin architecture, and how to secure sensor tunnels in hostile network environments — along with recent standards work that’s changing how UDP gets tunneled at all.

The Anatomy of Industrial Mirroring and Digital Twins
A digital twin is not merely a 3D dashboard; it’s a live, computational model of a physical system that updates in real time, increasingly paired with predictive models that flag wear-and-tear or forecast mechanical failure.

A digital twin is only as good as the data feeding it, though, and that means it depends on a reliable circulatory system: industrial mirroring.

The Challenge of the Edge-to-Cloud Gap
Consider a CNC milling machine on a factory floor. It outputs telemetry over a localized CAN bus or a legacy serial interface like RS-485. A local edge gateway translates this into IP traffic. The problem is getting that traffic out of the factory’s restrictive, air-gapped, or heavily firewalled network and into an AWS, Azure, or private cloud environment where the digital twin lives.

Inbound connectivity is blocked. Factory networks rarely allow inbound connections — you can’t simply send an API request directly to a sensor from the cloud.
Carrier-grade NAT (CGNAT). Many industrial cellular routers running on 4G/5G sit behind CGNAT and have no publicly routable IP address.
Protocol mismatch. Cloud-native ingestion pipelines often expect WebSockets, MQTT, or HTTPS, while sensors may be broadcasting over raw TCP, UDP, or CoAP (Constrained Application Protocol).
To solve this, architects use tunneling tools designed to punch outbound holes through firewalls and hold persistent connections open.

The Necessity of TCP and UDP in IoT
The Limits of HTTP
HTTP is stateful at the connection level (TCP) but stateless at the application level. Every time a sensor reports a value via HTTP, it typically has to perform a DNS lookup, complete a TCP handshake, complete a TLS handshake, send headers that often dwarf the payload, and then wait for a response. At a reporting rate of 100 Hz, that overhead will choke an edge gateway’s CPU and saturate limited cellular bandwidth.

MQTT and TCP Tunneling
MQTT (Message Queuing Telemetry Transport) over TCP is the workhorse of IIoT. Its publish/subscribe model holds a single, persistent TCP connection to a broker open, eliminating per-message handshake overhead. Routing MQTT through a strict corporate firewall requires a tunnel that can hold long-lived TCP connections open without timing out or interfering with MQTT keep-alive packets.

The Rise of UDP in Real-Time Telemetry
For latency-critical scenarios — remote robotics control, high-frequency vibration analysis — even TCP’s guaranteed delivery becomes a liability. TCP’s congestion control and retransmission logic can cause latency spikes through head-of-line blocking.

UDP is connectionless and fire-and-forget. It doesn’t care if a packet is lost. In vibration analysis, if packet #402 drops, the system doesn’t want the network to pause and re-request it — it wants packet #403 as fast as possible. UDP was long the domain of multiplayer gaming and WebRTC video streaming, but it has become core infrastructure for testing CoAP-based sensor boards and other raw-UDP telemetry sources without a full staging deployment.

Deep Dive: IoT Tunneling Protocols

SSH Reverse Tunneling The most basic form of tunneling is the SSH reverse tunnel (ssh -R). The edge device initiates an SSH connection to a cloud server and forwards a local port to a remote one.

Pros: Ubiquitous, heavily audited, natively supports TCP.
Cons: No native UDP support. Managing thousands of SSH keys and persistent connections at fleet scale is painful, and dropped connections generally need watchdog scripts to restart them.

VPNs and SD-WAN (WireGuard / OpenVPN) A WireGuard mesh lets edge devices sit on the same virtual subnet as cloud servers.

Pros: Full network-level transparency. Supports TCP, UDP, and ICMP. Strong security properties.
Cons: Heavier weight — usually needs kernel-level access or a full user-space client — and often overkill if you only need to expose a single telemetry stream rather than whole-network access.

Modern Multi-Protocol Tunnels UDP support is the actual dividing line in the tunneling market today. ngrok does not support UDP tunnels at all — only HTTP(S) and TCP — which rules it out for anything using raw UDP or CoAP. Tools built specifically to treat UDP as a first-class citizen include Localtonet, Pinggy, LocalXpose, and Playit.gg, all of which offer dedicated UDP (and mixed TCP+UDP) tunnel types alongside HTTP tunneling.

Mechanism: A lightweight agent on the edge gateway (a Raspberry Pi, an industrial router, a custom Linux board) makes an outbound connection to a relay network. The relay assigns a public endpoint — an IP:port pair or a dedicated URL. When the cloud twin platform connects to that endpoint, traffic is routed back down the tunnel to the local device, bypassing CGNAT and restrictive inbound firewalls without any router configuration.

MASQUE: Standardizing UDP-over-HTTP/3 Tunneling A newer, standards-track alternative worth watching is MASQUE (Multiplexed Application Substrate over QUIC Encryption), an IETF working group effort built on top of QUIC and HTTP/3. Rather than each vendor inventing its own UDP-tunneling wire format, MASQUE defines this as an HTTP mechanism:

RFC 9298 — “Proxying UDP in HTTP” (August 2022) defines CONNECT-UDP: an HTTP/3 Extended CONNECT request that maps QUIC DATAGRAM frames to UDP packets sent to a target. This is the core mechanism for tunneling a UDP flow through an HTTP proxy.
RFC 9484 — “Proxying IP in HTTP” (October 2023) extends the model with CONNECT-IP, letting a client push raw IP packets — TCP, UDP, and ICMP together — through a single HTTP/3 connection, effectively turning an HTTP/3 endpoint into a full tunnel gateway.
A further IETF draft, QUIC-Aware Proxying Using HTTP, adds optimizations so a proxy can reuse UDP 4-tuples across multiple proxied QUIC connections instead of opening a new one per flow — relevant for gateways juggling many simultaneous sensor streams.
Because the tunneled payload rides inside HTTP Datagrams on a standard QUIC connection over UDP/443, it’s indistinguishable from ordinary web traffic to any middlebox that hasn’t terminated TLS — a meaningful advantage on factory networks with deep packet inspection or overly aggressive egress filtering. As of 2026 this is moving from CDN/VPN pilots into broader use, and it’s worth evaluating for IIoT gateways alongside vendor-specific tunneling agents, particularly where a single connection needs to carry a mix of TCP control traffic and UDP telemetry.

Implementing a UDP Localhost Tunnel for Telemetry
Consider a developer working on firmware for a robotic arm that outputs joint-angle telemetry at 50 Hz over UDP on port 5000. The cloud-based anomaly detection model needs to ingest this data from the device sitting on their desk, without provisioning a staging environment or requesting a port-forwarding exception from IT.

Using a modern tunneling CLI, the developer might run something like:

Illustrative example — syntax varies by provider

tunnel-cli expose udp --port 5000 --local-ip 127.0.0.1 --region us-east
The network flow:

The CLI opens an outbound control channel to the provider’s regional edge server.
The provider allocates a public endpoint, e.g., udp.tunnelprovider.com:31045.
The cloud AI is configured to listen on that endpoint.
UDP datagrams flow in either direction through the tunnel, which acts as a transparent, stateless pipe.
Because UDP is stateless, there’s no TCP-in-UDP or UDP-in-TCP re-encapsulation overhead to fight — tunneling UDP through a TCP-based transport reintroduces the head-of-line blocking UDP was chosen to avoid. Keeping the tunnel’s transport UDP-native (or, per the MASQUE approach above, QUIC-native with unreliable datagram framing) preserves the loss-tolerant behavior the application expects, rather than forcing reliable delivery semantics onto traffic that doesn’t want them.

Reverse Proxy Digital Twins: Bridging Edge and Cloud
As deployments move from developer testing to production, the architecture typically shifts toward a reverse proxy digital twin pattern.

In standard web architecture, a reverse proxy like Nginx or HAProxy sits in front of web servers for load balancing, SSL termination, and routing. In the IoT world, this flips: instead of the cloud reaching down into the factory, the factory reaches up to the cloud.

The edge gateway (the client): A hardened edge device on the factory floor runs a reverse tunnel client, collecting data from PLCs via Modbus, OPC UA, or raw UDP.
The cloud proxy (the server): A tunnel server runs inside the cloud VPC.
The twin engine: Digital twin software — services like AWS IoT TwinMaker or Azure Digital Twins are the two major managed offerings as of 2026 — sits behind the cloud proxy.
Because the edge device initiates the connection, the factory firewall only needs to allow outbound traffic on port 443. Once that connection is up, the tunnel provides a secure, bidirectional, multiplexed channel, and the digital twin platform interacts with the local proxy as if the physical machine were in the same data center — querying localhost:8080/motor_speed on a cloud instance while the reverse proxy fetches the value from a motor thousands of miles away.

It’s worth noting that both AWS IoT TwinMaker and Azure Digital Twins are twin/graph orchestration layers, not telemetry ingestion services in their own right — they connect to and contextualize data that’s already flowing in through IoT Hub, IoT Core, or a similar ingestion path, rather than replacing the tunneling layer described above.

Ensuring Secure Sensor Tunneling in Hostile Environments
UDP tunnels and reverse proxies extend your localhost’s trust boundary to the open internet. In Operational Technology, a compromised machine doesn’t just mean a data breach — it can mean physical damage. Securing this setup takes a layered approach.

Ephemeral Endpoints and Zero Trust
Never leave a testing tunnel open indefinitely. Spin tunnels up via CI/CD for testing and tear them down immediately after. In production, restrict permanent tunnels with IP allowlisting at the relay level, so only the specific VPC hosting the digital twin can reach the tunnel’s public endpoint.
Payload Encryption (DTLS)
If you’re tunneling raw UDP, the control channel being encrypted isn’t enough on its own — you generally want DTLS (Datagram Transport Layer Security) at the application layer to get TLS-equivalent encryption, authentication, and integrity guarantees on a transport that tolerates dropped and out-of-order packets.

The current version is DTLS 1.3 (RFC 9147, April 2022), which obsoletes DTLS 1.2. It brings the 1-RTT handshake and mandatory forward secrecy from TLS 1.3, along with two additions that matter specifically for tunneled IIoT deployments:

Connection IDs (CIDs): without a CID, DTLS associations are keyed to the UDP host/port 4-tuple, so a NAT rebind — an industrial cellular router getting reassigned a new CGNAT-mapped port, for instance — breaks the session and forces a full re-handshake. CIDs decouple the security association from the 4-tuple, letting a session survive that kind of address change.
An explicit ACK message for handshake records, improving retransmission behavior over lossy links compared to DTLS 1.2’s timer-only approach.

Authentication at the Edge
A tunnel is just a pipe; it doesn’t authenticate what’s flowing through it. Mutual TLS (mTLS) between the edge gateway and the cloud ingress point lets the digital twin verify the cryptographic identity of the sensor before accepting telemetry, which is what stops an attacker from injecting spoofed data to manipulate the twin’s predictive models.
DDoS Mitigation
Unlike HTTP tunnels, which can parse headers and rate-limit abusive requests, raw TCP and UDP tunnels forward packets blindly. An attacker who discovers a public UDP tunnel endpoint can flood it with garbage, and because the tunnel faithfully forwards that traffic down to the edge device, a cloud-side flood can saturate the factory’s actual internet connection.

eBPF/XDP-based filtering is the standard mitigation at the relay or gateway level: XDP lets a program drop malicious packets in the NIC driver, before the kernel allocates sk_buff structures or the packet enters the full network stack, which keeps CPU overhead low even under attack. This isn’t just theoretical — a 2025 evaluation running an eBPF/XDP rate-based filter on a Raspberry Pi 4 under a 100 Mbps UDP flood (roughly 30,000 packets/second) measured over 97% mitigation effectiveness while keeping the device responsive, compared to the device becoming unresponsive with no filtering in place. Tunnel providers and gateway operators building on commodity edge hardware can realistically use the same approach rather than relying purely on upstream scrubbing.

Conclusion
Digital twins are only as good as the data feeding them, and HTTP alone isn’t built for high-frequency, low-latency telemetry. Reliance on dedicated IoT tunneling protocols, UDP-native tunnels for testing, reverse-proxy digital twin architectures, and layered security (mTLS, DTLS 1.3, eBPF-based filtering) is now standard practice for bridging OT networks to cloud twins. The emergence of MASQUE as a standards-track way to tunnel UDP and IP traffic over HTTP/3 suggests this space is consolidating around interoperable mechanisms rather than one-off vendor protocols — worth watching as it matures beyond current pilots.

Sources
IETF, RFC 9298 — Proxying UDP in HTTP
IETF, RFC 9484 — Proxying IP in HTTP
IETF MASQUE WG, draft-ietf-masque-quic-proxy
IETF, RFC 9147 — The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
Localtonet, Secure Tunneling for Any Protocol (UDP support comparison vs. ngrok)
Tolay, eBPF-Based Real-Time DDoS Mitigation for IoT Edge Devices (Raspberry Pi 4 / 100 Mbps flood results)
AWS, AWS IoT TwinMaker documentation
Microsoft, What is Azure Digital Twins?
Changelog
Removed (SEO / AI-draft artifacts): - Opening paragraph explaining the article’s SEO targeting strategy (“Highlighting how multi-protocol tunneling tools handle real-time data streams… targets a highly technical, low-competition niche…”) — meta-commentary about the article itself, not content for readers. - All bracketed pseudo-citations ([1.1.1], [1.2.1], [1.2.3]) pointing to two fabricated, non-existent source titles (“Spatial Computing & Real-World Testing: The 2026 Developer’s Playbook” and “Beyond HTTP: Exposing WebRTC and Local Game Servers via UDP Tunnels”). Replaced with a real, checked Sources list. - Unsupported specific claim that the described setup preserves “sub-millisecond network dynamics” — no basis for that figure; reworded to describe the actual mechanism (avoiding TCP-in-UDP re-encapsulation overhead) instead of asserting an unverified number.

Corrected: - The original draft implied “modern multi-protocol tunnels” broadly treat UDP as first-class without naming which do or don’t. Verified against current vendor documentation: ngrok has no UDP tunnel support (HTTP/S and TCP only); Localtonet, Pinggy, LocalXpose, and Playit.gg all offer dedicated UDP tunnel types. This distinction is now explicit rather than implied. - Clarified that AWS IoT TwinMaker and Azure Digital Twins are twin/graph orchestration layers that sit atop existing ingestion services (IoT Hub/IoT Core), not standalone telemetry ingestion or tunneling replacements — the original implied they handled the full pipeline.

Added (verified, current as of mid-2026): - New section on MASQUE / CONNECT-UDP (RFC 9298) and CONNECT-IP (RFC 9484) as an emerging IETF-standardized alternative to vendor-specific UDP tunneling protocols, plus the in-progress QUIC-aware proxying draft that optimizes 4-tuple reuse for multi-flow gateways. - Updated the DTLS section to name the current version specifically (DTLS 1.3, RFC 9147, obsoleting 1.2) and explained Connection IDs, a concrete feature directly relevant to the CGNAT/NAT-rebind problem raised earlier in the article. - Added a real, sourced data point on eBPF/XDP DDoS mitigation effectiveness (97%+ mitigation of a 100 Mbps / ~30k pps UDP flood on Raspberry Pi 4 hardware) to replace the vague, unsupported mitigation claim in the original draft. - Confirmed AWS IoT TwinMaker and Azure Digital Twins are both active, currently supported services as of mid-2026 (no deprecation notices found for either).

Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
InstaTunnel vs LocalXpose
Compare developer tunnel workflows, stable URLs, webhook testing, and plan fit.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
InstaTunnel CLI download
Install or update the CLI for Windows, macOS, Linux, npm, and release binaries.
Related Topics

ngrok, localtonet, localxpose, ngrok alternative, ngrok vs localtonet, ngrok vs localxpose, IoT tunneling protocols, UDP localhost tunnel, reverse proxy digital twins, secure sensor tunneling, industrial mirroring, hardware engineering tools, cloud based digital twins, real time data streams, tcp tunneling iot, udp tunneling iot, multi protocol tunneling, robust iot architecture, low latency telemetry, push telemetry data, secure iot connection, remote sensor access, bidirectional synchronization iot, enterprise iot routing, expose local sensors, forward udp port iot, forward tcp port iot, connect iot to cloud, mqtt broker tunneling, mosquitto remote access, edge device tunneling, raw socket data iot, nat traversal iot, bypass cgnat iot, secure connection remote devices, iot device port forwarding, local sensor network, digital twin optimization, digital twin synchronization, unmetered iot bandwidth, unmetered ngrok alternative, hardware telemetry routing, esp32 remote access, raspberry pi tunneling, localtonet multi protocol, remote device tunneling, reverse proxy iot, secure tcp tunnel, secure udp tunnel, enterprise reverse proxy, webhook alternative iot, iot infrastructure scaling, industrial iot networks, real time iot monitoring, coap protocol tunneling

Letting AI Drive: Exposing Localhost via MCP Servers

InstaTunnel — Fri, 24 Jul 2026 04:52:35 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
Letting AI Drive: Exposing Localhost via MCP Servers
Quick answer

Letting AI Drive: Exposing Localhost via MCP Servers & Pingg: quick comparison answer
Choose the tunnel tool based on the network model: public HTTPS URLs for webhooks and demos, private mesh access for internal apps, and managed infrastructure when policy controls matter most.

Which tunnel tool is best for public webhook testing?
Use a public HTTPS localhost tunnel with stable URLs. InstaTunnel focuses on webhook testing, demos, OAuth callbacks, and MCP endpoint workflows.

When should I choose a private network tool instead?
Choose a private mesh or Zero Trust tool when every user and service should stay inside a controlled private network.

AI coding agents can now write a webhook handler, spin up a dev server, and expose that server to the public internet, all from one natural-language prompt, without the developer touching a second terminal window. The piece that made the last step possible is the Model Context Protocol (MCP): agents that used to stop at the edge of the local machine can now reach through it to tunneling services like Pinggy. This piece walks through how MCP got here, where the agentic IDE landscape actually stands in mid-2026, and exactly how Pinggy’s MCP server and skill work today.

What MCP Actually Standardizes
Anthropic open-sourced the Model Context Protocol on November 25, 2024, as a standard for connecting AI assistants to the systems where data and tools live. Before MCP, connecting a given model to a given tool meant a bespoke integration for every model-tool pair — what Anthropic called the “N×M” problem. MCP collapses that to one server per tool, usable by any MCP-compatible client. The protocol’s message-flow design borrows from the Language Server Protocol (LSP), and messages are exchanged as JSON-RPC 2.0.

The architecture has three parts:

Host — the user-facing application: an IDE, a desktop chat client, a custom agent.
Client — the piece inside the host that speaks MCP and routes calls to servers.
Server — the external process that exposes tools, resources, or prompts (in this case, tunnel management).
The transport layer has changed since MCP’s first release. The original 2024-11-05 spec shipped with stdio (for local, single-client processes) and an HTTP+SSE transport for remote servers. The March 2025 spec revision (2025-03-26) deprecated HTTP+SSE in favor of Streamable HTTP, which uses a single endpoint, supports stateless deployment behind load balancers, and allows resumable sessions — the old dual-endpoint SSE design didn’t hold up well behind serverless platforms and proxies. SSE transport is still supported for backward compatibility, but vendors are setting shutoff dates for it (Atlassian’s Rovo MCP server, for instance, drops SSE support on June 30, 2026). For anything built today, stdio for local tools and Streamable HTTP for remote ones is the current guidance.

MCP’s adoption outside Anthropic moved fast: OpenAI added native MCP support to its Agents SDK in March 2025, and Google DeepMind confirmed support for Gemini the following month. By the time Anthropic handed the protocol’s governance to the Linux Foundation’s newly formed Agentic AI Foundation on December 9, 2025, the ecosystem had grown to more than 97 million monthly SDK downloads and over 10,000 active public servers.

The Agentic IDE Landscape Has Shifted
The three tools most associated with agentic coding have all changed shape since they were first compared side by side.

Cursor, built by Anysphere on a VS Code fork, is still built around Composer (multi-file agent edits) and per-task model switching between Claude, GPT, and Gemini. Anysphere shipped a proprietary model, Composer, alongside “Cursor 3” in April 2026 — a redesign centered on an Agents Window that manages parallel agent sessions across local machines, Git worktrees, cloud sandboxes, and remote SSH targets. Anysphere’s valuation climbed from a $29.3 billion Series D in November 2025 toward reported talks above $50 billion in 2026, and in mid-2026 SpaceX (by then merged with xAI) structured a deal giving it the right to acquire Anysphere for $60 billion — not yet exercised as of this writing.
Windsurf started as Codeium’s agentic IDE with the Cascade planning system. After Google’s roughly $2.4 billion acquihire of Windsurf’s CEO and senior staff in mid-2025, Cognition AI — maker of the autonomous coding agent Devin — signed a deal to acquire the rest of the company, closing around December 2025 for roughly $250 million. Windsurf is no longer an independent product: it now runs Cognition’s own SWE-1.5 model, ships a codebase-visualization feature called Codemaps, and is being merged with Devin into a single agentic development stack.
Claude Code, Anthropic’s coding agent, started terminal-only but no longer lives there exclusively. It now runs across six surfaces sharing one underlying engine: the original terminal CLI, a VS Code extension, a JetBrains plugin (IntelliJ IDEA, PyCharm, WebStorm, and others), a standalone desktop app, a web version at claude.ai/code, and a Slack integration. All surfaces share the same CLAUDE.md project configuration, permission modes, and MCP server connections — the terminal is one entry point among several rather than the whole product.
MCP is the connective layer across all of them: any of these clients can attach to the same MCP server, including one that manages tunnels.

The Localhost Bottleneck
Writing the code for a webhook integration was never the hard part. Testing it against a live third-party service — Stripe, Shopify, a mobile client on a different network — needs a public URL pointing at your local machine. The traditional flow breaks the agent’s autonomy at exactly that step: stop, open another terminal, authenticate with a tunneling service, copy a URL back into the agent’s context or a dashboard, resume. Multiply that across webhook testing, remote demos, and IoT/device work, and it’s a recurring source of context-switching that an agent can’t work around on its own — unless it has a tool call that does the tunneling for it.

Pinggy’s MCP Server and Skill
Pinggy, the SSH-based tunneling service, ships two separate pieces of agent tooling that can be installed together or independently: an Agent Skill and an MCP server.

The skill is packaged instructions and reference material — SSH commands, CLI flags, SDK usage — that an agent reads and then executes itself using ordinary terminal access. The MCP server is a running process that exposes tunnel operations as callable tools, so the agent doesn’t need to reconstruct a command from documentation; it calls a tool directly. Pinggy’s own guidance is to start with the skill and add the MCP server only once you want the agent operating tunnels on its own.

Installing the skill
npx skills add https://pinggy.io
This is published under the community Agent Skills standard, and the skills CLI detects the agent and installs into its skills directory — for Claude Code, that’s ~/.claude/skills/pinggy/. The only prerequisite is Node.js.

Installing the MCP server
The MCP server’s source lives at github.com/Pinggy-io/pinggy_mcp — Pinggy’s own documentation flags it as “early and experimental.” It requires Python 3.10+ and uv:

curl -LsSf https://astral.sh/uv/install.sh | sh
Nothing else installs globally; each client fetches and runs pinggy-mcp on demand through uvx. Configuration differs by client — notably, VS Code uses a servers key while Claude Desktop, Cursor, and Windsurf use mcpServers, and the exact file each one reads is different too.

Claude Code — registered directly through the CLI rather than a config file:

claude mcp add pinggy-mcp -- uvx --from git+https://github.com/Pinggy-io/pinggy_mcp.git pinggy-mcp
Confirm it registered with claude mcp list.

Claude Desktop — edit the config file for your OS: - macOS: ~/Library/Application Support/Claude/claude_desktop_config.json - Windows: %APPDATA%\Claude\claude_desktop_config.json - Linux: ~/.config/Claude/claude_desktop_config.json

{
"mcpServers": {
"pinggy-mcp": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Pinggy-io/pinggy_mcp.git",
"pinggy-mcp"
]
}
}
}
Cursor — ~/.cursor/mcp.json for a global config, or .cursor/mcp.json in a project root:

{
"mcpServers": {
"pinggy-mcp": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Pinggy-io/pinggy_mcp.git",
"pinggy-mcp"
]
}
}
}
VS Code — ~/.vscode/mcp.json (global) or .vscode/mcp.json (project); note the top-level key is servers, not mcpServers:

{
"servers": {
"pinggy-mcp": {
"type": "stdio",
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Pinggy-io/pinggy_mcp.git",
"pinggy-mcp"
]
}
}
}
Reload with Developer: Reload Window from the command palette afterward.

Windsurf — ~/.codeium/windsurf/mcp_config.json:

{
"mcpServers": {
"pinggy-mcp": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Pinggy-io/pinggy_mcp.git",
"pinggy-mcp"
]
}
}
}
Restart Windsurf after saving.

What you can actually ask it to do
Once connected, Pinggy’s own documentation gives these as example prompts:

“Expose my dev server on port 3000.”
“Open a TCP tunnel to localhost:22.”
“Share my ~/Downloads folder over the internet.”
“Log in to Pinggy.”
“List my active tunnels.”
“Only allow traffic from 1.2.3.4 to my tunnel.”
“Stop the tunnel.”
Worth noting: Pinggy’s docs don’t publish the technical details of what “log in” does under the hood, and given the project is explicitly labeled early and experimental, it’s worth reading the source before pointing it at anything sensitive. Every Pinggy doc page is also published as plain Markdown at the same URL with an index.md suffix, and the whole site is summarized at pinggy.io/llms.txt — a detail aimed squarely at letting agents read the docs directly rather than scraping rendered HTML.

Practical Use Cases
Webhook testing. Ask an agent building a Shopify integration to “set up the order-creation webhook,” and it can write the route handler, start the local dev server, call the Pinggy MCP tool to open an HTTP tunnel, and hand the resulting URL to whatever registers it with Shopify — collapsing a normally multi-step manual process into one exchange.

Device and sensor access. For a local IoT sensor or a Raspberry Pi that needs to reach a cloud endpoint, an agent can open a TCP tunnel and hand back the public address without the developer manually reconstructing an SSH command.

File and folder sharing. Pinggy’s CLI can serve a local directory directly (pinggy --serve /path/to/files), and that capability is exposed through the MCP server too — “share my ~/Downloads folder” is one of the documented example prompts. For a colleague reviewing a dataset or build output, that’s a public link without uploading anything to a third-party storage service first.

Security Considerations
None of this removes the need for judgment. VS Code’s own MCP documentation puts it plainly: local MCP servers can run arbitrary code on your machine, and you should only add servers from sources you trust and have reviewed. Pinggy’s MCP server is genuinely new — the company’s own docs call it experimental — so the usual due diligence applies: read what the server actually does before granting it network and filesystem access, and don’t assume “the agent asked politely” is the same thing as “this is safe to expose.” IP whitelisting and Pinggy’s own authentication options (basic auth, bearer tokens) remain available on any tunnel the agent opens, and they’re worth applying by default rather than only when something goes wrong.

Where This Is Heading
MCP didn’t just standardize file access and API calls — it gave agents a socket back out to the network tools developers already use. Tunnel management was a natural, if unglamorous, thing to put behind that interface: developers were manually running the same handful of commands anyway, and an agent that can already write the webhook handler can just as easily call the tool that exposes it. Whether it’s a sensor feed, a webhook, or a folder full of test data, the pattern is the same: describe what you want reachable, and let the tool call handle the mechanics.

Changelog
This piece was rewritten from an earlier draft. Corrections and additions, with sources:

MCP announcement date and framing — confirmed November 25, 2024 as the release date, and confirmed the “N×M” integration problem framing and the LSP-derived message-flow design, against Anthropic’s own announcement and multiple technical retrospectives. (Anthropic, “Introducing the Model Context Protocol,” anthropic.com/news/model-context-protocol; NeuralCoreTech, “Why MCP Became the Standard for Agentic AI,” May 2026)
Transport layer corrected — the original draft described SSE as a current remote transport. In fact, the MCP spec revision 2025-03-26 deprecated HTTP+SSE in favor of Streamable HTTP; SSE is retained only for backward compatibility and several vendors have announced 2026 shutoff dates. (modelcontextprotocol.io/specification/2025-11-25/basic/transports; GitHub modelcontextprotocol/python-sdk issue #2278; Atlassian Community, “HTTP+SSE Deprecation Notice for Atlassian Rovo MCP server”)
Added MCP adoption and governance update — OpenAI Agents SDK support (March 2025), Google DeepMind/Gemini support (April 2025), and Anthropic’s December 9, 2025 donation of MCP’s governance to the Linux Foundation’s Agentic AI Foundation, along with current scale figures (97M+ monthly SDK downloads, 10,000+ active public servers). This postdates the original draft. (NeuralCoreTech, May 2026; Cuttlesoft, “Anthropic’s Model Context Protocol,” Feb 2026)
Cursor, Windsurf, and Claude Code descriptions updated for 2026 — the original draft described Windsurf as an independent product; it was acquired by Cognition AI (announced mid-2025, deal closing around December 2025 for roughly $250 million) after Google’s acquihire of Windsurf’s CEO and senior staff, and now runs Cognition’s SWE-1.5 model. Cursor’s parent Anysphere reached a $29.3B valuation in its November 2025 Series D, and in mid-2026 a SpaceX/xAI deal structured an option to acquire Anysphere for $60B. Claude Code was described as terminal-only; it now ships across six surfaces (terminal, VS Code extension, JetBrains plugin, desktop app, web, Slack). (Wikipedia, “Cognition AI”; Taskade, “Windsurf Review 2026”; ValueAddVC, “Cursor (Anysphere) Valuation 2026”; Fastio, “Claude Code IDE Setup for VS Code and JetBrains (2026)”)
Corrected the Pinggy MCP server’s GitHub source — the original draft cited github.com/abhimp/pinggy_mcp, which could not be verified. The actual, official repository is github.com/Pinggy-io/pinggy_mcp, confirmed directly against Pinggy’s own documentation. (pinggy.io/docs/ai_agents/)
Replaced unverified OAuth 2.0 Device Authorization Grant claim — the original draft asserted Pinggy’s MCP server uses the OAuth 2.0 Device Authorization Grant (RFC 8628). Pinggy’s own documentation does not describe the underlying authentication mechanism for its “log in” tool call, so this specific claim has been removed rather than repeated unverified. (pinggy.io/docs/ai_agents/ — no mention of OAuth or device flow found)
Replaced unverified WebDAV claim — the original draft described folder sharing as happening “over WebDAV.” Pinggy’s documented mechanism is its existing file-serving flag (pinggy --serve ), exposed through the MCP server as a natural-language capability; no WebDAV-specific implementation is documented. (pinggy.io/docs/ai_agents/; GitHub Pinggy-io/cli-js README)
Corrected and completed installation instructions — the original draft’s config example was largely accurate for VS Code (the servers key was actually correct) but conflated VS Code, Cursor, and Windsurf into one shared config format and path. These three use different top-level keys (servers vs. mcpServers) and different file paths, and Claude Code’s installation is a CLI command rather than a JSON file. All five configurations, plus prerequisites (Python 3.10+, uv), were pulled directly from Pinggy’s current documentation, which also explicitly labels the MCP server “early and experimental.” (pinggy.io/docs/ai_agents/)
Added verified example prompts — replaced illustrative but unsourced prompts with Pinggy’s own documented examples, including IP whitelisting and folder sharing. (pinggy.io/docs/ai_agents/)
Removed SEO-style bolded phrase repetition and generic AI-filler framing (“the workplace revolution,” “game-changer,” redundant restatements of the thesis) throughout, consistent with house style for this blog.
Added a security-considerations note grounded in VS Code’s own published MCP security guidance and Pinggy’s self-description of the server as experimental, rather than a general reassurance about “security remaining a priority.” (code.visualstudio.com/docs/agent-customization/mcp-servers; pinggy.io/docs/ai_agents/)
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
InstaTunnel vs Pinggy
Compare managed developer tunnel workflows with SSH-style tunnel commands.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
InstaTunnel CLI download
Install or update the CLI for Windows, macOS, Linux, npm, and release binaries.
Related Topics

MCP server tunneling, automate localhost exposure, AI agent webhook testing, Pinggy AI skill, model context protocol, Cursor AI tunnel, Windsurf AI localhost, Claude Code MCP, AI agent developer workflows, agentic developer workflows, AI coding assistants, MCP server localhost, Pinggy MCP integration, natural language port forwarding, AI driven tunnel management, expose local server AI, agentic tunneling, MCP proxy, MCP localhost expose, Pinggy SSH tunnel AI, MCP tools for developers, AI webhook proxy, localhost to web AI, model context protocol Pinggy, Claude Desktop MCP, Cursor MCP server, Windsurf MCP integration, automate tunnel with AI, AI localhost routing, Pinggy CLI AI, AI developer environment, LLM developer tools 2026, natural language localhost proxy, AI agent network tools, local environment to AI, secure MCP tunnel, localhost tunneling for AI, agentic AI proxy, AI generated webhooks, test webhooks with AI, MCP server tutorial, setup MCP server, MCP server Pinggy, ngrok alternative for AI, AI workflow tunneling, automated port forwarding, AI infrastructure tools, Pinggy AI agent, Claude MCP tunneling, natural language tunneling, expose MCP server, connect local MCP to Claude, local LLM tunnel, AI agent localhost preview

Moving From Local Dev to Production: Piko as an Open-Source Ngrok Alternative for Kubernetes Clusters

InstaTunnel — Thu, 23 Jul 2026 04:10:40 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
Moving From Local Dev to Production: Piko as an Open-Source Ngrok Alternative for Kubernetes Clusters
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

ngrok vs piko: The Open-Source Kubernetes Production Proxy: webhook testing answer
For local webhook testing, run your app locally, expose it with a public HTTPS tunnel, and paste the stable callback URL into the provider dashboard.

How do I test webhooks on localhost?
Start your local server, open a public HTTPS tunnel to that port, configure the provider webhook URL, and inspect events in your local logs.

Why does a stable webhook URL matter?
Stable URLs prevent provider dashboards from needing manual callback updates every time you restart a tunnel.

Every developer remembers the first time they used ngrok: one command, and a local server on localhost is reachable from the public internet. For testing webhooks, sharing a work-in-progress build, or hacking together a quick integration, it works well.

But that same reverse-tunneling pattern behaves differently once you need it for production services running inside a Kubernetes cluster. At that point the requirements change — you need fault tolerance, horizontal scaling, and control over your data plane, ideally without a SaaS licensing bill that scales with usage.

This is the gap Piko is built to fill: an open-source, Go-based reverse proxy and tunneling system, MIT-licensed, created by Andy Dunstall and hosted at github.com/andydunstall/piko. Its own documentation describes it plainly as “an open-source alternative to Ngrok, designed to serve production traffic and be simple to host (particularly on Kubernetes).”

How Reverse Tunneling Works, and Where It Struggles at Scale
Traditional ingress requires opening an inbound port — you poke a hole in your perimeter so the internet can reach your service.

Reverse tunneling inverts this: your internal service makes an outbound connection to an external edge server, which then routes public traffic back down that already-established tunnel. Outbound connections are almost universally permitted by corporate firewalls, so there’s no NAT configuration, no port forwarding, and no security-review cycle to get through.

The friction shows up when you take a tool built around a single developer’s laptop and try to run it as production infrastructure in a cluster:

Single point of failure — a standalone tunnel client that crashes drops traffic until it restarts.
Horizontal scaling limits — load-balancing a large number of concurrently connected tunnel clients isn’t something every local-dev tool is designed for.
Data residency — unless you’re on a self-hosted or enterprise plan, traffic passes through a third-party SaaS edge, which is a nonstarter for some compliance requirements.
Cost at scale — bandwidth- or endpoint-based SaaS pricing scales linearly with your footprint.
What Piko Actually Does Differently
Piko isn’t meant to run as a single binary on a laptop — it’s designed to run as a cluster of nodes, and its own docs are explicit that this is the point: it’s “built to serve production traffic by running as a cluster of nodes for fault tolerance, horizontal scaling and zero-downtime deployments.”

The mechanics: your upstream service (or the Piko agent running next to it) opens an outbound-only connection to a Piko server node and registers the endpoint it’s listening on. Piko never opens a connection to your service — it only ever forwards traffic down the connection your service opened to it. That means the service can run anywhere, with no exposed port and no public route, as long as it can reach the Piko server.

High availability via gossip
Because pods are ephemeral, Piko is designed to run as multiple server nodes that discover each other and share cluster state. If an upstream is connected to node A but a request lands on node B, node B looks up which node holds the connection and forwards the request internally.

To keep every node’s view of “which endpoint is connected where” in sync, Piko uses a gossip-based anti-entropy mechanism. When upstreams connect or disconnect, that state change propagates around the cluster — according to Piko’s own documentation, typically in under a second, not instantaneously. If a node fails or is deprovisioned, the affected upstream reconnects to a surviving node and the new routing state is propagated the same way. This is what makes it reasonable to run Piko as a Kubernetes StatefulSet behind a standard HTTP(S) load balancer.

One real operational constraint worth flagging: Piko’s own docs recommend deploying a single cluster within a single region, distributed across availability zones — it isn’t designed out of the box as a multi-region active-active system. That’s a meaningful caveat if “high availability” is doing a lot of work in your evaluation.

Four ports, not one
A Piko server node exposes four distinct ports, each with a specific job (shown here with the default values from Piko’s Kubernetes deployment example):

Port Default Purpose
Proxy 8000 Receives HTTP(S) traffic from downstream clients and routes it to the correct upstream. Depending on your deployment, this may be public-facing or only reachable from clients on the same network — for example, in a BYOC setup where the client is your own control plane.
Upstream 8001 Where upstream services (agents or the Go SDK) connect to register an endpoint and hold their outbound tunnel open.
Admin 8002 Serves the status API, cluster/node health checks, and a Prometheus /metrics endpoint. Piko’s docs are explicit that this port should not be exposed to the internet, and if you must expose it, you should enable TLS and authentication.
Gossip 8003 Node-to-node only. Carries the gossip protocol traffic used for service discovery and routing-state propagation.
Because the admin port exports Prometheus metrics natively, wiring up Grafana dashboards for tunnel health and throughput is straightforward without custom instrumentation.

Routing without wildcard DNS
When a request hits the proxy port, Piko identifies the target endpoint from either the Host header (using the first subdomain segment — e.g., foo.piko.example.com routes to the foo endpoint) or a custom x-piko-endpoint header, which lets you skip setting up wildcard DNS entirely.

TCP traffic can’t carry a header, so for TCP tunnels you connect through piko forward (which maps a local TCP port to a target endpoint) or the Go SDK, rather than connecting straight to the server.

Authentication
Piko authenticates connecting clients with a JWT provided by your own application. It supports HMAC, RSA, and ECDSA signing (specifically HS256/384/512, RS256/384/512, and ES256/384/512), and each port — proxy, upstream, and admin — can be configured with independent auth settings. A JWT can optionally carry a piko claim scoping the token to specific endpoints; if that claim is absent, the token can access any endpoint. Piko also supports mutual TLS, added in release v0.6.4, and JWKS-based key verification, added in v0.8.0, alongside multi-tenant upstream authentication in that same release.

Bring-Your-Own-Cloud (BYOC)
This is the use case Piko’s own maintainers point to explicitly, alongside “expose services in a customer network” and “connect to user devices.” It addresses a specific, common enterprise problem: a vendor needs to manage and monitor software that runs deep inside a customer’s own VPC, and the customer’s security team will not open inbound firewall ports for a third party’s control plane.

With Piko, the vendor runs a Piko server cluster centrally, and a lightweight Piko agent runs inside the customer’s environment alongside the workload. The agent opens an outbound-only connection back to the vendor’s cluster — which, to the customer’s firewall, looks like ordinary outbound web traffic. Once that tunnel is up, the vendor’s control plane can route requests, trigger deployments, or scrape metrics through it, without VPN tunnels, VPC peering, or custom NAT gateways per customer. (The “50 customers, 50 security reviews” framing here is illustrative of the pattern Piko documents, not a direct quote from its docs.)

Deploying Piko
Piko ships a Helm chart at operations/helm in the repository, which creates a headless Service and a StatefulSet. The one hard requirement on your load balancer is WebSocket-upgrade support, since that’s how upstream agents hold their persistent outbound connections open.

Registering an upstream is a single command. The agent binds to your service’s local port and opens the tunnel:

Connects a local service on port 4000 to the Piko cluster

under the endpoint name "my-endpoint"

piko agent http my-endpoint 4000
The same piko binary handles both roles — piko server to run a node, piko agent http|tcp to register an upstream, and piko forward for TCP clients. Docker images are published to ghcr.io/andydunstall/piko.

Current State of the Project
As of this writing, Piko is at v0.10.0 (released May 8, 2026), and development has been active and incremental over the past two years — mutual TLS support (v0.6.4, December 2024), connection rebalancing across the cluster (v0.7.0, February 2025), JWKS and multi-tenant upstream auth (v0.8.0, August 2025), graceful client shutdown (v0.9.0, January 2026), and configurable stream window sizing (v0.10.0, May 2026).

Two things worth weighing before betting production traffic on it:

It’s still pre-1.0. Versioning at 0.x doesn’t mean it’s unstable, but it does mean the project hasn’t declared a stable, backward-compatible API surface yet.
It’s a small but real community. At the time of writing the repository has roughly 2,200 GitHub stars and 87 forks, and it’s listed in the community-maintained awesome-tunneling directory — which, as of a February 2026 policy update, now requires at least 100 GitHub stars for any new tool to be added. Piko clears that bar, but it’s still a single-maintainer-led project rather than a large team.
ngrok vs. Piko: Where Each One Fits
ngrok is not obsolete, and nothing here suggests it should be for its actual target use case. For a developer testing a Stripe webhook locally, sharing a preview build with a client, or wanting someone else’s edge to absorb DDoS traffic, ngrok’s managed experience is hard to beat.

The dividing line is production Kubernetes infrastructure — specifically BYOC ingress, environments with data-residency constraints, or high-traffic internal services where a third party’s edge isn’t an option. For that case, Piko offers the operational shape of a reverse tunnel with a cluster-native architecture you host and control yourself, at the cost of running and operating that cluster — and of adopting a pre-1.0 project rather than a mature managed product.

Fact-Check & Changelog
Verified against Piko’s official GitHub repository, wiki, and release notes (all links below).

Corrected propagation timing. The draft claimed gossip state propagates “in milliseconds.” Piko’s own wiki states routing updates are “usually” propagated “in less than a second” — corrected accordingly. (How Piko Works)
Softened the failover claim. The draft said a failed node causes “instant” reconnection. Piko’s docs describe automatic reconnection to a surviving node without giving a specific latency figure — removed the unsupported “instant” framing.
Added exact port numbers. The draft described four ports conceptually with no values. Confirmed and added the actual defaults (8000/8001/8002/8003) from Piko’s Kubernetes deployment example. (Server Kubernetes)
Added the admin-port security warning. Piko’s docs explicitly state the admin port “should not be exposed to the Internet,” and if it must be, TLS and auth should be enabled — this specific guidance wasn’t in the original draft. (Server)
Verified and specified JWT support. Confirmed Piko supports HMAC, RSA, and ECDSA JWT signing algorithms with per-port configuration and optional endpoint-scoping claims, rather than a generic “JWT authentication” mention. (Authentication)
Verified and dated mTLS support. Confirmed mutual TLS support, added in release v0.6.4 (December 2024). (Releases)
Verified the Helm chart claim. Confirmed the chart exists at operations/helm in the repo and creates a headless Service + StatefulSet. (Server Kubernetes)
Verified BYOC as an official use case, not just marketing framing — Piko’s own wiki lists “a bring your own cloud (BYOC) service” as a stated use case. (What Is Piko?)
Added project maturity context not present in the original draft: current release (v0.10.0, May 2026), pre-1.0 versioning, and approximate community size (~2,200 stars, 87 forks), plus third-party validation via inclusion in the awesome-tunneling list under its 100-star minimum policy. (Releases, awesome-tunneling)
Added the single-region caveat. Piko’s docs recommend a cluster be deployed within a single region across availability zones — a real limit on the HA story that the original draft omitted. (Server)
Clarified TCP tunnel routing. Made explicit that TCP tunnels require piko forward or the Go SDK, since raw TCP has no header to identify the target endpoint. (What Is Piko?)
Stripped SEO/AI-draft artifacts: removed unverifiable superlatives (“the gold standard,” “brilliant,” “the industry is pivoting”) and any leftover metadata framing not relevant to a technical readership.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
Plans and limits
Compare Free, Pro, and Business limits for tunnels, MCP endpoints, bandwidth, and teams.
Trust and security center
Review security controls, reliability practices, status references, and operational safeguards.
Related Topics

ngrok vs piko, piko reverse proxy, piko kubernetes, kubernetes production proxy, piko vs ngrok, ngrok alternative, open source ngrok alternative, enterprise ngrok alternative, platform engineer tools, devops networking tools, kubernetes ingress architecture, high traffic k8s clusters, byoc networking, bring your own cloud architecture, outbound only connections, fault tolerant reverse proxy, horizontal scaling proxy, zero downtime deployment k8s, piko cluster nodes, piko go proxy, golang reverse proxy, k8s production tunnel, production traffic proxy, cloud native tunneling, secure outbound tunnel, secure k8s ingress, expose k8s services securely, piko github, piko open source, self hosted production tunnel, bypass local dev proxy, local dev to production, scalable k8s proxy, kubernetes gateway alternative, kubernetes load balancer proxy, multi node proxy cluster, tunnel outbound k8s, piko agent, piko server, open source tunnel kubernetes, enterprise ingress tool, platform engineering k8s, k8s devops proxy, secure tunnel cluster, kubernetes network security, open source ingress controller, byoc proxy, k8s deployment proxy, self hosted ingress proxy, production ready tunnel, ngrok production alternative

Tunnelmole vs ngrok: A Native npm Alternative for Node.js Developers

InstaTunnel — Wed, 22 Jul 2026 07:27:01 +0000

Tunnelmole vs ngrok: A Native npm Alternative for Node.js Developers

Every developer running a local server eventually hits the same wall: the app works fine on localhost:3000, but a webhook provider, a physical phone, or a client on the other side of the world can't reach it. For years, ngrok has been the default fix. Tunnelmole is a newer, TypeScript-native option that's picked up traction specifically among Node.js and JavaScript developers who'd rather not leave the npm ecosystem to get a public URL.

This piece compares the two head-to-head: installation friction, licensing, self-hosting, and the parts of Tunnelmole's own documentation that are worth reading before you point production-adjacent traffic through it.

Why Tunneling Tools Exist

Your router and OS firewall block inbound traffic to your machine by default — that's a feature, not a bug. But it creates real friction during development:

Webhooks: Stripe, Twilio, GitHub, and Discord need a public URL to POST to. They can't reach localhost:3000.
Mobile and cross-device testing: phones on the same Wi-Fi are often isolated from your dev machine by client isolation, and typing a LAN IP into a phone is clunky anyway.
HTTPS-only browser APIs: Service Workers, the Web Crypto API, Geolocation, push notifications, and PWA installation all require a secure context. Self-signed certs across multiple devices are a hassle to manage.
Demoing work in progress: showing a client or teammate something running locally, without a full deploy.

A tunneling tool solves this by running a lightweight client that opens an outbound connection to a cloud relay, which then hands out a public URL and forwards traffic back down that connection to your local port. Because the connection is outbound-initiated, it gets through most NATs and firewalls without any router configuration.

Where ngrok Creates Friction for JS Developers

ngrok is a mature, capable product, but a few things about it specifically bother developers who live in the npm ecosystem:

It's a Go binary, not an npm package. The core agent is a closed-source, pre-compiled Go binary. Node.js wrappers exist, but they work by spawning that binary as a child process rather than behaving like a native JS module.

An account and authtoken are mandatory. This isn't outdated FUD — ngrok's own CLI documentation states plainly that the service requires you to sign up for an account to connect an agent, and attempting to run the agent without a verified account and authtoken now fails outright with an ERR_NGROK_4018 authentication error. There's no more anonymous, zero-signup quick start.

It's closed source. You can't audit the agent's code, and ngrok's pricing, plan names, and feature gating have changed multiple times over the product's history — something worth knowing if you're building a workflow that depends on specific free-tier limits staying put.

Enter Tunnelmole

Tunnelmole is an open-source tunneling tool built by developer Robbie Cahill, with both halves of the stack — the tunnelmole-client and the tunnelmole-service backend — written in TypeScript. The pitch is straightforward: no Go binary, no mandatory signup for the free tier, and a codebase JS developers can actually read.

Licensing (this is a two-license project, not one)

This is a detail worth getting right, since it affects what you can legally do with each half:

tunnelmole-client is MIT licensed — permissive, easy to vendor into your own tooling.
tunnelmole-service (the backend relay) is AGPLv3 licensed — if you modify it and make it available over a network, the AGPL's network-use clause applies. Tunnelmole's maintainer also offers a separate commercial source license for businesses that want more flexibility than AGPL allows.

Installing it

If you have Node.js 16.10 or later, the npm route works:

npm install -g tunnelmole
tmole 3000

You can also skip the Node version requirement entirely and grab a precompiled binary with Node bundled in:

curl -O https://install.tunnelmole.com/xD345/install && sudo bash install

Windows users can download tmole.exe directly and add it to their PATH.

Either way, running tmole <port> gives you both an HTTP and HTTPS URL immediately, no account required for the default hosted service:

$ tmole 8080
http://evgtkh-ip-49-145-166-122.tunnelmole.net is forwarding to localhost:8080
https://evgtkh-ip-49-145-166-122.tunnelmole.net is forwarding to localhost:8080

Using it programmatically

Tunnelmole also ships as an npm dependency for use inside Node/TypeScript code, supporting both ESM and CommonJS:

npm install --save tunnelmole

import { tunnelmole } from 'tunnelmole';
import express from 'express';

const app = express();
const PORT = 3000;

app.get('/', (req, res) => {
  res.send('Hello from the public web, routed through Tunnelmole!');
});

app.listen(PORT, async () => {
  console.log(`Server is running locally on http://localhost:${PORT}`);
  const url = await tunnelmole({ port: PORT });
  console.log(`Public URL available at: ${url}`);
});

The function is async and won't block your event loop. Installing as a dependency also drops node_modules/.bin/tmole into your project, which is handy for wiring into an npm script like "start-public": "npm run start && tmole 3000".

Two Things the Marketing Copy Tends to Skip

These don't show up in most comparison posts, but they matter for anyone evaluating Tunnelmole for anything beyond casual local testing.

Your IP is not hidden on the hosted service. Tunnelmole's own FAQ is direct about this: the service used to obscure origin IPs, but that was exploited by phishing operators, so Tunnelmole now attaches an X-Forwarded-For header with your real IP to every response — and for randomly generated subdomains, the IP is embedded in the URL itself. If IP privacy matters for your use case, self-hosting is the way to remove that behavior (you'd need to strip the header yourself), not the default hosted service.

Telemetry is on by default. The client collects anonymized data — your Node.js version, OS, and crash reports with stack traces — unless you opt out by setting TUNNELMOLE_TELEMETRY=0 in your environment. For a one-off tmole 3000 test this is a non-issue; for anything approaching a compliance-sensitive workflow, it's worth disabling explicitly and documenting that you did.

Self-Hosting Tunnelmole

This is the feature ngrok simply doesn't offer at any price. Since both the client and service are open source, you can run your own instance instead of relying on tunnelmole.com:

git clone git@github.com:robbie-cahill/tunnelmole-service.git
cd tunnelmole-service
npm install
cp config-instance.example.toml config-instance.toml
npm start

Point your tunnelmole-client config at your own server's WebSocket endpoint instead of the default SaaS instance, and you have a fully private tunneling setup with no third party in the loop, no telemetry you didn't add yourself, and no subscription needed for custom subdomains (which cost extra on the hosted service).

Two caveats worth flagging before you rely on this for anything real:

tunnelmole-service has no native HTTPS support. The maintainer's documentation is explicit about this — you need to put it behind Nginx (or similar) with a Let's Encrypt certificate to get HTTPS. The hosted tunnelmole.com service adds this infrastructure on top of the open-source code; a bare self-hosted instance won't have it out of the box.
The official hosted service isn't 100% identical to the open-source repo. Per the maintainer, tunnelmole.com runs the same open-source code plus closed-source billing/subscription verification and the added HTTPS infrastructure — that's the only proprietary layer, but it means "self-hosted" and "hosted" aren't running byte-identical software.

Feature Comparison

Attribute	ngrok	Tunnelmole
Core agent	Go, closed-source binary	TypeScript, open source
Account required for free tier	Yes — verified account + authtoken enforced	No, for the default hosted service
License	Proprietary	MIT (client) / AGPLv3 (service)
Self-hostable	No	Yes
Programmatic Node.js use	Wrapper around external binary	Native ESM/CommonJS module
IP hidden from destination	N/A (ngrok's own infra)	No — `X-Forwarded-For` + IP in URL on hosted service
Telemetry	Not the focus of this piece	On by default, opt-out via env var
Custom subdomains, hosted free tier	Included (ngrok-branded domain)	Requires paid subscription unless self-hosted

Where Each Tool Actually Costs Money

Since pricing is exactly the kind of thing that goes stale fastest in posts like this, here's ngrok's current published structure (verified directly against ngrok's pricing page, not a third-party aggregator):

Plan	Price	Includes
Free	$0	$5 one-time usage credit (lasts one year, free plan only), up to 3 online endpoints, 1GB data transfer, 20k HTTP/S requests/month, interstitial warning page on endpoints
Hobbyist	$8/mo billed annually ($10 month-to-month)	$10 monthly usage credit, 3 online endpoints, 5GB data transfer, 100k requests included, no interstitial page, ngrok-branded domains
Pay-as-you-go	$20/mo + usage	Unlimited online endpoints and data transfer, bring-your-own domain, usage billed beyond included credit
Enterprise	Custom	SSO/SAML, SCIM, HIPAA BAAs, SOC 2 reports, dedicated support SLAs

Tunnelmole's hosted service is free for the core use case (random subdomain, HTTPS included); a subscription is only needed for a custom/reserved subdomain, and that requirement disappears entirely if you self-host.

Real-World Use Cases

Webhook development. tmole 3000 gives you a stable public HTTPS URL to hand to Stripe, Twilio, or GitHub's webhook settings, so you can set breakpoints and debug live events instead of writing stub payloads.

Mobile and cross-device testing. Because the tunnel is an outbound WebSocket connection, it gets around client-isolated Wi-Fi networks that would otherwise block a phone from reaching your dev machine directly.

HTTPS-gated browser features. Service Workers, PWA installation, and the Web Crypto API require a secure context. Tunnelmole's hosted HTTPS URLs sidestep the need to generate and trust self-signed certs across every test device.

Conclusion

ngrok remains a capable, enterprise-ready platform — but its account requirement and closed-source agent are real, current constraints, not outdated criticisms. Tunnelmole's pitch to JavaScript developers is legitimate: native npm installation, a readable TypeScript codebase, and a genuinely free, no-signup path for the common case. The trade-offs are just as real, though — telemetry is on by default, your IP is visible on the hosted service, and self-hosting for privacy means you're also on the hook for your own HTTPS termination. None of that makes Tunnelmole a bad choice; it just means "open source and self-hostable" isn't the same claim as "private by default," and it's worth knowing which one you're actually getting before you wire it into anything beyond a quick local demo.

Changelog

Removed: promotional/SEO framing ("Enter Tunnelmole, the tool that has recently gone viral," "the ultimate flex," "reclaiming your ecosystem" section headers) and AI-draft filler throughout; tightened language to match a technical, fact-first tone.
Corrected: original draft did not mention that ngrok now hard-enforces account signup and authtoken verification with a specific error (ERR_NGROK_4018) — added and sourced to ngrok's own CLI docs and a reproduced GitHub issue showing the failure. (Source: ngrok Agent CLI docs, runatlantis/atlantis#4218)
Added: exact current ngrok pricing table (Free/Hobbyist/Pay-as-you-go/Enterprise), pulled directly from ngrok's live pricing page rather than a general claim of "$0–$49/month." (Source: ngrok.com/pricing)
Added: confirmation and citation for the split license — MIT for tunnelmole-client, AGPLv3 for tunnelmole-service, plus the existence of a commercial licensing option. (Source: tunnelmole-service README)
Added: new "Two Things the Marketing Copy Tends to Skip" section covering (1) that the hosted Tunnelmole service does not hide your IP — it adds an X-Forwarded-For header and embeds IP in generated URLs — and (2) that telemetry (Node version, OS, crash reports) is collected by default with an opt-out env var. Neither fact appeared in the original draft. (Source: tunnelmole-client README/FAQ)
Added: clarification that tunnelmole-service has no native HTTPS support and requires a separate Nginx + Let's Encrypt setup for self-hosted HTTPS, plus the fact that the official hosted service runs the open-source code plus closed-source billing code and added HTTPS infrastructure — so self-hosted and hosted are not byte-identical. (Source: tunnelmole-service README)
Corrected: original draft implied npm install -g tunnelmole needs no Node version consideration; the actual requirement per the client README is Node.js 16.10+ specifically for the npm installation path (the precompiled binary/install script route has no such requirement since Node is bundled in). (Source: tunnelmole-client README)
Added: install-script and Windows binary installation methods as alternatives to npm, which the original draft omitted entirely. (Source: tunnelmole-client README)
Retained, verified accurate: self-hosting steps (git clone, cp config-instance.example.toml config-instance.toml, npm start) match the current tunnelmole-service README exactly. (Source: tunnelmole-service README)
Retained, verified accurate: programmatic ESM/CommonJS usage example matches the current tunnelmole-client README's documented API. (Source: tunnelmole-client README)

rathole vs. frp vs. ngrok: What the Benchmarks Actually Show

InstaTunnel — Tue, 21 Jul 2026 04:04:17 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
rathole vs. frp vs. ngrok: What the Benchmarks Actually Show
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

ngrok vs rathole: The Rust-Based Performance King for Self-H: quick answer
If free tunnel limits interrupt your workflow, compare session length, stable URLs, concurrent tunnels, and paid-plan pricing before choosing a localhost tunnel tool.

What free tunnel limits should developers check first?
Check session duration, URL stability, concurrent tunnels, custom subdomains, bandwidth or request limits, and whether webhook callbacks survive restarts.

How does InstaTunnel handle longer development sessions?
InstaTunnel Free is designed around 24-hour sessions, with Pro available for higher limits and MCP endpoint tunnel workflows.

CGNAT and IPv4 exhaustion have made “just open a port on your router” a non-option for most home connections and a lot of cloud deployments too. If you’re testing webhooks, running a homelab service, or managing remote IoT devices, you need something to broker the NAT traversal for you. Three names come up constantly in that conversation: ngrok, frp, and the newer Rust entrant, rathole. Here’s what each one actually does, and — since a lot of the enthusiasm around rathole online is copy-pasted from the same few sources — what the numbers behind the claims actually say.

ngrok: convenient, centralized, and still bandwidth-capped
ngrok’s pitch hasn’t changed: run one command, get a public HTTPS URL pointing at your local server, no server of your own required. That convenience comes from routing your traffic through ngrok’s edge network, which is also where its limitations live.

As of 2026, ngrok’s free tier caps you at 1 GB of bandwidth per month with a single active endpoint, and it reassigns a random .ngrok-free.app subdomain every time you restart the agent — a real problem if you’re pointing a webhook at it. Free-tier HTML traffic also gets an interstitial warning page (skippable via an API header, but not for browser-facing demos). Custom subdomains require a paid plan, starting at the Personal tier ($8/month, 5 GB, then $0.10/GB overage), up through Pro ($20/month, 15 GB) and Enterprise ($39/month), with pay-as-you-go usage-based pricing available from $18/month for production workloads.

The more structural limitation is protocol support: ngrok still has no native UDP tunneling, at any tier. That rules it out for game servers, VoIP, and IoT protocols like CoAP or MQTT-over-UDP variants — you’re limited to HTTP, HTTPS, TCP, and TLS. Where ngrok remains genuinely strong is the stuff around the tunnel: request replay, traffic inspection, webhook verification, OAuth/SAML/OIDC gating, and a polished API for managing tunnel lifecycle — none of which frp or rathole attempt to replicate.

frp: mature, actively developed, and larger than either alternative
frp (Fast Reverse Proxy), written in Go, is the long-standing self-hosted option: you run frps on a VPS with a public IP and connect frpc from behind the NAT. It’s worth being precise about frp’s current state, because a lot of “frp is bloated and insecure” framing online is several years stale.

frp is under very active development — v0.70.0 shipped July 11, 2026, and the project sits at roughly 106,000+ GitHub stars with about 15,000 forks, an order of magnitude larger than any Rust alternative in this space. TLS encryption has been enabled by default since v0.50.0, and modern configs use TOML, YAML, or JSON (the old INI format is deprecated). Authentication supports both static tokens and OIDC.

On the “clients can open arbitrary ports” security concern: that’s true only in the sense that frp doesn’t restrict port binding out of the box. The server config supports an allowPorts directive that whitelists which port ranges a client is permitted to bind, plus a maxPortsPerClient cap — but it’s opt-in, not the default. If you deploy frp without setting allowPorts, a client with a valid token can indeed request any port on the server. That’s a real operational gotcha worth flagging in any frp deployment guide, though it’s a config oversight rather than an architectural flaw.

The garbage-collection critique is architecturally real — Go’s GC does introduce non-deterministic pause behavior that a GC-less language avoids by construction — but it’s worth weighing against the fact that frp has scaled to hundreds of thousands of production deployments with that architecture. Whether GC pauses matter to your use case depends heavily on your traffic pattern, not just the language choice.

rathole: genuinely fast, but essentially unmaintained since 2023
This is the section where the “dethroning” narrative needs the most correction. rathole, originally built by GitHub user rapiz1 and now maintained under the rathole-org organization, is a Rust reverse proxy explicitly built as a leaner alternative to frp: TCP/UDP forwarding only, no built-in web server, no load balancer, no plugin system.

The maintenance status matters more than the benchmarks. rathole’s most recent tagged release, v0.5.0, shipped October 1, 2023. As of this writing (mid-2026), that’s just under three years without a new release, and it’s an active enough concern that rathole’s own user community has openly asked whether a better-maintained alternative has since emerged. The repository sits at 13.9k stars and 791 forks — a real, respected project, but roughly a tenth the size and community of frp, and without frp’s release cadence. That’s not disqualifying for a hobby project on a Raspberry Pi, but it’s a meaningfully different risk profile than “the modern standard” framing implies, especially for anything you’d call production infrastructure.

What rathole does deliver, factually:

Small binary. The official build guide gets the compiled binary down to roughly 500 KiB for embedded targets — genuinely tiny, and a real advantage on flash-constrained routers.
Mandatory per-service tokens. Every service on both client and server needs its own token; there’s no “trust by default” equivalent to frp’s un-whitelisted port binding.
Noise Protocol support, as an alternative to TLS, avoiding certificate management entirely.
Hot-reloadable config — services can be added or removed without restarting the process.
Configuration
rathole’s actual config format (from the project’s own documentation) is TOML-based, split between client and server files:

Server (server.toml, on your public VPS):

[server]
bind_addr = "0.0.0.0:2333" # Port rathole listens on for the client

[server.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know"
bind_addr = "0.0.0.0:5202" # Public port exposing the service
Client (client.toml, behind the NAT):

[client]
remote_addr = "myserver.com:2333"

[client.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Must match the server
local_addr = "127.0.0.1:22"
Run ./rathole server.toml on the VPS and ./rathole client.toml on the local host, and ssh myserver.com:5202 reaches the NAS. The token-per-service model is the one clear security improvement over frp’s default configuration.

The benchmark everyone cites — and its actual caveats
The numbers behind “rathole crushes frp under load” are real, but they come from a single source: rathole’s own docs/benchmark.md, dated December 28, 2021, run on one machine (an Arch Linux box with a dual Xeon E5-2620 and 16 GB RAM), comparing an early rathole development commit against frp v0.38.0 — a version roughly 30 releases behind frp’s current v0.70.0. It’s also a loopback benchmark, which the rathole docs themselves note reflects CPU-bound performance rather than real network conditions.

With those caveats stated, here’s the actual latency table from that benchmark, using vegeta to generate HTTP load against both proxies:

QPS rathole latency frp latency
1 2.113 ms 2.55 ms
1000 1.723 ms 1.742 ms
2000 1.845 ms 1.749 ms
3000 2.064 ms 2.011 ms
4000 2.569 ms 7,907 ms
Up to 3,000 QPS the two are essentially indistinguishable. At 4,000 QPS, frp 0.38.0 fell over hard in this specific test, while rathole’s latency barely moved. That’s a genuinely dramatic result, and it’s the origin of essentially every “rathole is faster” claim you’ll see repeated across blogs and forums. What none of those repeats mention is that nobody appears to have re-run this comparison against a current frp release, on different hardware, or under real (non-loopback) network conditions in the years since. Treat the throughput ceiling as “true for a 2021 frp binary in one lab,” not as a settled verdict on the current codebases.

The memory comparison from the same benchmark run is more straightforwardly credible: under a sustained vegeta attack -duration 30s -rate 1000, frp’s memory footprint grows substantially larger than rathole’s, consistent with what you’d expect from a garbage-collected runtime buffering connections versus Rust’s ownership-based allocation. This is the argument that holds up best for rathole on genuinely resource-constrained hardware — a 128 MB OpenWrt router or a $3/month VPS is far more likely to hit an OOM-killer event under frp’s memory profile than rathole’s.

Noise Protocol: what it actually replaces, and who else uses it
Both TLS and the Noise Protocol Framework solve the same problem — encrypting the tunnel between client and server — but Noise skips the certificate authority model entirely in favor of pre-shared or exchanged static keys. rathole’s default Noise pattern is Noise_NK_25519_ChaChaPoly_BLAKE2s.

Noise is a real, credible framework, not a rathole-specific invention: WireGuard’s handshake is built on Noise’s IKpsk2 pattern, and WhatsApp uses Noise for its client-to-server transport encryption. Slack has also used Noise-based implementations. One correction worth making here: Signal’s messaging protocol (X3DH plus the Double Ratchet algorithm) is a different, older design — despite some conceptual lineage, Signal does not use the Noise Protocol Framework, so it shouldn’t be cited alongside WireGuard and WhatsApp as a Noise adopter.

Where each tool actually fits
ngrok — you want a public URL in ten seconds, you don’t want to run a VPS, and UDP isn’t a requirement. Its request-inspection and webhook-debugging tooling remains the most polished of the three, and that’s the real reason to pay for it.

frp — you want a self-hosted, actively developed tool with a large community, HTTP/TCP/UDP support, load balancing, and dashboards, and you’re willing to explicitly configure allowPorts and keep the default TLS enabled rather than relying on defaults alone.

rathole — you’re running on genuinely memory-constrained hardware (an OpenWrt router, a 512 MB VPS) where rathole’s small footprint and per-service tokens are a real win, and you’re comfortable with the fact that you’re depending on a project that hasn’t tagged a release in close to three years. That’s a reasonable trade for a homelab; it’s a much harder sell for anything you’d call production infrastructure without a plan for what happens if a security issue surfaces and nobody ships a fix.

Changelog
Removed all SEO-style framing, unstated “market share” and “violently disrupted” claims, and the “Ini, TOML” code-fence label artifacts that had leaked into the body text of the original draft.
Corrected the central narrative: the original draft presented rathole as actively “dethroning” frp. In fact, rathole’s last tagged release was v0.5.0 on October 1, 2023 (~13.9k GitHub stars, 791 forks), while frp shipped v0.70.0 on July 11, 2026 and has roughly 106k+ stars and 15k forks — frp is both larger and far more actively maintained. (rathole releases, frp releases)
Verified and re-sourced the QPS/latency benchmark table (previously stated without attribution) directly against rathole’s own docs/benchmark.md, and added the missing context that it dates to December 28, 2021, used frp v0.38.0 (now ~30 releases out of date), ran on a single lab machine, and was a loopback test — not an independent or current benchmark. (rathole benchmark.md)
Corrected the frp security claim: frp does support an opt-in allowPorts whitelist and maxPortsPerClient limit to restrict client port binding, and has shipped with TLS enabled by default since v0.50.0 — the original draft implied no such controls exist. (frp GitHub, frp config reference)
Corrected the binary size claim from a vague “well under 1MB” to the sourced, specific figure of ~500 KiB from rathole’s own build documentation.
Corrected the Noise Protocol adopter list: removed Signal (which uses the separate X3DH/Double Ratchet-based Signal Protocol, not Noise) and confirmed WireGuard (Noise_IKpsk2 pattern), WhatsApp (client-server transport), and Slack as actual Noise adopters. (Noise Protocol Framework overview, Wikipedia: Noise Protocol Framework)
Corrected and updated ngrok free-tier specifics with current, sourced figures: 1 GB/month bandwidth, 1 active endpoint, random subdomain per restart, no native UDP support at any tier, and current pricing tiers (Personal $8/mo, Pro $20/mo, Enterprise $39/mo, pay-as-you-go from $18/mo). (ngrok pricing/limits summary, ngrok blog on static domains)
Replaced the fabricated TOML configuration example with rathole’s actual documented client/server config syntax and field names, sourced from the project README.
Softened the “Go’s GC vs. Rust’s zero-cost abstractions” framing from an absolute claim into a stated architectural trade-off, noting frp’s GC-based design hasn’t prevented large-scale production adoption.
Rewrote the conclusion to reflect the maintenance-status finding: rathole is recommended for constrained hobbyist hardware with an explicit caveat about its stale release cycle, rather than positioned as the general-purpose “modern standard.”
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
InstaTunnel CLI download
Install or update the CLI for Windows, macOS, Linux, npm, and release binaries.
Plans and limits
Compare Free, Pro, and Business limits for tunnels, MCP endpoints, bandwidth, and teams.
Related Topics

ngrok vs rathole, rathole reverse proxy, rust reverse proxy, frp alternative, ngrok alternative, self hosted reverse proxy, rathole vs frp, rathole vs ngrok, nat traversal tool, noise protocol encryption, low latency proxy, bare metal performance proxy, self host local tunnel, rust networking tools, rust based reverse proxy, embedded device proxy, raspberry pi proxy, low end vps tunneling, low memory reverse proxy, fast nat traversal, secure nat traversal, open source reverse proxy, self hosted tunneling, rust performance proxy, benchmark local tunnels, rathole configuration, tcp proxy rust, local server to internet, expose localhost free, port forwarding rust, secure reverse proxy rust, high performance tunnel, bypass nat rust, self hosted local tunnel, best frp alternative, best ngrok alternative, rust ecosystem networking, reverse proxy for raspberry pi, low memory tunnel, native noise encryption, reverse proxy embedded systems, rust rathole github, replace frp with rathole, replace ngrok with rathole, rust tunneling tool, reverse tunnel open source, raw performance proxy, lightweight ingress proxy, bare metal networking, self managed proxy tool

ngrok vs. Expose: Comparing an Enterprise Ingress Platform to a Web-First PHP Tunnel

InstaTunnel — Mon, 20 Jul 2026 04:03:08 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
ngrok vs. Expose: Comparing an Enterprise Ingress Platform to a Web-First PHP Tunnel
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

ngrok vs Beyond Code's Expose: The Open-Source Tunnel : quick answer
If free tunnel limits interrupt your workflow, compare session length, stable URLs, concurrent tunnels, and paid-plan pricing before choosing a localhost tunnel tool.

How does InstaTunnel handle longer development sessions?
InstaTunnel Free is designed around 24-hour sessions, with Pro available for higher limits and MCP endpoint tunnel workflows.

If you build APIs, integrate webhooks from providers like Stripe, Shopify, or GitHub, or need to show work-in-progress to a client, you’ve run into the same problem: a server running on localhost is invisible to the outside world. Tunneling tools solve this by running a lightweight client on your machine that opens an outbound connection to a remote server, which then assigns a public URL and routes incoming traffic back down the tunnel.

For over a decade, ngrok has been the default answer. But its free tier has gotten measurably tighter in 2026, and one of the tools independent developers are reaching for instead is Beyond Code’s Expose — an open-source, PHP-native tunnel built specifically for the web development workflow rather than as a generic network transport.

This piece breaks down what each tool actually does today, with current pricing, limits, and installation steps checked against primary documentation rather than recycled blog claims.

Why you need a tunnel
A few recurring cases come up constantly in web development:

Webhook testing — Stripe, GitHub, and similar services need a public URL to deliver events to your local API.
Mobile app testing — an iOS or Android emulator (or a physical device) needs an endpoint to talk to your local backend.
Client demos — showing the latest state of a site without deploying to staging.
ngrok: the incumbent
ngrok was originally created in March 2013 by Alan Shreve, who built it as an exercise in learning Go. It has since grown well past a simple tunneling utility. Today its own pricing page frames it as a full ingress platform, and the free tier still ships with capabilities that used to be paid add-ons elsewhere: HTTPS tunnels, a web-based traffic inspector with request replay, ngrok SDKs, a Kubernetes Operator, remote agent management, circuit breaking, and automatic TLS. On the identity side, the free plan supports OAuth/SAML/OIDC traffic identities for up to 3 monthly active users, and load balancing is available under the name “endpoint pooling.”

What’s actually restricted on the free plan
Checked directly against ngrok’s current documentation, the free-tier limits are:

Resource Free tier limit
Data transfer out 1 GB/month
HTTP/S requests Up to 20,000/month
Online endpoints Up to 3
Concurrent agents 3
TCP connections Up to 5,000/month
HTTP request rate 4,000/min
Custom/vanity domains Not available — dev domain only
A few points that get misrepresented a lot in third-party comparison posts are worth being precise about:

No session timeout. The free tier does not impose timeouts on endpoints — you can run it continuously as a background service. Claims of a “2-hour session limit” on the free plan don’t match ngrok’s own documentation.
The interstitial page is real, but narrower than commonly described. ngrok injects an interstitial warning page in front of HTML browser traffic on the free tier to deter phishing abuse; once a visitor clicks through, a cookie suppresses the page for that domain for 7 days. Critically, this does not affect programmatic or API access to your endpoint — so it doesn’t actually break automated webhook delivery from services posting to your endpoint directly. It’s a friction point for browser-based demos, not for machine-to-machine traffic. It can also be removed on the free tier itself by sending a ngrok-skip-browser-warning header or a custom User-Agent, without upgrading.
Current paid tiers
The free plan includes $5 of one-time included usage and no usage beyond that credit. Above free:

Hobbyist — $8/month billed annually ($10/month billed monthly), with $10 of monthly included usage, up to 3 online endpoints, 5GB data transfer included, 100k HTTP/S requests included, and no interstitial page. Domains are ngrok-branded, not fully custom.
Pay-as-you-go — $20/month base with $20 of included usage, unlimited online endpoints, unlimited data transfer and requests beyond the included amounts (billed as overage), and support for bringing your own domain.
Enterprise — contact sales; SSO/SAML, SCIM, SLAs, HIPAA BAAs, and SOC 2 documentation are available here.
(Note: “Personal” is an older plan name that no longer appears on ngrok’s current pricing page — the equivalent tier today is Hobbyist.)

Expose: a web-first, open-source alternative
Expose is built and maintained by Marcel Pociot at Beyond Code — the team also behind Laravel Herd and Tinkerwell. Unlike ngrok’s Go binary, Expose’s core is open source and written in PHP, and it’s scoped narrowly: it shares HTTP/HTTPS traffic for anything reachable on your own machine. It doesn’t attempt to be a generic TCP/UDP transport the way ngrok is.

As of mid-2026, the project is active: the GitHub repository has 4.6k stars and 309 forks, is MIT-licensed, and its latest release, 3.2.2, shipped March 27, 2026.

Installing Expose
The currently documented install paths are:

PHP Archive (PHAR) — the primary documented method:

curl https://github.com/exposedev/expose/raw/master/builds/expose -L --output expose
chmod +x expose
sudo mv expose /usr/local/bin/expose
Via Composer:

composer global require exposedev/expose
Make sure your global Composer bin directory is on your PATH. Expose ships as a compiled binary but still requires PHP to be installed locally to run.

Laravel Herd: if you already use Laravel Herd, Expose is available in your terminal out of the box — you just need to set your token.

Authenticating and sharing a site
expose token YOUR_TOKEN
Then, from a project directory:

expose share http://localhost:8000
If your local sites resolve at a .test domain (as with Laravel Herd or Valet), you can skip the URL entirely and just run expose from inside the project directory. A local request dashboard is available for inspecting and replaying traffic, similar in spirit to ngrok’s localhost:4040 inspector.

Reserved/custom subdomains are gated behind a paid tier: passing --subdomain requires either your own self-hosted Expose server or an Expose Pro/Team account — on the free plan you get a new random subdomain on every connection.

Current Expose pricing
Pulled directly from expose.dev:

Tier Price Includes
Hobby Free TLS/SSL encryption, time-limited connections, random URLs, single EU server
Pro $79 per user per year No time limit, access control, persistent URLs, custom domains and subdomains, reserved subdomains, global server network
Team $229 per team per year, for up to 10 users Everything in Pro, plus priority support
The “global server network” on Pro/Team spans seven regions: EU (Frankfurt), US (New York and San Francisco), Asia Pacific (Singapore), India (Bangalore), South America (São Paulo), and Australia (Sydney), selectable via expose servers and --server.

Self-hosting
This is still the differentiator most developers cite. The self-hosted version of Expose lets you run the server on your own infrastructure, giving you full control over your data with no third-party servers involved, plus support for your own custom domains and SSL. A basic DigitalOcean Droplet still starts at $4/month as of mid-2026, which is enough to run a self-hosted Expose server with effectively no bandwidth cap beyond what the VPS provider allows — no interstitial page, and no dependency on Beyond Code’s hosted infrastructure at all.

Laravel ecosystem integration
Expose has two separate integration points worth distinguishing:

Laravel Herd (Beyond Code’s own local environment for macOS and Windows) has a native Expose integration built in, letting you share a site with a single command or click. The auth token can be set through Herd’s settings UI rather than the CLI.
Laravel Valet (Taylor Otwell’s separate, community-maintained tool) also supports sharing via either ngrok or Expose, selected through the share-tool config command; Valet will prompt to install whichever tool you choose via Homebrew (ngrok) or Composer (Expose).
Feature comparison
Feature ngrok (Free / Hobbyist) Expose (Hobby / Pro)
Primary use case Generic network transport; enterprise API/K8s ingress Web developer local environments (HTTP/S only)
Language Go PHP
Free-tier bandwidth 1 GB/month Not published as a hard cap; time-limited connections instead
Free-tier requests 20,000/month Not published as a hard cap
Custom domains Paid only (Hobbyist: ngrok-branded; Pay-as-you-go: bring your own) Paid only (Pro: $79/user/yr) or free via self-hosting
Protocols HTTP/S, TCP, TLS HTTP/S only
Browser interstitial on free tier Yes, bypassable via header/user-agent; doesn’t affect API traffic No
Request inspection dashboard Yes (localhost:4040) Yes
Open source No Yes (MIT, client and server)
Self-hosting Not applicable (managed only) Yes, fully documented
When each one makes sense
Stick with ngrok if: - You need raw TCP/TLS tunneling (databases, SSH, game servers, IoT) — Expose is HTTP/S only. - You need Kubernetes ingress, SSO/SAML at the org level, or SOC 2/HIPAA documentation for compliance. - You’d rather not have a PHP runtime as a dependency for a networking tool.

Consider Expose if: - Your traffic is exclusively HTTP/HTTPS and you want to avoid the free-tier interstitial page for browser-facing demos. - You’re already in the PHP/Laravel ecosystem, especially on Laravel Herd, where Expose is a first-class integration. - You want custom domains without a per-seat annual fee, and are willing to run and maintain your own small VPS.

Conclusion
The two tools aren’t solving quite the same problem anymore. ngrok has expanded into a broader ingress and API gateway platform, and its free tier — while genuinely capped at 1 GB and 20,000 requests a month — is less restrictive on the session/timeout front than a lot of comparison content suggests. Expose stays narrowly focused on HTTP/HTTPS sharing for web developers, trades ngrok’s protocol breadth for a lighter, open-source footprint, and makes self-hosting a real option rather than a workaround. Which one fits depends mostly on whether you need TCP/TLS tunneling and enterprise compliance features (ngrok), or you’re PHP/Laravel-centric and want either a free hosted tier without a warning page or full control via self-hosting (Expose).

Changelog
Corrections and additions made to the original draft, checked against primary sources on July 20, 2026:

ngrok plan names and pricing — Original draft referenced a “Personal/Hobbyist plan at around $8 to $10/month.” Corrected to the current structure: Free ($0, $5 one-time usage credit), Hobbyist ($8/month billed annually, $10/month billed monthly, 5GB/100k requests included), Pay-as-you-go ($20/month base + metered overage), Enterprise (contact sales). “Personal” no longer appears as a plan name on ngrok’s pricing page. Source: ngrok Pricing page.
Free-tier session limits — Original draft stated free sessions are “tightly constrained, meaning long-running background tunnels require frequent manual intervention.” ngrok’s own documentation states explicitly that free-tier endpoints have no timeout and can run indefinitely as a background service. Source: ngrok Free Plan Limits documentation.
Interstitial page scope — Original draft claimed the interstitial “completely breaks automated webhook payloads.” ngrok’s documentation states the interstitial does not affect API or programmatic access, and can additionally be bypassed on the free tier via the ngrok-skip-browser-warning header or a custom User-Agent, without upgrading. Source: ngrok Free Plan Limits documentation.
ngrok free-tier feature list — Added a verified list of what’s actually included free (Kubernetes Operator, circuit breaking, OAuth/SAML traffic identities, endpoint pooling/load balancing, automatic TLS) in place of a generic “enterprise-grade” description. Source: ngrok Free Plan Limits and Pricing pages.
Expose install command — Original draft used composer global require beyondcode/expose. Current official documentation lists the PHAR download as the primary install method and gives the Composer package as exposedev/expose. Source: Expose Installation documentation.
Expose Pro/Team pricing — Original draft described Expose Pro only in general terms (“flat subscription,” “predictable pricing”) with no figures. Added current concrete pricing: Pro at $79/user/year, Team at $229/team/year for up to 10 users, plus the Hobby (free) tier’s actual restrictions (time-limited connections, single EU server, random URLs). Source: expose.dev pricing page.
Custom subdomain gating — Clarified that the --subdomain flag is explicitly a Pro/Team (or self-hosted) feature, not available on the free Hobby tier. Source: Expose Sharing documentation.
Global server regions — Added the specific list of seven Pro/Team server regions (EU, two US regions, Asia Pacific, India, South America, Australia), which the original draft didn’t specify. Source: Expose Global Server Infrastructure documentation.
Laravel integration detail — Original draft only mentioned Laravel Valet’s valet share support. Added that Beyond Code’s own Laravel Herd ships with a native Expose integration configurable through its settings UI, which is a more directly relevant integration point than Valet given Beyond Code builds both tools. Valet’s support (via share-tool expose, requiring a Composer install) is retained and confirmed as still current. Source: Expose Authentication documentation; Laravel Valet documentation (11.x).
Project activity/health — Added current GitHub repository stats (4.6k stars, 309 forks, MIT license, latest release 3.2.2 dated March 27, 2026) to establish the project is actively maintained in 2026, which the original draft didn’t substantiate. Source: GitHub — exposedev/expose.
Self-hosting cost estimate — Verified the $4/month VPS figure against current DigitalOcean Basic Droplet pricing; confirmed accurate as of mid-2026. Source: DigitalOcean pricing coverage, July 2026.
ngrok founding facts — Confirmed and cited: ngrok was created in March 2013 by Alan Shreve as a Go-learning project. Source: Ngrok, Inc. history (Wikitia); Twilio blog interview.
Removed unverifiable marketing language from the original draft (e.g., “the web developer’s darling,” “stealing web developers from ngrok,” generic SEO framing and repeated bolded value propositions) in favor of neutral, comparative technical language.
Protocol scope — Confirmed Expose’s documentation only describes HTTP/HTTPS sharing, with no TCP/UDP tunneling commands present anywhere in current docs, supporting the original draft’s claim that Expose can’t handle raw TCP traffic.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
InstaTunnel CLI download
Install or update the CLI for Windows, macOS, Linux, npm, and release binaries.
Plans and limits
Compare Free, Pro, and Business limits for tunnels, MCP endpoints, bandwidth, and teams.
Related Topics

ngrok vs expose, beyond code expose, expose vs ngrok, ngrok alternative, open source ngrok alternative, best ngrok alternative for web developers, php tunneling tool, laravel tunneling tool, expose local web server, share local sites securely, self hosted tunnel free, bypass ngrok free tier, ngrok domain limits, local http dashboard, inspect incoming http requests, replay http requests, modify http headers, web developer tunnel, php ngrok alternative, laravel ecosystem tools, open source reverse proxy, free tunnel for localhost, expose php binary, beyond code tools, share localhost to internet, secure tunnel for web developers, ngrok paid features free, expose pro tier, self host expose server, open source tunneling software, web hooks local testing, expose localhost free, expose local site, local dev environment sharing, webhook inspection tool, free ngrok premium features, managed tunnel service, custom domains local tunnel, beyond code php, laravel web development tools, web app testing tunnel, localhost sharing tool, secure localhost tunnel, expose cli, web testing proxy, local server to internet, unmetered custom domains tunnel, php reverse proxy, laravel local sharing, web traffic inspector, http request replay tool, http header modifier, alternative to ngrok for web developers

ngrok vs. Expose: The Open-Source PHP Tunnel Built for Web Developers

InstaTunnel — Sun, 19 Jul 2026 03:55:40 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
ngrok vs. Expose: The Open-Source PHP Tunnel Built for Web Developers
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

How does InstaTunnel handle longer development sessions?
InstaTunnel Free is designed around 24-hour sessions, with Pro available for higher limits and MCP endpoint tunnel workflows.

If you build APIs, wire up webhooks from Stripe, Shopify, or GitHub, or need to hand a client a working preview without deploying to staging, you’ve almost certainly reached for ngrok at some point. For over a decade it’s been the default answer to “how do I share my localhost?”

But ngrok’s product has changed shape. It has grown from a simple developer utility into a full ingress and API gateway platform, and its free tier reflects that shift. That’s opened space for narrower, developer-focused alternatives — one of the more established ones being Expose, an open-source PHP tunnel built by Beyond Code (the makers of Laravel Herd and Tinkerwell).

This piece compares the two tools as they actually stand today, not as they’re often described in older blog posts.

(Note: this is Expose by Beyond Code, not LocalXpose, a separate cross-protocol tunneling tool covered elsewhere on this site. Different products, similar-sounding names.)

Why local tunnels exist
A local server (http://localhost:8000) isn’t reachable from the internet — that’s the correct default. But it becomes a problem the moment you need:

Webhooks: Stripe, GitHub, and similar services need a public URL to POST events to.
Mobile testing: a phone or emulator needs a real endpoint to talk to your local backend.
Client demos: showing work in progress without a deploy step.
Tunneling tools solve this by running a client on your machine that opens an outbound connection to a relay server. That server hands you a public URL and forwards traffic back down the tunnel to your local port.

ngrok: the incumbent
Created in 2013 by Alan Shreve and written in Go, ngrok is the tool most developers learned tunneling on. It has since repositioned itself as what its own marketing calls a “universal gateway” — offering Kubernetes ingress via its own operator, traffic policy rules (WAF, OAuth/OIDC, SAML), endpoint pooling for load balancing, and SOC 2/HIPAA compliance for enterprise customers. It supports HTTP, HTTPS, TCP, and (on paid plans) TLS traffic, which is why it’s still the right tool for tunneling something that isn’t a web server — an SSH session, a game server, a database port.

What the free tier actually restricts (and what it doesn’t)
ngrok’s current published limits for the free plan:

Resource Free tier limit
Online endpoints Up to 3
Data transfer out 1 GB/month
HTTP/S requests 20,000/month
TCP connections 5,000/month (requires card verification to enable TCP at all)
TLS endpoints Not available
Team members 1
A few corrections to claims that circulate about the free tier:

There is no 2-hour session timeout. ngrok’s own documentation states plainly that the free tier has no timeout on endpoints, and that you can run a tunnel indefinitely as a background service. This gets repeated as fact in a lot of comparison articles; it isn’t accurate as of ngrok’s current docs.
The free-tier URL is not random on every restart. Every ngrok account — free included — gets one assigned “dev domain” (like your-name.ngrok-free.app) that’s tied to the account, not regenerated per session. You can’t customize it or add your own domain on the free plan, but it doesn’t rotate the way older write-ups describe.
The interstitial warning page can be bypassed without upgrading. ngrok injects a security interstitial in front of HTML traffic on free-tier endpoints to deter phishing abuse. It doesn’t affect programmatic API/webhook traffic at all, and for browser traffic it can be skipped by sending an ngrok-skip-browser-warning header or a non-default User-Agent — no paid plan required. Upgrading removes it entirely, but it’s not a hard blocker on the free plan the way it’s sometimes portrayed.
What genuinely is restrictive: 1 GB of monthly transfer and 20,000 requests disappear fast on anything with real traffic, and TCP tunnels need card verification even for free use.

Current paid pricing
ngrok simplified its plan names. As of now there’s no “Personal” tier — it’s Free, Hobbyist, Pay-as-you-go, and Enterprise:

Hobbyist — $8/month billed annually ($10 month-to-month): 3 online endpoints, 5 GB data transfer included, 100,000 requests included, no interstitial, ngrok-branded domains.
Pay-as-you-go — $20/month base (includes $20 of usage) plus metered overage: unlimited online endpoints, bring-your-own domain, unlimited team members (3 included).
Enterprise — custom pricing, SSO/SCIM, HIPAA BAAs, dedicated support.
Expose: the PHP-native alternative
Expose is built by Marcel Pociot and the Beyond Code team (also behind Laravel Herd and Tinkerwell). Unlike ngrok, it’s written entirely in PHP and scoped deliberately to HTTP/HTTPS — it doesn’t do raw TCP or UDP, and it isn’t trying to be a Kubernetes ingress controller. It’s aimed at exactly the workflow this blog covers a lot of: local web dev, webhook testing, client previews.

It’s genuinely open source (MIT license, client and server both), which is the core differentiator from ngrok.

Installation
Current official installation methods, per Expose’s own docs:

Composer (global install):

composer global require exposedev/expose
Make sure your global Composer bin directory is on your PATH.

PHP Archive (PHAR), no Composer required:

curl https://github.com/exposedev/expose/raw/master/builds/expose -L --output expose
chmod +x expose
sudo mv expose /usr/local/bin/expose
One thing worth flagging clearly: Expose still requires a local PHP installation even when installed as the PHAR “binary” — Beyond Code’s own FAQ confirms this. If you’re not already running PHP for other reasons, that’s a real dependency ngrok’s single Go binary doesn’t have.

The project’s GitHub organization moved from beyondcode to exposedev; the older beyondcode/expose Composer package still exists and is updated, but the docs now point to exposedev/expose.

Authentication and sharing a site
expose token YOUR_TOKEN
expose share http://localhost:8000
If you have a Pro or Team account (or run your own server), you can request a fixed subdomain:

expose share http://localhost:8000 --subdomain=my-awesome-app
The dashboard
Expose ships a local web dashboard (http://127.0.0.1:4040, same convention as ngrok) for inspecting and replaying incoming HTTP requests. Expose 3, the current major version, added a few things worth knowing about if you haven’t looked at it recently:

Replay with modification — you can now edit headers, the URI, or the payload before replaying a captured request, not just resend it as-is.
Request Plugins — Expose can recognize specific webhook formats (GitHub and Paddle Billing ship built-in) and surface the relevant payload fields directly in the dashboard and CLI instead of making you dig through raw JSON.
Vite detection — if you share a site while a Vite dev server is running, Expose now detects it and routes the Vite tunnel automatically, fixing a long-standing annoyance where hot-reloaded CSS/JS would silently break over a shared tunnel.
catch-all command — spins up a tunnel that returns 200 OK to anything, useful for quickly inspecting a webhook payload without having an endpoint implemented yet.
Self-hosting vs. the managed free tier — an important distinction
This is where a lot of comparison write-ups oversimplify. “Expose is open source, so you get everything for free” isn’t quite right unless you’re self-hosting the server yourself.

Expose’s own free (“Hobby”) managed tier comes with real constraints, per Beyond Code’s docs: a single server location (their EU data center), randomized tunnel names on every connection, and a time limit per connection. That’s a meaningfully different deal from ngrok’s free tier, which gives you a stable per-account domain with no timeout.

Self-hosting the open-source server is genuinely free and removes those constraints — you control the domain, there’s no time limit, and you’re only bound by your own infrastructure’s bandwidth. But it does mean standing up and maintaining your own server (a basic VPS from a provider like Hetzner or DigitalOcean is enough for the job), which is a real ongoing responsibility, not a one-time setup.

Expose Pro and Team (the paid managed tiers) sit in between: persistent URLs, custom domains, reserved subdomains, and Beyond Code’s global server network, without you running anything yourself.

Current published pricing:

Plan Price What you get
Hobby Free Single EU server, random tunnel names, connection time limit
Self-hosted Free (your infra cost) Full control, custom domain, no time limit, your bandwidth
Pro $79/user/year Persistent URLs, custom domains, reserved subdomains, global server network, no time limit
Team $229/team/year Everything in Pro, up to 10 users, priority support
Laravel integration, corrected
A common claim is that Expose “replaced ngrok as the default” in Laravel Valet. That’s not accurate — Valet 4+ supports three interchangeable share tools (ngrok, expose, and cloudflared), selected explicitly via valet share-tool . ngrok remains Valet’s default unless you switch it.

Where Expose does have a tighter, more current integration is Laravel Herd, Beyond Code’s own modern local-dev environment (successor to Valet, available for macOS and Windows): Expose ships built into Herd, and you can set your Expose auth token directly from Herd’s settings UI rather than the CLI.

Feature comparison
Feature ngrok Expose
Primary use case Generic network ingress; enterprise API gateway Web dev HTTP/HTTPS tunneling
Language / runtime Go (single binary) PHP (PHAR still requires local PHP)
Protocols HTTP/S, TCP, TLS (paid) HTTP, HTTPS only
Open source No Yes (MIT, client + server)
Free tier bandwidth/requests 1 GB / 20,000 requests per month Not capped by volume, but single server + time-limited connections
Free tier URL One persistent dev domain per account Random subdomain per connection
Webhook interstitial Yes on free tier (bypassable via header without upgrading) None
Request inspection Local dashboard, replay Local dashboard, replay with edits, webhook-aware Request Plugins
Custom domains Paid plans only ($8–10/mo+) Free if self-hosted, or Pro ($79/user/year)
Kubernetes / enterprise ingress Yes (built-in operator, SSO/SCIM, HIPAA) Not a target use case
When each tool makes sense
Stick with ngrok if: - You need to tunnel something that isn’t HTTP — SSH, a database port, a game server, raw TCP/TLS. - You need Kubernetes ingress, SSO/SAML, or compliance paperwork (HIPAA BAAs, SOC 2 reports). - You’d rather not have PHP as a dependency on a machine that otherwise has none.

Consider Expose if: - Your work is HTTP/webhook-shaped and you’re already in a PHP/Laravel environment (Herd, Valet, Sail). - You want a genuinely free, unlimited setup and are willing to self-host the open-source server on your own VPS. - The webhook-aware dashboard (GitHub/Paddle payload detection, Vite auto-routing) fits how you actually debug integrations.

Neither tool has “won” here — they’re solving overlapping but distinct problems, and the honest comparison depends more on whether you need raw TCP/enterprise ingress (ngrok’s territory) or a lean, self-hostable HTTP tunnel with a PHP-native workflow (Expose’s territory).

Changelog
Corrections and additions made to the original draft, with sources:

Removed the “2-hour session timeout” claim for ngrok’s free tier. ngrok’s Free Plan Limits documentation explicitly states the free tier has no endpoint timeouts and supports running as a background service indefinitely. (Source: ngrok docs, Free Plan Limits)
Corrected the “random URL that changes on restart” claim. ngrok assigns one dev domain per account, not a new random one each session; this has been the case since ngrok’s domain changes around 2023. (Source: ngrok docs, Free Plan Limits — “Development domain… specific to your account”)
Corrected the framing of the interstitial page as an unavoidable paid-upgrade issue. It can be bypassed on the free tier via the ngrok-skip-browser-warning header or a custom User-Agent, and doesn’t affect API/webhook traffic at all. (Source: ngrok docs, Free Plan Limits — “Removing the interstitial page”)
Updated ngrok plan names and pricing. Removed the outdated “Personal” tier name; current tiers are Free, Hobbyist ($8/mo annual, $10/mo monthly), Pay-as-you-go ($20/mo + usage), and Enterprise. (Source: ngrok.com/pricing)
Corrected the Composer install command for Expose. Docs now specify composer global require exposedev/expose (the project’s GitHub org moved from beyondcode to exposedev); added the PHAR-based install method as an alternative. (Source: expose.dev/docs/getting-started/installation)
Added the fact that Expose’s PHAR “binary” still requires a local PHP installation — it isn’t a fully standalone binary the way ngrok’s is. (Source: expose.dev FAQ)
Corrected Expose’s pricing structure. Replaced the vague “flat subscription” description with actual current tiers: Hobby (free, restricted), Pro ($79/user/year), Team ($229/team/year, up to 10 users). (Source: expose.dev pricing page)
Added an important caveat the original draft omitted: Expose’s own free “Hobby” managed tier has real restrictions — randomized tunnel names per connection, a connection time limit, and a single EU server. The “get everything for free” pitch only holds if you self-host the open-source server yourself. (Source: expose.dev/docs/getting-started/authentication)
Corrected the Laravel Valet integration claim. Valet did not make Expose “the default,” replacing ngrok — Valet 4+ offers ngrok, Expose, and cloudflared as interchangeable, explicitly-selected share tools, with ngrok remaining the default. (Sources: laravel.com/docs Valet documentation; Laravel Valet 4.0 release notes)
Replaced the Valet reference with Laravel Herd, Beyond Code’s own current local-dev environment, which has a more direct, built-in Expose integration (token configuration from the Herd settings UI). (Source: expose.dev/docs/getting-started/authentication)
Added new, verified content on Expose 3.0, the current major version: the redesigned dashboard, replay-with-modification, webhook-aware Request Plugins (GitHub, Paddle Billing), automatic Vite tunnel detection, and the catch-all command. (Source: expose.dev/docs/release-notes)
Removed unverifiable/soft claims from the original draft (e.g., an exact “$4/month VPS” figure for self-hosting) in favor of general, defensible language about typical low-cost VPS providers.
Stripped SEO-style headline, meta-description language, and promotional framing (“stealing web developers from ngrok,” etc.) from the original draft.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
InstaTunnel CLI download
Install or update the CLI for Windows, macOS, Linux, npm, and release binaries.
Plans and limits
Compare Free, Pro, and Business limits for tunnels, MCP endpoints, bandwidth, and teams.
Related Topics

ngrok vs expose, beyond code expose, expose vs ngrok, ngrok alternative, open source ngrok alternative, best ngrok alternative for web developers, php tunneling tool, laravel tunneling tool, expose local web server, share local sites securely, self hosted tunnel free, bypass ngrok free tier, ngrok domain limits, local http dashboard, inspect incoming http requests, replay http requests, modify http headers, web developer tunnel, php ngrok alternative, laravel ecosystem tools, open source reverse proxy, free tunnel for localhost, expose php binary, beyond code tools, share localhost to internet, secure tunnel for web developers, ngrok paid features free, expose pro tier, self host expose server, open source tunneling software, web hooks local testing, expose localhost free, expose local site, local dev environment sharing, webhook inspection tool, free ngrok premium features, managed tunnel service, custom domains local tunnel, beyond code php, laravel web development tools, web app testing tunnel, localhost sharing tool, secure localhost tunnel, expose cli, web testing proxy, local server to internet, unmetered custom domains tunnel, php reverse proxy, laravel local sharing, web traffic inspector, http request replay tool, http header modifier, alternative to ngrok for web developers

ngrok vs. sish (The Self-Hosted Serveo): How to Build Your Own Private ngrok Using sish and a $5 VPS

InstaTunnel — Sat, 18 Jul 2026 07:46:18 +0000

IT
InstaTunnel Team
Published by the InstaTunnel team | Editorial policy
ngrok vs. sish (The Self-Hosted Serveo): How to Build Your Own Private ngrok Using sish and a $5 VPS
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

ngrok vs sish: Build Your Own Private Self-Hosted Serveo: quick answer
If free tunnel limits interrupt your workflow, compare session length, stable URLs, concurrent tunnels, and paid-plan pricing before choosing a localhost tunnel tool.

How does InstaTunnel handle longer development sessions?
InstaTunnel Free is designed around 24-hour sessions, with Pro available for higher limits and MCP endpoint tunnel workflows.

In modern software development, exposing your local development environment to the public internet is a daily necessity. Whether you are testing webhooks, showcasing a work-in-progress to a client, or debugging a complex API integration, you need a reliable tunnel. For years, developers defaulted to third-party tools like ngrok or Serveo. However, as team sizes grow and security requirements tighten, relying on managed tunneling services can introduce bottlenecks, costs, and security compliance headaches.

If ngrok’s free-tier limits, rate limiting, or the unpredictable uptime of free alternatives like Serveo have ever frustrated you, it might be time to take control of your infrastructure. Enter sish, an open-source, actively maintained alternative that lets you build your own private version of localhost.run or Serveo — or, as of this year, simply use its official managed service instead of self-hosting at all.

In this guide, we’ll walk through the current state of SSH tunneling, compare ngrok and sish accurately against both projects’ own documentation, and provide a step-by-step tutorial for standing up your own private ngrok using sish and a $5 VPS.

The Evolution of Localhost Tunneling
The Reign of ngrok
When developers think of localhost tunneling, ngrok is usually the first name that comes to mind. It revolutionized the way we expose local servers. By running a simple command (ngrok http 8080), you instantly receive a public HTTPS URL forwarding traffic to your local machine.

ngrok’s free tier is genuinely limited, but not in the way most comparison articles describe it. As of ngrok’s own current pricing and limits documentation, the Free plan includes:

A one-time $5 usage credit
Up to 3 online endpoints and 3 concurrent agents
1 GB of data transfer per month
20,000 HTTP/S requests per month, capped at roughly 4,000 requests/minute
5,000 TCP/TLS connections per month
One automatically assigned “dev domain” (e.g. your-name.ngrok-free.app)
An interstitial warning page shown to browser visitors on free HTTP/S endpoints (bypassable by sending an ngrok-skip-browser-warning header or a non-default User-Agent — no upgrade required)
A common myth worth correcting: many “ngrok alternative” marketing blogs claim the free tier now enforces a hard 2-hour session timeout. ngrok’s own documentation directly contradicts this — free-tier endpoints have no timeout and can run indefinitely as a background service. The actual constraints are the monthly data, request, and connection caps above, plus the inability to reserve a custom domain and the interstitial page. Treat any article citing a “2-hour limit” with skepticism.

Paid tiers have also been restructured. The current lineup (per ngrok’s pricing and limits pages) is:

Plan Price Data transfer Requests Endpoints
Free $0 1 GB/mo 20k/mo 3
Hobbyist $8/mo (annual) or $10/mo 5 GB/mo 100k/mo 3
Pay-as-you-go $20/mo base (includes $20 usage credit) Metered ($0.10/GB) Metered ($1/100k) Unlimited
Enterprise Custom / quote-only Custom Custom Custom
Aside from cost, some corporate networks also restrict or flag ngrok traffic by default, since its shared domains have historically been abused for phishing and malware command-and-control — a security posture problem independent of pricing.

The Rise and Fall of Serveo
As an alternative to ngrok’s proprietary agent, developers flocked to Serveo. Serveo was notable because it required no installation — it leveraged the standard SSH client already installed on almost every developer’s machine. Running ssh -R 80:localhost:8080 serveo.net would instantly return a public URL.

Serveo became a go-to for free SSH tunneling, but its open, unauthenticated nature made it a magnet for phishing and malware abuse. This led to recurring blacklisting and outages. Serveo’s uptime today is still inconsistent — third-party uptime monitors show it flipping between “up” and “down” depending on region and time, consistent with a lightly-maintained free service rather than a reliably available one. It’s still reachable intermittently, but it’s not something to depend on for anything production-adjacent.

Enter sish: The Open-Source Successor
sish, created by developer Antonio Mika, is the open-source community’s answer to the gap Serveo left. It’s an actively maintained project — currently on release v2.23.0 (June 2026), with roughly 4.6k GitHub stars, 329 forks, and 64 tagged releases — and is now sponsored by pico.sh, the SSH-powered developer tools project Mika also maintains.

Unlike Serveo, which existed only as a public service, sish is explicitly designed to be self-hosted on your own infrastructure. It runs as an SSH server that forwards traffic back to connected clients.

One important update since sish’s earlier days: you no longer have to self-host it at all if you don’t want to. The project now offers an official managed service at tuns.sh, maintained by the same team, as the fastest way to try sish without touching a VPS:

ssh -R 80:localhost:8080 tuns.sh
This instantly creates a public URL for something running on local port 8080 — no signup, no client install. Self-hosting remains the better option for teams that need custom domains, private tunnels, or full control over data residency, which is what the rest of this guide covers.

The Superpower of sish
What makes sish stand out in the crowded field of tunneling tools?

Protocol support: sish handles HTTP, HTTPS, TCP, WS (WebSockets), and WSS connections, plus SNI-based TLS routing without terminating the TLS connection itself.
No client installation: Just like Serveo, sish uses the native SSH client (ssh -R). Your team doesn’t need any proprietary CLI tools or agents.
TLS certificates: sish can serve HTTPS either from certificates you provide yourself, or by requesting them on demand from Let’s Encrypt (--https-ondemand-certificate), or — if you use the official Docker Compose deployment — fully automated wildcard certificates via DNS-01 challenges through the bundled dnsrobocert container.
Multiplexing: sish supports wildcard subdomains, letting multiple developers request their own subdomains on the fly (e.g., dev1.yourdomain.com, api-test.yourdomain.com).
Security and auth, on by default: As of the current release, sish requires SSH authentication by default (public key or password) — it is no longer an “open by default, secure it later” tool. You configure who’s allowed in before anyone can open a tunnel, not after.
Private TCP aliases and load balancing: Beyond public tunnels, sish supports internal-only TCP aliases (reachable only via authenticated SSH jump-host access), plus optional load-balancing modes so multiple clients can share the same HTTP, TCP, or SNI endpoint.
Traffic inspection: An optional admin console and per-tunnel service console let you inspect forwarded requests — closing some of the gap with ngrok’s traffic inspector, without sending your traffic through a third party.
ngrok vs. sish: Which is Right for You?
Feature ngrok (SaaS) sish (Self-Hosted or Managed)
Architecture Managed third-party service Self-hosted on your infrastructure, or use the official tuns.sh managed service
Client software Requires the ngrok CLI agent Uses native SSH (ssh command)
Custom domains Requires Hobbyist plan or higher Free on self-hosted; bring your own domain
Cost Free (limited) up to $20/mo base + usage on Pay-as-you-go ~$5/month VPS + domain, or free via tuns.sh for quick tests
Data privacy Traffic routes through ngrok’s cloud Traffic routes through your own VPS (self-hosted)
Rate limits 1GB/20k requests (Free), 5GB/100k (Hobbyist), metered beyond that None inherent to sish; bounded only by your VPS bandwidth
Endpoint timeout None (a common myth says otherwise) None
Auth by default Account-based (SaaS) SSH key/password auth required by default since recent releases
Setup time Instant Instant via tuns.sh; ~15–30 minutes for self-hosted VPS setup
Maintenance None (managed for you) Minimal (OS and container updates) for self-hosted; none via tuns.sh
When to choose ngrok: you want a polished, fully managed experience with built-in traffic inspection and don’t mind the free tier’s data/request ceilings, or you need enterprise features like SSO and audit logs.

When to choose sish: you have a team that wants persistent custom subdomains without SaaS fees, you handle data that shouldn’t route through a third party, or you want unmetered bandwidth bounded only by your own VPS.

How to Build Your Own Private ngrok Using sish and a $5 VPS
Prerequisites
A Cloud VPS: a basic $5/month instance from DigitalOcean, Linode, Vultr, or Hetzner is sufficient. Choose Ubuntu 22.04 LTS or 24.04 LTS.
A domain name (e.g., my-tunnels.com) to route traffic to your VPS.
Basic terminal knowledge with SSH and the command line.
Your local machine’s SSH public key (usually ~/.ssh/id_ed25519.pub) — you’ll need this up front, since sish now requires authentication from the start.
Step 1: Configure Your DNS Records
For sish to route traffic dynamically to different subdomains, set up a wildcard DNS record. In your domain registrar’s DNS panel, create two A records pointing to your VPS’s public IP:

Primary record: Host my-tunnels.com (or @) → your VPS IP
Wildcard record: Host *.my-tunnels.com → your VPS IP
DNS propagation can take anywhere from a few minutes to a few hours.

Step 2: Prepare Your VPS (Install Docker)
SSH into your VPS:

ssh root@your_vps_ip
Update packages:

sudo apt update && sudo apt upgrade -y
Install Docker via the official script:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
docker --version
Step 3: Deploy sish, Secured From the Start
Older sish guides had you deploy with authentication off and lock it down in a later step. That’s no longer the recommended flow — recent sish releases require SSH authentication by default, so the secure setup and the working setup are now the same step.

Create the required directories and drop your public key in before you start the container:

mkdir -p ~/sish/ssl ~/sish/keys ~/sish/pubkeys
cp ~/.ssh/id_ed25519.pub ~/sish/pubkeys/
Pull the current image and run it, substituting your own domain:

docker pull antoniomika/sish:latest

docker run -itd --name sish \
--restart always \
-v ~/sish/ssl:/ssl \
-v ~/sish/keys:/keys \
-v ~/sish/pubkeys:/pubkeys \
--net=host antoniomika/sish:latest \
--ssh-address=:2222 \
--http-address=:80 \
--https-address=:443 \
--https=true \
--https-certificate-directory=/ssl \
--authentication-keys-directory=/pubkeys \
--private-keys-directory=/keys \
--bind-random-ports=false \
--domain=my-tunnels.com
A few notes on these flags: * --net=host binds the container directly to the host’s network interfaces for accurate client IP logging. * --ssh-address=:2222 avoids conflicting with your VPS’s own SSH daemon on port 22. * --authentication-keys-directory=/pubkeys points sish at the folder it should watch for authorized keys; it reloads automatically when you add or remove files, no restart needed. * --bind-random-ports=false lets clients request specific TCP ports instead of always getting a random one. * This basic setup expects certificates already present in /ssl (for example via certbot). If you want sish to fetch Let’s Encrypt certificates on demand itself, add --https-ondemand-certificate --https-ondemand-certificate-accept-terms; for fully automated wildcard certs via DNS challenge, use sish’s official Docker Compose deployment instead, which bundles the dnsrobocert container for that purpose.

Check the logs to confirm it started cleanly:

docker logs -f sish
Step 4: Test Your New Private ngrok
From your local machine — not the VPS — with a local server running on port 3000:

ssh -p 2222 -R 80:localhost:3000 my-tunnels.com
Because your public key is already trusted, this connects immediately and returns an HTTPS URL such as:

Press Ctrl-C to close the session.
Forwarding to:
https://randomstring.my-tunnels.com
Requesting a Custom Subdomain
ssh -p 2222 -R custom-name:80:localhost:3000 my-tunnels.com
This attempts to bind https://custom-name.my-tunnels.com, as long as that subdomain isn’t already claimed by another user on your server.

Managing Developer Access
Because the pubkeys directory is watched continuously, adding or removing a teammate’s access is just a file operation — no restart required:

nano ~/sish/pubkeys/new_teammate.pub

paste their public key, save

A convenient shortcut for onboarding via GitHub-hosted keys:

curl https://github.com/their-github-username.keys > ~/sish/pubkeys/their-github-username
Advanced sish Use Cases

Bypassing Firewalls with TCP Tunnels sish isn’t limited to HTTP/HTTPS. To expose a local MySQL instance (port 3306) to a remote client:

ssh -p 2222 -R 3306:localhost:3306 my-tunnels.com
Your remote client connects to my-tunnels.com:3306 and traffic routes securely to your local database.

Private TCP Aliases (No Public Exposure at All) For access patterns that shouldn’t be internet-facing even behind auth, sish supports TCP aliases reachable only through an authenticated SSH jump host — nothing is bound publicly:

ssh -p 2222 -R mylaptop:22:localhost:22 my-tunnels.com
A teammate with access can then reach it via:

ssh -J my-tunnels.com mylaptop

Team-Wide Integration Standardize the tunnel command into your team’s package.json or Makefile:

"scripts": {
"start": "react-scripts start",
"tunnel": "ssh -p 2222 -R $(whoami)-dev:80:localhost:3000 my-tunnels.com"
}
When Alice runs npm run tunnel, she gets alice-dev.my-tunnels.com; Bob gets bob-dev.my-tunnels.com.

CI/CD Pipeline Testing
Since sish only needs a standard SSH client, it’s straightforward to integrate into GitHub Actions or GitLab CI — spin up a temporary app instance, tunnel it through your sish server, and run end-to-end tests against the public URL before tearing it down.
Load Balancing and SNI Routing
If your use case grows beyond a single developer’s tunnel, sish’s optional load-balancer modes (--http-load-balancer, --tcp-load-balancer, --sni-load-balancer) let multiple clients share the same bound domain, port, or SNI hostname — useful for basic multi-instance failover without standing up a separate load balancer.

Summary
ngrok’s polish and traffic-inspection tooling remain genuinely useful, and its free tier — while capped on data and requests, not session length — is a reasonable way to kick the tires. But for teams that want control, data privacy, and predictable costs, self-hosting has gotten easier, not harder: sish now ships secure by default, offers a managed tuns.sh option for zero-setup testing, and has grown features (TCP aliases, SNI proxying, load balancing, traffic consoles) that narrow the gap with commercial tunneling platforms.

By investing about $5 a month and 20 minutes of setup time, you can run a private, custom-branded tunneling server that your whole team controls.

Changelog
This article was rewritten from a submitted draft and fact-checked against primary sources on July 18, 2026.

Corrections: 1. Removed the “ngrok free-tier 2-hour session timeout” claim entirely and added an explicit correction. ngrok’s own Free Plan Limits documentation states free-tier endpoints have no timeout and can run as a background service indefinitely; the real constraints are monthly data/request/connection caps. Source: ngrok.com/docs/pricing-limits/free-plan-limits. 2. Updated ngrok’s pricing structure, which the original draft only described in general terms. Current tiers per ngrok’s own pricing/limits docs: Free ($0, $5 one-time credit, 3 endpoints, 1GB/20k requests monthly), Hobbyist ($8/mo annual or $10/mo, 5GB/100k requests, still 3-endpoint cap), Pay-as-you-go ($20/mo base including $20 usage credit, unlimited endpoints, metered overage), Enterprise (custom/quote-only). Source: ngrok.com/docs/pricing-limits. 3. Corrected the sish Docker deployment flow. The original draft’s “Step 5: secure your server” pattern (deploy with --authentication=false, then lock it down later) no longer matches sish’s current defaults: the --authentication flag now defaults to true, meaning sish requires SSH auth out of the box. The tutorial was restructured to place your public key in ~/sish/pubkeys before first launch rather than deploying an open relay first. Source: docs.ssi.sh/cli and docs.ssi.sh/getting-started. 4. Updated the Docker run command to match the current officially documented example, which adds --private-keys-directory=/keys and --bind-random-ports=false flags not present in the original draft. Source: github.com/antoniomika/sish (README) and docs.ssi.sh/getting-started. 5. Corrected the Let’s Encrypt automation claim. The plain docker run deployment does not automatically provision Let’s Encrypt certificates on its own — it expects certificates already present in the mounted /ssl directory unless you add the --https-ondemand-certificate flag, or use sish’s official Docker Compose deployment, which bundles the dnsrobocert container specifically for automated wildcard DNS-01 certificates. Source: docs.ssi.sh/getting-started.

Additions (not in the original draft): 6. Added sish’s official managed service, tuns.sh, as a zero-setup option for trying sish without a VPS. Source: github.com/antoniomika/sish, docs.ssi.sh/getting-started. 7. Added current project stats and status: sish is at release v2.23.0 (June 2026), ~4.6k GitHub stars, 329 forks, 64 tagged releases, and is sponsored by pico.sh. Source: github.com/antoniomika/sish. 8. Added coverage of sish’s private TCP alias feature (SSH jump-host access with no public binding) and its optional HTTP/TCP/SNI load-balancer modes, neither of which appeared in the original draft. Source: docs.ssi.sh/cli, github.com/antoniomika/sish. 9. Added sish’s admin/service console feature for inspecting forwarded traffic, as a self-hosted parallel to ngrok’s traffic inspector. Source: docs.ssi.sh/cli. 10. Softened the Serveo reliability claim to reflect current, mixed uptime-monitor reports rather than presenting a specific characterization of its downtime, since third-party monitors show it as intermittently reachable rather than consistently down. Source: aggregated third-party uptime monitors (isitdownorjustme.net, notopening.com), cross-checked July 2026.

Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
InstaTunnel CLI download
Install or update the CLI for Windows, macOS, Linux, npm, and release binaries.
Plans and limits
Compare Free, Pro, and Business limits for tunnels, MCP endpoints, bandwidth, and teams.
Related Topics

ngrok vs sish, sish vs ngrok, sish, ngrok alternative, best ngrok alternative, free ngrok alternative, self hosted ngrok, self hosted ngrok alternative, serveo alternative, self hosted serveo, open source ngrok alternative, open source serveo alternative, ssh tunneling, ssh reverse tunnel, secure shell tunnel, local tunneling tool, private ngrok, build private ngrok, $5 vps proxy, cheap vps tunnel, self hosted tunneling service, private tunneling tool, route local traffic, expose localhost via ssh, bypass third party infrastructure, team ssh tunneling, standard ssh commands, port forwarding ssh, open source reverse proxy, self host webhooks, dynamic subdomain routing, automatic let's encrypt, custom domains proxy, http tunnel, https tunnel, tcp tunnel, websocket tunnel, ws tunnel, wss tunnel, sish github, sish tutorial, install sish vps, ngrok pricing alternative, ngrok limits bypass, local development server sharing, forward ports ssh, private localhost.run, self managed tunnel, ssh client port forwarding, secure tcp tunnel, websockets reverse proxy, let's encrypt ssl tunnel, custom domain ssh tunnel, web development tunneling tools, devops ssh tools, host internal apps public, self hosted url generator, persistent ssh tunnel, local environment proxy, bypass ngrok paywall

ngrok vs. localhost.run (The Zero-Friction Standard)

InstaTunnel — Fri, 17 Jul 2026 04:35:27 +0000

IT
InstaTunnel Team
Published by our engineering team
ngrok vs. localhost.run (The Zero-Friction Standard)
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

ngrok vs localhost.run: Zero-Friction Native SSH Tunneling : quick comparison answer
Choose the tunnel tool based on the network model: public HTTPS URLs for webhooks and demos, private mesh access for internal apps, and managed infrastructure when policy controls matter most.

Which tunnel tool is best for public webhook testing?
Use a public HTTPS localhost tunnel with stable URLs. InstaTunnel focuses on webhook testing, demos, OAuth callbacks, and MCP endpoint workflows.

When should I choose a private network tool instead?
Choose a private mesh or Zero Trust tool when every user and service should stay inside a controlled private network.

Every time a developer complains about having to create an ngrok account, generate an authentication token, and download a binary just to share a quick preview of a local environment, localhost.run enters the chat.

For the better part of a decade, exposing a local development server to the public internet meant exactly one thing: reaching for ngrok. Whether you were testing Stripe webhooks, building Slack bots, or sharing a staging link with a client, ngrok was the undisputed default. But as we move deeper into 2026, the developer ecosystem is experiencing an aggressive shift toward minimalism. The patience for account walls, binary installations, and stringent free-tier limits has worn thin.

Developers are increasingly gravitating toward agentless, clientless tools that leverage the software already installed on their machines. At the forefront of this movement is localhost.run, a tool that champions the “zero-friction” approach by completely abandoning custom binaries in favor of native SSH tunneling.

This article explores the technical mechanics, limits, and architectural philosophies behind ngrok and localhost.run, examining exactly why the zero-friction standard is taking over.

The Evolution of Localhost Exposure
To understand the shift, we must look at why these tools exist in the first place. Modern development machines sit behind NAT (Network Address Translation) routers and stringent firewalls. They are purposefully isolated from the public internet.

When you boot up a local server on http://localhost:8080, it is bound to your local loopback interface. If a third-party API (like GitHub or Stripe) needs to send a POST request to your machine to trigger a local debugging session, it cannot reach your local IP. Historically, solving this meant diving into your router settings to configure port forwarding and setting up dynamic DNS.

Reverse proxy tunnels solved this by establishing an outbound connection from your local machine to a publicly accessible cloud server. Because the connection is initiated outbound, your firewall allows it. The cloud server then acts as a relay, capturing incoming public traffic and funneling it back through the established tunnel to your local port.

The Rise of the Heavyweight: ngrok
ngrok popularized this pattern. It provided a polished, easy-to-use binary that abstracted away the networking complexities. You simply downloaded the executable, ran ngrok http 8080, and immediately received a public URL.

However, as ngrok evolved into a comprehensive API gateway and enterprise ingress controller, its onboarding friction increased. In 2026, using ngrok requires signing up for an account, retrieving an authtoken, and saving that token to your local configuration file.

One thing worth updating from the “random URL” reputation ngrok used to have: as of a January 2026 platform update, every free account is automatically assigned a persistent dev domain the moment the account is created, rather than a URL that changes on every restart. These dev domains aren’t billed against endpoint-hour usage and don’t count toward the domain limits on paid plans — though they’re still distinct from a fully custom or branded domain, which remains a paid feature.

The free tier itself has also become noticeably restrictive. Free users are currently capped at 1 GB of outbound data transfer per month, up to 3 concurrently online endpoints, and 20,000 HTTP/S requests per month. TCP endpoints are available on the free plan, but only after verifying the account with a credit card.

Crucially, to combat phishing, ngrok injects a mandatory interstitial warning page in front of all HTML browser traffic on its free tier. Anyone clicking your shared link must manually acknowledge a warning before seeing your work — unless the request includes an ngrok-skip-browser-warning header, or the visitor has already clicked through once (the resulting cookie suppresses the page for seven days). For developers trying to quickly share a pristine UI preview with stakeholders, this interstitial screen is still a common UX roadblock.

A persistent myth worth killing here: the widely repeated claim that ngrok’s free tier disconnects after a fixed session length (often cited as a “2-hour timeout”) doesn’t hold up against ngrok’s own documentation. There is no such session timeout — an endpoint stays online for as long as the agent process is running. The real constraints are the monthly data, request, and concurrent-endpoint caps described above.

The Zero-Friction Challenger: localhost.run
In stark contrast, localhost.run strips the tunneling process down to its barest essentials. It operates on a fundamentally different philosophy: you already have a secure, battle-tested tunneling client installed on your computer.

Every major operating system today — macOS, Linux, and Windows 10⁄11 — ships with OpenSSH built in. localhost.run leverages this native SSH client to create the tunnel. There is no binary to download, no account to create, and no configuration file to manage for basic usage.

To expose a local server running on port 8080, you simply open your terminal and execute:

ssh -R 80:localhost:8080 nokey@localhost.run
The moment you press enter, the service provisions a public URL and prints it to your terminal, complete with an automatically generated TLS certificate. The friction from thought to execution is virtually zero.

Under the Hood: The Mechanics of Native SSH Tunneling
To appreciate why localhost.run is so elegant, it helps to understand what the SSH command is actually doing.

ssh: Invokes the native OpenSSH client on your machine.
-R 80:localhost:8080: This is the crucial flag. -R stands for Remote Port Forwarding. It tells the SSH client to open a port (80) on the remote server (localhost.run) and forward any traffic it receives back through the encrypted tunnel to localhost:8080 on your local machine.
nokey@localhost.run: This specifies the user (nokey, a special username that skips SSH-key verification for free, ephemeral tunnels) and the host server (localhost.run).
Because OpenSSH handles connection multiplexing, encryption, and keep-alives natively, localhost.run doesn’t need to maintain its own daemon or client software. It simply runs a hardened SSH server configured to act as a reverse proxy, accepting incoming SSH connections and bridging them to public HTTP endpoints.

This architecture makes localhost.run uniquely suited for temporary environments, CI/CD pipelines, and remote servers where installing a third-party binary like ngrok introduces unnecessary security reviews or pipeline bloat.

Head-to-Head Comparison: ngrok vs. localhost.run
While localhost.run wins on speed and onboarding, tunneling is not a one-size-fits-all requirement. Let’s break down how these two tools compare across the most critical developer vectors in 2026.

Installation and Onboarding ngrok: Requires a multi-step onboarding process. You must navigate to their website, create an account, verify your email, download the OS-specific binary, extract it, move it to your system $PATH, and authenticate it using a command like ngrok config add-authtoken . Only then can you start a tunnel.

localhost.run: Requires zero installation. You do not need to visit a website or create an account for the free tier. You simply type the SSH command into any standard terminal. For developers setting up automated scripts or working on fresh machine installs, this agentless approach is a real advantage.

Traffic Inspection and Observability ngrok: This is where ngrok justifies its “heavyweight” status. When you run the agent, it spins up a built-in local web interface (typically at http://127.0.0.1:4040). This dashboard captures every HTTP request and response traversing the tunnel — headers, payloads, query parameters, and response times, in real time. The web inspector and its one-click Replay feature are both included free on every plan, including Free. If you’re debugging a complex webhook payload from Shopify, you don’t need to trigger a new event on Shopify’s end; you can just replay the exact captured payload against your local server.

localhost.run: Provides no built-in traffic observability. Because it operates purely at the transport layer via SSH, it simply pipes bytes from the cloud to your local port. If you want to inspect headers or replay webhooks, you have to rely on your application’s own logging, your browser’s DevTools, or a secondary local proxy. For heavy API debugging, this remains a real trade-off.

Free Tier Limits and Quotas (2026 Landscape) ngrok Free Tier Constraints: - Bandwidth: 1 GB outbound data transfer per month. - Requests: Up to 20,000 HTTP/S requests per month. - Endpoints: Up to 3 concurrently online endpoints. - Browser interstitial: Forces a manual click-through warning page for HTML browser traffic (bypassable with a request header, or by upgrading to a paid plan). - Domains: An auto-assigned dev domain is included free; fully custom/branded domains require a paid plan.

localhost.run Free Tier Constraints: - Speed: localhost.run’s own documentation confirms free-tier tunnels are deliberately speed-limited, specifically to discourage the domains from being used for phishing. It’s workable for API testing and text-heavy HTML, but large asset downloads or video streaming will bottleneck. - Domain stability: Free tunnels are assigned a domain that rotates periodically; a stable domain requires either an SSH key on file or the paid Custom Domain plan. - Custom domains: Like ngrok, a stable branded domain requires a paid subscription.

Pricing for Premium Features ngrok Pricing (2026): ngrok’s entry paid tier is now called Hobbyist, priced at $8/month billed annually (or $10/month billed monthly). It includes a monthly usage credit, up to 3 online endpoints, 5 GB of included bandwidth, 100,000 included HTTP/S requests, a custom ngrok-branded subdomain (e.g., yourcompany.ngrok.app), and it removes the interstitial warning page entirely.

Beyond that sits Pay-as-you-go, which replaced the old flat-rate “Pro” tier: a $20/month base fee that includes $20 of usage credit, with additional data transfer, endpoint-hours, and requests metered beyond that. This tier removes the endpoint cap entirely, allows a fully custom bring-your-own domain, and unlocks add-ons like SSO/RBAC, SCIM provisioning, wildcard endpoints, and mutual TLS for larger teams.

localhost.run Pricing: localhost.run’s paid offering is simpler: a single Custom Domain subscription priced at $9/month, billed annually. This removes the speed throttling, gives you a stable domain (your own domain or a subdomain of lhr.rocks), and grants priority bandwidth on the underlying system. It requires uploading an SSH key to the localhost.run admin console for authentication — no proprietary token involved.

Security Posture: Binaries vs. SSH Keys
In an era of supply chain attacks and strict Zero Trust enterprise policies, the security architecture of your tunneling tool matters deeply.

Downloading a pre-compiled binary like ngrok requires implicit trust in the vendor’s build pipeline. The ngrok agent runs as a persistent process on your machine, managing its own encrypted connections and authenticating via a proprietary authtoken. While ngrok is highly reputable and widely audited, heavily regulated enterprise environments often block unapproved third-party binaries from executing or establishing outbound tunnels — and increasingly, endpoint detection platforms will flag unsigned tunneling CLIs on sight.

localhost.run utilizes standard OpenSSH. From a security team’s perspective, SSH is a known, auditable, standard protocol. To authenticate with localhost.run’s paid features (like custom domains), you don’t use a proprietary token; you use your existing SSH public/private key pair (e.g., id_rsa or ed25519). This allows developers to integrate tunneling directly into existing SSH-agent workflows.

However, because localhost.run relies on OS-level SSH configuration, misconfigurations in your local ~/.ssh/config can occasionally cause connection drops or key exchange issues.

The Trade-off: When to Use Which?
The debate between ngrok and localhost.run is not about finding an objective winner; it’s about choosing the right tool for the specific phase of your development lifecycle.

Choose ngrok if: - You’re debugging webhooks: The ability to inspect incoming payloads and replay them with a single click in the local dashboard remains close to a necessity for serious API integration work. - You’re running persistent demo environments: If you need a stable, long-running tunnel with high reliability for a client showcase, ngrok’s edge infrastructure is more robust. - You need advanced ingress features: ngrok’s paid tiers offer OAuth, IP restrictions, and mutual TLS directly at the edge, letting you secure a local preview without writing auth code into your app.

Choose localhost.run if: - You want zero installation: If you’re jumping onto a fresh machine, working inside a constrained Docker container, or writing a quick bash script, the native SSH approach is hard to beat. - You’re sharing pristine UI previews: Because localhost.run doesn’t inject a warning interstitial page, you can share links with non-technical clients who might be confused by ngrok’s mandatory security screens. - You’re building automated AI-agent workflows: In 2026, AI coding agents frequently need to expose local ports to verify functionality. Prompting an agent to run a native SSH command is simpler and less error-prone than instructing it to download, authenticate, and configure a third-party binary.

Conclusion
The developer tooling landscape in 2026 is defined by a real intolerance for unnecessary friction. While ngrok remains a genuinely powerful edge gateway and observability tool, its transition into a heavier enterprise product has left room at the lower end of the market.

For developers who simply need to get a local port onto the internet right now, localhost.run has carved out a real niche as the zero-friction option. By recognizing that the best client is often the one you don’t have to install, it makes the case that the most useful solution is sometimes just leveraging the native tools already on your machine.

Changelog
Structural/formatting changes: - Reformatted into clean Markdown; removed the SEO subtitle/tagline beneath the title. - No other front-matter or tracking metadata was present in the source draft.

Corrections to existing claims: 1. ngrok tier naming and current structure. The draft’s “Personal” tier no longer exists under that name. As of 2026 it’s called Hobbyist: $8/month billed annually ($10/month billed monthly), not “$8/month” flat with no monthly-billing distinction. Source: ngrok Pricing and Limits docs, ngrok blog — Static dev domains for all ngrok users (Jan 8, 2026 update). 2. ngrok Hobbyist bandwidth. The draft claimed the paid tier “increases bandwidth allowance to 10 GB per month.” The current documented figure is 5 GB included on Hobbyist, not 10 GB. Source: ngrok pricing/limits documentation, cross-checked against multiple current third-party pricing trackers. 3. ngrok “Pro” tier. The flat “$20/month Pro tier” described in the draft has been restructured into Pay-as-you-go: a $20/month base fee that includes $20 of usage credit, with metered overage beyond that, rather than a flat-rate tier with fixed higher limits. Source: ngrok Pricing and Limits documentation. 4. The “2-hour session timeout” myth. Not present in the original draft’s specific wording, but added as a proactive correction since this is one of the most common misconceptions in tunneling comparison content: ngrok’s own documentation confirms free-tier endpoints have no session timeout — the real limits are the monthly data/request/endpoint caps. Source: ngrok Pricing and Limits documentation; corroborated across multiple 2026 comparison sources. 5. ngrok free dev domains. Added new information not in the original draft: since a January 2026 ngrok platform update, free accounts are automatically assigned a persistent “dev domain” rather than a domain that changes on every restart. Source: ngrok blog — Static dev domains for all ngrok users. 6. ngrok TCP endpoints on Free. Added: TCP endpoints are available on the free plan but require credit-card verification first. Source: ngrok blog (as above). 7. localhost.run pricing. The draft stated pricing “roughly $3.50 to $9 per month depending on the configuration tier.” No lower tier could be verified on localhost.run’s own site; the documented price for the Custom Domain subscription is a single $9/month, billed annually. Source: localhost.run Custom Domains docs, localhost.run homepage. 8. localhost.run free-tier throttling. Confirmed as accurate against localhost.run’s own “Forever Free Tier” documentation, which explicitly states free domains have a speed limit and rotate regularly to deter phishing abuse. 9. SSH command syntax. Confirmed accurate and unchanged: ssh -R 80:localhost:8080 nokey@localhost.run matches localhost.run’s current documentation and homepage exactly.

All other technical explanations (NAT/firewall mechanics, reverse tunnel architecture, the -R flag mechanics, OpenSSH’s default presence on major OSes) were reviewed and left as-is; they describe stable, non-time-sensitive technical facts.

Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
InstaTunnel vs LocalXpose
Compare developer tunnel workflows, stable URLs, webhook testing, and plan fit.
Webhook testing tool
Use stable HTTPS tunnel URLs for provider webhooks, retries, and local callback debugging.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
InstaTunnel CLI download
Install or update the CLI for Windows, macOS, Linux, npm, and release binaries.
Related Topics

ngrok vs localhost.run, localhost.run, ngrok alternative, localhost.run vs ngrok, native ssh tunneling, ssh reverse tunnel, zero friction tunneling, zero installation tunnel, ssh port forwarding, expose localhost via ssh, free ngrok alternative, public url generator, instant public url, no binary tunnel, bypass ngrok binary, developer tunneling tools 2026, ssh -r localhost, localhost to internet ssh, reverse proxy ssh, free ssh tunneling, ngrok bandwidth limits, local server tunneling tool, web development tunneling, easy localhost sharing, share local web server, host local app public, localhost.run bandwidth limits, ngrok web inspection dashboard, ngrok dashboard alternative, mac ssh tunnel, windows ssh tunnel, linux ssh tunnel, zero config reverse proxy, fast local tunnel, local environment preview, ssh client proxy, ssh reverse port forward, webhook testing tool, expose web server ssh, secure tunnel localhost, developer tools 2026, lightweight ngrok alternative, serverless tunneling, terminal ssh tunnel, instant local server sharing, no account tunneling, native operating system tunnel, local server to public domain, ssh client built in, web traffic forwarding, localxpose vs localhost.run, cloud tunneling alternatives, test local applications, bypass local firewall, nat traversal ssh

ngrok vs. Playit.gg: Bypassing CGNAT for Gaming and Real-Time UDP Traffic in 2026

InstaTunnel — Thu, 16 Jul 2026 05:24:33 +0000

IT
InstaTunnel Team
Published by our engineering team
ngrok vs. Playit.gg: Bypassing CGNAT for Gaming and Real-Time UDP Traffic in 2026
Current comparison

Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.

Open the InstaTunnel ngrok alternative guide
Quick answer

ngrok vs Playit.gg: The Ultimate Tunnel for Gaming, UDP & CG: quick answer
If free tunnel limits interrupt your workflow, compare session length, stable URLs, concurrent tunnels, and paid-plan pricing before choosing a localhost tunnel tool.

How does InstaTunnel handle longer development sessions?
InstaTunnel Free is designed around 24-hour sessions, with Pro available for higher limits and MCP endpoint tunnel workflows.

If you’ve ever tried to host a multiplayer game server, test real-time netcode, or expose a local IoT device to the public internet, you’ve hit the wall of port forwarding. For years, developers reached for tunneling tools to get around router configuration. ngrok has long been the household name in that space.

But in 2026, that name recognition doesn’t automatically make it the right tool. For raw, real-time UDP traffic — the backbone of gaming, VoIP, and IoT telemetry — ngrok still has a structural gap, and Playit.gg has built its entire product around filling it.

This guide covers the architectural differences between the two, why UDP support is the real dividing line, how Carrier-Grade NAT (CGNAT) forces this whole conversation in the first place, and what it actually costs to go fully self-hosted with frp or inlets instead.

The UDP Problem: Why ngrok Struggles with Real-Time Traffic ngrok’s HTTP-first architecture ngrok was built to solve a specific problem: exposing local web servers so developers could test webhooks, APIs, and web apps. It’s still excellent at that — request inspection, replay, and webhook verification remain some of the best tooling in the category.

What it has never done is support UDP. As of 2026, ngrok’s tunnel types are still limited to HTTP, HTTPS, TCP, and TLS — there is no UDP endpoint type on any plan, free or paid. This isn’t a rumor or an outdated complaint; it’s confirmed directly in ngrok’s own documentation, and developers have been asking about it in ngrok’s GitHub issues since at least 2013 without it landing.

Why games and IoT actually need UDP
In real-time multiplayer gaming, VoIP, and high-frequency IoT telemetry, perfect delivery matters less than speed.

Multiplayer gaming: Titles like Minecraft Bedrock, Valheim, Rust, and Counter-Strike 2 rely on UDP. If a packet with a player’s position drops, the game doesn’t want it resent a moment later — it wants the next packet with the player’s current position. UDP just keeps firing without waiting for acknowledgment.
VoIP and video: Voice servers and WebRTC-based tools can’t tolerate the latency spikes that come from TCP retransmission.
IoT sensors: Devices sending rapid telemetry over CoAP or custom UDP protocols need low-overhead transmission.
Because ngrok doesn’t support UDP on any tier, these use cases are simply off the table for it — you either bolt on an unstable TCP-to-UDP hack or use a different tool entirely.

Playit.gg: Built for Raw Sockets and Gaming Where ngrok stops, Playit.gg picks up. It was built specifically to handle raw TCP and UDP traffic with minimal setup — no router configuration required.

How it differs architecturally
Playit.gg works closer to Layer 4 than ngrok’s largely Layer 7 (HTTP) model. You run the Playit agent locally; it opens an outbound connection to Playit’s network of relay datacenters (19 datacenters as of mid-2026, spanning North America, Europe, Asia, Oceania, and South America), and that relay forwards traffic back down to your machine.

On the free tier, Playit assigns your tunnel a persistent address (something like your-game.at.ply.gg:xxxxx) that doesn’t rotate every time you restart the client, unlike ngrok’s free-tier random URLs. It’s worth being precise here: free tunnels route over Playit’s “Global Anycast” network, meaning the actual datacenter your players connect through can vary and isn’t something you control — that requires Playit Premium’s regional tunnels, which pin routing to a specific datacenter. So “static” describes the address staying the same, not a fixed single IP with fixed routing underneath.

What’s confirmed directly from Playit.gg: - Premium costs $3/month (or roughly $30/year), confirmed on Playit’s own pricing page. - Premium adds regional tunnels, several .playit.plus/custom domains (sources describe anywhere from 3 to 6 depending on the exact plan tier), external domain support, and additional ports/firewalls/agents. - HTTPS tunnels specifically require Playit Premium — this isn’t available on the free plan, which is worth knowing if you assumed Playit was a general-purpose web tunnel too. - The client agent is open source (playit-cloud/playit-agent on GitHub), which is a legitimate transparency advantage over ngrok’s closed-source client.

What’s widely reported but not something Playit’s own marketing page states as a hard number: independent guides published throughout 2026 (Pinggy, Localtonet, and others) consistently describe the free tier as including 4 TCP tunnels and 4 UDP tunnels, though at least one source describes the free allotment as 3 tunnels. Given the inconsistency between third-party sources, treat “4 TCP + 4 UDP” as the commonly cited figure rather than a number verified on Playit’s own site, and check your account dashboard for your actual current limit.

Demystifying Carrier-Grade NAT (CGNAT) To understand why any of this matters, you need to understand CGNAT.

Historically, hosting a Minecraft server meant logging into your router, opening port 25565, and mapping your home’s public IP directly to your machine. That model depends on your home actually having a public IPv4 address.

The problem: IPv4 only has about 4.3 billion possible addresses, and the regional internet registries exhausted their free pools years ago (ARIN, North America’s registry, ran out in September 2015; RIPE NCC, Europe’s, in November 2019). Since IPv6 adoption is still incomplete — global IPv6 capability sits in roughly the mid-40% range as of 2026, and is very unevenly distributed by country — most ISPs still lean on IPv4, and CGNAT is how they stretch a shrinking supply of addresses across a growing customer base.

Under CGNAT, your ISP assigns your router an address from a reserved private range (RFC 6598’s 100.64.0.0/10 block, specifically set aside for this purpose in 2012) instead of a real public IP, and does the actual internet-facing NAT translation on its own equipment. You end up with two layers of translation — your home router’s NAT, plus the ISP’s CGNAT — a setup sometimes called NAT444. The result: port forwarding on your home router does nothing, because you don’t own the public IP it would need to map to.

How Playit.gg (and ngrok, and most tunnels) get around it
Because the Playit or ngrok client initiates an outbound connection from your machine to the provider’s cloud, your ISP’s NAT allows it through — outbound connections are rarely blocked, even under CGNAT. Once that tunnel exists, inbound traffic from your players gets routed back down it. This is why you can host a server from a 5G hotspot or a CGNAT’d home connection without touching a router setting — the mechanism works the same way whether you’re using ngrok, Playit.gg, frp, or inlets; the difference between those tools is what kind of traffic they’ll carry through that tunnel, not whether they can get through CGNAT at all.

Best Use Cases: Who Wins Where? Use ngrok when: - You’re testing local web apps, APIs, or webhook integrations (Stripe, Twilio, etc.) - You want request inspection — pausing, replaying, and analyzing HTTP traffic is still one of ngrok’s strongest features - You need enterprise auth controls — but note this is an Enterprise-tier feature ($39/month as of early 2026 per third-party pricing trackers), not something available on Free or Hobbyist

Use Playit.gg when: - You’re hosting a Minecraft, Valheim, Terraria, or similar game server for friends without renting a VPS - You’re an indie developer testing multiplayer netcode with external testers - You’re tinkering with UDP-based protocols on IoT hardware like a Raspberry Pi

Feature Comparison (Verified Against Current Sources) Feature ngrok Playit.gg Primary focus HTTP/HTTPS, with TCP/TLS tunnels TCP/UDP for gaming and raw sockets UDP support None, on any tier Yes, native Free tier limits 1 active endpoint, up to 3 tunnels per agent, 1 GB/month data out, 20,000 HTTP requests/month, 1 static dev domain Commonly reported as 4 TCP + 4 UDP tunnels (figure varies by source; not itemized on Playit’s own pricing page) Cheapest paid tier Hobbyist: $10/month ($8/month billed annually) Premium: $3/month (~$30/year) HTTPS tunnels Free tier: yes, with an interstitial warning page for browser traffic Requires Premium CGNAT bypass Yes Yes Request inspection/replay Yes — a genuine strength No — Playit is pure routing, not a debugging tool Client source Closed source Open source
Expanding the Scope: Who Owns the Network Boundary? Both ngrok and Playit.gg route your traffic through a company’s servers. That’s convenient — no VPS to manage, no DDoS protection to configure — but it also means you’re bound by that company’s pricing, terms, and datacenter footprint. Tools like frp and inlets move that boundary onto infrastructure you control, typically a cheap cloud VPS running $4–6/month from a provider like DigitalOcean, Hetzner, or Linode.

frp (Fast Reverse Proxy)
frp is a genuinely free, open-source reverse proxy with a large following on GitHub. You run frps (the server component) on your VPS and frpc (the client) on your home machine, and it supports TCP, UDP, HTTP, and HTTPS.

One correction worth making here: frp’s peer-to-peer feature (called xtcp) does not fully bypass your relay server the way it’s sometimes described. Per frp’s own documentation, frps is still required to coordinate the connection — “P2P” in this context refers only to the actual data transmission attempting to flow directly between clients after the server helps establish it, using STUN-based NAT hole-punching. It also doesn’t work with every type of NAT device; frp’s own docs recommend falling back to its stcp mode if xtcp fails. So frp gives you a real option for lower-latency, more direct connections — just not a way to eliminate your VPS from the picture entirely.

inlets
inlets, created by Alex Ellis, was built to give teams a self-hosted, Kubernetes-friendly tunnel — automating exit-node creation via inletsctl or the inlets-operator, rather than requiring manual .ini/.toml configuration. It operates at Layer 4, so beyond HTTP it can tunnel databases (PostgreSQL, MySQL), SSH, RDP, or a Kubernetes API server.

Here’s an important correction to make clear: inlets Pro is not free software. Unlike frp, it requires a paid license on top of whatever you pay for the VPS itself. Current pricing directly from inlets.dev is a Personal plan at $25/month (5 tunnels), Commercial at $50/month (2 tunnels, +$25/month per additional), and Uplink (aimed at SaaS providers managing customer connectivity) at $250/month per cluster including 10 tunnels. So the realistic cost of a self-hosted inlets setup is your VPS bill plus a license fee — not simply “$5 for a VPS,” as inlets is sometimes casually described.

It’s also worth narrowing an oft-repeated claim: inlets does not offer broad, general-purpose UDP tunneling for things like game servers or VoIP. Its own site currently scopes UDP support specifically to DNS traffic. If your goal is UDP for gaming, frp or Playit.gg are the appropriate tools — not inlets.

Final Verdict
The right tool in 2026 still comes down to what kind of traffic you’re pushing and how much infrastructure you want to own.

If you’re a web developer testing integrations, APIs, or webhooks, ngrok’s request-inspection tooling remains genuinely strong, even with a tighter free tier than it used to have.

If you need to host a game server or push raw UDP traffic without paying enterprise fees, Playit.gg remains a solid, purpose-built option for exactly that gap — just go in aware that “static IP” is really “persistent address over an anycast network,” and that HTTPS tunnels require the paid tier.

For full control over your own network boundary: frp is free and handles UDP well, with the caveat that its peer-to-peer mode still leans on your relay server for signaling. inlets is a more polished, Kubernetes-native option, but budget for its license fee on top of your VPS cost — it isn’t the free alternative it’s sometimes made out to be.

Changelog (Fact-Check Corrections)
ngrok free-tier limits corrected and detailed. Original draft only vaguely referenced bandwidth limits. Verified directly against ngrok’s own docs (ngrok.com/docs/pricing-limits): free tier is 1 active endpoint, up to 3 tunnels per agent, 1 GB/month data transfer out, 20,000 HTTP requests/month, 1 static dev domain, 5,000 TCP/TLS connections. Removed the unqualified “$10/month” premium price and replaced with the correct current tier structure: Hobbyist $10/month ($8 annual), Pay-as-you-go $20/month base + usage, Enterprise ~$39/month for SSO/mTLS/RBAC (per third-party pricing trackers, since ngrok doesn’t list Enterprise pricing publicly).
Playit.gg “static IP” claim softened and corrected. Playit’s own support documentation describes free tunnels as running over a “Global Anycast” network where the datacenter routing your players connect through can vary — a fixed, single-IP guarantee is not accurate for the free tier. Rewrote to describe a “persistent address,” not a static IP, and added that regional (fixed-datacenter) routing is a Premium-only feature.
Added a new, verified fact: Playit.gg’s own support docs confirm HTTPS tunnels require Playit Premium — this was missing from the original draft entirely.
Playit.gg free-tier tunnel count flagged as unverified on primary source. The “4 TCP + 4 UDP tunnels” figure appears consistently across multiple 2026 third-party guides (Pinggy, Localtonet, DevToolLab) but is not itemized on Playit’s own pricing page, and at least one source cites a different number (3 tunnels). Labeled accordingly rather than stated as confirmed fact.
Playit.gg premium pricing confirmed directly on playit.gg/pricing: $3/month. Removed an unverified claim about premium including “basic analytics” — not mentioned anywhere in Playit’s own support documentation.
Playit.gg client open-source claim confirmed via the public playit-cloud/playit-agent GitHub repository.
frp’s P2P claim corrected. The original draft implied frp’s peer-to-peer mode lets two clients “bypass the server entirely.” frp’s own documentation is explicit that its frps server is still required to coordinate the connection (via STUN-based hole-punching); only the data transmission itself may go direct, and even that doesn’t work with all NAT types.
Significant correction to inlets’ cost model. The original draft implied inlets was in the same free/self-hosted cost bracket as frp (just a $4–5/month VPS). In fact, inlets Pro requires a paid software license on top of the VPS cost — confirmed directly against inlets.dev/pricing: Personal $25/month (5 tunnels), Commercial $50/month, Uplink $250/month per cluster. This is now stated explicitly.
Narrowed inlets’ UDP claim. Original draft didn’t make a UDP claim for inlets, but for completeness: inlets’ own site currently scopes UDP tunneling specifically to DNS traffic, not general real-time protocols — added as a clarifying note so readers don’t assume broader UDP support.
CGNAT section extended with sourced specifics: IPv4 registry exhaustion dates (ARIN, September 2015; RIPE NCC, November 2019), the RFC 6598 100.64.0.0/10 address block reserved for CGNAT in 2012, the NAT444 terminology, and a current (2026) global IPv6 adoption estimate of roughly the mid-40% range, to explain why CGNAT is still widespread rather than a fading edge case.
Removed unverifiable superlatives (“the undisputed champion,” “recognized a glaring hole,” etc.) in favor of attributed, sourced comparisons, consistent with keeping vendor claims separable from independently confirmed facts.
Primary sources consulted: ngrok.com/docs/pricing-limits, playit.gg/pricing, playit.gg (homepage), playit.gg/support/playit-premium, github.com/fatedier/frp, github.com/playit-cloud/playit-agent, inlets.dev/pricing, docs.inlets.dev, en.wikipedia.org/wiki/IPv4_address_exhaustion, plus cross-checks against multiple independent 2026 tunneling-tool comparison articles for figures not itemized on vendor sites.

Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.

Ngrok alternative comparison
Compare InstaTunnel with ngrok for stable URLs, pricing, webhooks, and local tunnel workflows.
ngrok pricing comparison
Compare tunnel pricing questions by session behavior, stable URLs, webhook workflows, and MCP support.
ngrok free plan limitations
Review the free-plan limits developers should check before choosing a localhost tunnel tool.
Tunnel tool comparisons
Compare InstaTunnel with Cloudflare Tunnel, localtunnel, Tailscale, LocalXpose, and Pinggy.
Localhost tunnel guide
Expose a local app securely with a public URL for QA, demos, mobile testing, and integrations.
Plans and limits
Compare Free, Pro, and Business limits for tunnels, MCP endpoints, bandwidth, and teams.
InstaTunnel documentation
Read setup steps, CLI commands, webhook guides, MCP usage, and troubleshooting workflows.
Use-case playbooks
Browse practical workflows for webhooks, OAuth callbacks, MCP tunnels, and demo links.
Related Topics

ngrok, playit.gg, ngrok vs playit.gg, playit.gg vs ngrok, ngrok alternative, free ngrok alternative, best ngrok alternative for gaming, host game server from home, host minecraft server free, minecraft server port forwarding, minecraft server tunnel, valheim server tunnel, multiplayer netcode testing, game developer network tools, raw UDP protocols, UDP routing, TCP/UDP tunneling, raw socket data tunnel, static IP addresses for local server, custom ports tunneling, port forwarding alternative, port forwarding without router, CGNAT bypass, Carrier-Grade NAT traversal, strict NAT bypass, penetrate strict NAT, host server on home network, no router configuration server, custom UDP IoT applications, IoT application testing, real time applications tunnel, reverse proxy for gaming, expose local game server, localhost to internet gaming, free static ip tunnel, bypass http proxy, game server reverse proxy, playit gg minecraft, playit gg valheim, playit gg static ip, how to use playit gg, ngrok limitations for games, free gaming tunnel, host server behind cgnat, cgnat port forwarding, nat traversal gaming, local server to internet free, game server proxy setup, expose udp localhost, forward udp port free, ngrok udp alternative, self hosted game server tunnel, internet to localhost gaming, raw tcp proxy