Ngrok vs. frp (Fast Reverse Proxy): The Ultimate Battle Between Managed Tunnels and Self-Hosted Sovereignty
IT
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 guideQuick answer
ngrok vs frp: The Ultimate Self-Hosted Reverse Proxy Alterna: 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.
Exposing a local development server, an IoT device, or an on-premise staging environment to the public internet used to require tedious router configurations. You had to navigate ISP-level carrier-grade NATs (CGNAT), request static public IPs, and manually open ports on consumer firewalls.
Modern engineering has moved past this friction. Today, reverse tunneling tools create secure inbound paths through outbound connections, bypassing firewall restrictions completely.
When selecting an architecture for reverse tunneling, two dominant philosophies emerge. On one side stands ngrok, the fully managed, developer-first cloud service that prioritizes plug-and-play simplicity and instantaneous edge features. On the other side stands frp (Fast Reverse Proxy), the self-hosted open-source heavyweight with more than 107,000 stars on GitHub.
Choosing between them is not just a matter of selecting a tool; it is a fundamental architectural decision regarding data sovereignty, cost efficiency, and operational overhead. This guide breaks down the core differences, performance profiles, security implementations, and configuration strategies of ngrok and frp to help you choose the best fit for your infrastructure stack.
1. Architectural Philosophies: SaaS vs. Self-Hosted
Understanding the core structural divergence between ngrok and frp reveals how each handles traffic routing and infrastructure management.
The ngrok Paradigm: Managed Edge-as-a-Service
Ngrok operates as a commercial Software-as-a-Service (SaaS) platform. When you run the ngrok agent on a local machine, it initiates an encrypted outbound connection to ngrok’s globally distributed cloud edge network.
[Local Application]
│
▼ (Outbound Connection via ngrok Agent)
[ngrok Cloud Edge Network] ◄───── (Public Request via Internet) ─── [External User]
Traffic from the public internet hits ngrok’s ingress nodes, passes through their managed web application firewalls (WAF) and DDoS protection layers, and is routed down the established tunnel to your local machine. You do not manage the servers, the certificates, or the routing tables; everything is handled via a managed cloud API.
The frp Paradigm: Self-Hosted Traffic Delegation
Frp strips away the third-party infrastructure. It splits the tunneling process into two separate, lightweight binaries:
- frps (frp Server): Hosted by you on a publicly accessible machine, typically a low-cost VPS on platforms like DigitalOcean, Linode, or AWS Lightsail.
- frpc (frp Client): Executed inside your private local network alongside the target application.
[Local Application] │ ▼ (Outbound Connection via frpc) [Your Cloud VPS (frps)] ◄───── (Public Request via Internet) ─── [External User]
The frpc client connects outbound to your running frps server instance. When an external client connects to a designated port or domain assigned to the VPS, the frps server encapsulates that traffic and pumps it down the active connection channel to frpc, which maps it directly to your local application port. You are the infrastructure provider, the network operator, and the sole data custodian.
2. Feature-by-Feature Deep Dive
The architectural divergence results in drastically different feature sets. This table reflects each project’s current, verified state as of July 2026.
| Capability / Feature | ngrok (Managed Cloud) | frp (Fast Reverse Proxy) |
|---|---|---|
| Primary Model | Commercial SaaS / Managed Cloud Edge | Open-source self-hosted (Go) |
| GitHub Popularity | Proprietary client (agent is closed-source) | 107,000+ stars, 15,100+ forks |
| Latest Stable Release | N/A (continuously deployed cloud service) | v0.69.1 (June 2026) |
| Protocol Support | HTTP, TCP (all tiers); TLS (Pay-as-you-go only) | TCP, UDP, HTTP, HTTPS, STCP, XTCP (P2P) |
| Data Sovereignty | Third-party transit (ngrok’s edge network) | Absolute — you control 100% of the traffic path |
| Bandwidth | Metered by plan (1 GB–5 GB included, then $0.10/GB) | Unbounded — limited only by your VPS’s uplink |
| TLS/SSL Management | Automated, managed certificates | Manual or automated via ACME plugins |
| Traffic Inspection | Real-time web UI console with request/response replay | Basic web dashboard; Prometheus metrics available |
| Pricing Constraints | Free tier limited to 1 GB/month, 3 endpoints | No feature paywalls — cost is VPS only |
| UDP Support | Not supported on any tier | Native UDP, plus KCP and QUIC transport options |
3. The Power of Self-Hosting: frp’s Capabilities
Frp has earned its status as an enterprise-grade self-hosted tool due to an extensive, actively maintained feature set that lifts the restrictions imposed by commercial alternatives.
Absolute Data Sovereignty
When using a commercial proxy service, unencrypted HTTP payloads, authorization headers, and webhook data pass through external proxy nodes. For teams bound by compliance frameworks such as HIPAA, GDPR, or SOC 2, this third-party exposure introduces a data-supply-chain consideration worth weighing carefully.
With frp, data never leaves your infrastructure perimeter — it passes directly from the end user, through your own cloud compute instance, to your local architecture.
No Feature Paywalls
Frp has no concept of a paywall. If your host has a 1 Gbps unmetered port, your tunnels inherit that capability. You can run hundreds of concurrent proxies, bind custom apex domains, and reserve TCP/UDP port mappings without hitting arbitrary API rate limits — the practical ceiling is your VPS, not frp’s licensing tier.
Advanced NAT Traversal: STCP and XTCP
Traditional reverse proxies route all data through the public server, so the server’s bandwidth caps the effective transfer speed. frp offers two additional connection modes to work around this:
- STCP (Secret TCP): Hides a proxy from the open internet entirely. A client must present a matching
secretKeyvia a[[visitors]]block on its own frpc instance to reach the service — there’s no public port to scan or guess. - XTCP (P2P Traversal): Uses STUN-based UDP hole-punching to attempt a direct peer-to-peer connection between the visitor and the local client. frps is still required for the initial handshake and signaling, but once established, data can flow directly between endpoints, bypassing the server for the actual transfer. frp’s own documentation notes this doesn’t work with all NAT types and recommends falling back to STCP when it fails.
What’s new in frp through mid-2026
frp has shipped several meaningful updates in its last few minor releases that are worth knowing about if you last touched it more than a year ago:
- Formal compatibility policy (as of v0.69.0): each minor release is now supported until nine newer minor releases ship — for example, v0.69.0 remains supported through v0.78.0 — giving operators a clearer upgrade window than frp has historically offered.
- Wire protocol v2 (v0.69.0+): a new, versioned frpc↔frps protocol with negotiated AEAD encryption (
xchacha20-poly1305oraes-256-gcm) on the control channel, intended to eventually replace the legacy protocol. It’s opt-in viatransport.wireProtocol = "v2"and not yet the default. - Dynamic proxy management (“Store”) (v0.68.0+): frpc can now create, update, and delete proxies and visitors at runtime through its web UI or API, persisting them to disk without a full restart.
- SSH Tunnel Gateway (v0.53.0+): frps can accept plain
ssh -Rconnections directly, letting you create a TCP proxy without installing frpc at all. - VirtualNet (alpha, v0.62.0+): a TUN-interface-based feature that extends frp from port forwarding into IP-level routing between clients and visitors — still explicitly marked alpha and disabled by default via feature gate.
Worth noting: frp’s long-discussed “v2” architectural rewrite (a from-scratch, Envoy-like four/seven-layer proxy core) is a separate, much larger effort from wire protocol v2 above. As of mid-2026, the maintainer has stated its complexity is higher than anticipated and development continues opportunistically rather than on a committed timeline — so don’t plan around it landing soon.
4. The Value Proposition of ngrok
While self-hosting offers clear advantages, ngrok remains a strong choice for teams that value zero-ops simplicity and production-ready edge features over full infrastructure control.
Zero Infrastructure Management
Setting up frp requires provisioning a VPS, configuring firewall rules, and managing a systemd daemon. Ngrok removes this entirely — exposing a local instance takes one command:
ngrok http 8080
There are no servers to provision and no security patches to track on your side.
Advanced Traffic Inspection and Request Replay
Ngrok’s local web inspector (served at http://127.0.0.1:4040) lets you view inbound HTTP requests down to the full header set and JSON body, and its Replay feature lets you re-trigger a captured webhook without re-running the upstream event that generated it.
Identity and Edge Protection, Built In
Ngrok bakes authentication into its edge configuration via Traffic Policy — OIDC, SAML, and per-request rate limiting are configuration, not separate infrastructure you have to stand up and patch yourself.
New in 2026: ngrok as an AI/MCP gateway
This is the most significant thing that’s changed on ngrok’s side since tunneling-tool comparisons like this were last written, and it’s directly relevant if you’re also evaluating AI-agent infrastructure. Through 2026, ngrok extended its edge platform into what it calls a “Universal Gateway” with two AI-specific pieces:
- ngrok as an MCP gateway: you can put an ngrok Agent Endpoint in front of a local MCP server and use Traffic Policy to authenticate, authorize, and audit every MCP request before it reaches your process — for example, restricting inbound connections to Anthropic’s or OpenAI’s IP ranges and rate-limiting per API key, without touching your MCP server’s code.
- ngrok.ai (AI Gateway): a separate, OpenAI-compatible routing layer (relaunched July 1, 2026 at
app.ngrok.ai) that sits in front of your model calls rather than your tunnels. It supports bring-your-own provider keys, automatic failover between providers, and routing to self-hosted models (Ollama, vLLM) alongside hosted ones — all by changing abaseURL, with no code changes otherwise. As of April 2026, this is also available to Free-tier accounts.
None of this replaces frp’s use case — it’s a parallel product for LLM traffic rather than raw TCP/UDP tunneling — but it’s a meaningful reason ngrok has stayed relevant for teams building agentic tooling specifically, and it maps directly onto the zero-trust AI-agent tunneling ground this blog has covered with zrok/OpenZiti.
Current ngrok pricing (verified against ngrok.com, July 2026)
| Plan | Price | Data transfer | HTTP/S requests | Online endpoints | Protocols |
|---|---|---|---|---|---|
| Free | $0 | 1 GB included | 20k/month | 3 | HTTP, TCP (requires card verification) |
| Hobbyist | $8/mo billed annually ($10/mo monthly) | 5 GB included, then $0.10/GB | 100k included, then $1/100k | 3 | HTTP, TCP |
| Pay-as-you-go | $20/mo + usage | 5 GB included, then $0.10/GB, unlimited | 100k included, then $1/100k, unlimited | Unlimited | HTTP, TCP, TLS |
UDP is not available on any ngrok tier — this remains an architectural gap, not a pricing one, and it’s the single most common reason developers reach for an alternative when the workload involves game servers, VoIP, or UDP-based IoT protocols like CoAP or DTLS. If UDP is a hard requirement and self-hosting frp isn’t an option, that’s a real gap in ngrok’s lineup worth being aware of — it’s part of why a wave of UDP-native managed alternatives (Localtonet, LocalXpose, Pinggy, Playit.gg) has gained traction through 2026, though evaluating those is outside the scope of this comparison.
5. Step-by-Step Deployment Guide: Building a Private frp Network
Here is a complete deployment walkthrough for setting up an frp tunneling network on a standard Ubuntu cloud instance, using the current stable release (v0.69.1) and corrected, verified TOML syntax.
Step 1: Configuring the Server Node (frps)
Log into your cloud VPS via SSH, download the latest release binary, and extract it:
wget https://github.com/fatedier/frp/releases/download/v0.69.1/frp_0.69.1_linux_amd64.tar.gz
tar -zxvf frp_0.69.1_linux_amd64.tar.gz
cd frp_0.69.1_linux_amd64
Copy the server binary to /usr/local/bin and create a configuration directory:
sudo cp frps /usr/local/bin/
sudo mkdir -p /etc/frp
Create /etc/frp/frps.toml. Note that the HTTP/HTTPS vhost keys use capitalized HTTP/HTTPS — vhostHttpPort and vhostHttpsPort (as written with a lowercase “ttp”) are not valid TOML keys in frp and will silently fail to bind:
# /etc/frp/frps.toml
bindPort = 7000
# Virtual host setup for HTTP/HTTPS web routing
vhostHTTPPort = 80
vhostHTTPSPort = 443
# Authentication layer to prevent unauthorized client attachments
auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"
# Enable the built-in monitoring dashboard
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "CHOOSE_A_COMPLEX_DASHBOARD_PASSWORD"
Wrap execution in a systemd unit at /etc/systemd/system/frps.service:
[Unit]
Description=frp Server Daemon
After=network.target
[Service]
Type=simple
User=nobody
Restart=on-failure
RestartSec=5s
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
[Install]
WantedBy=multi-user.target
Reload systemd, enable, and start:
sudo systemctl daemon-reload
sudo systemctl enable frps
sudo systemctl start frps
sudo systemctl status frps
Step 2: Configuring the Client Node (frpc)
On your local machine, create frpc.toml. Note the field is localIP (capital IP), not localIp — frp’s config parser is case-sensitive and the lowercase variant used in earlier drafts of this guide will fail validation:
# frpc.toml
serverAddr = "YOUR_VPS_PUBLIC_IP_ADDRESS"
serverPort = 7000
auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"
# Example 1: Forwarding local SSH service access
[[proxies]]
name = "secure-ssh-tunnel"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6022
# Example 2: Exposing a local development web app
[[proxies]]
name = "local-web-development"
type = "http"
localIP = "127.0.0.1"
localPort = 8080
customDomains = ["dev.yourdomain.com"]
Launch the client:
./frpc -c ./frpc.toml
Once connected, public HTTP requests landing on dev.yourdomain.com (pointed via DNS to your VPS IP) will route directly to your local port 8080.
You can verify a config file has no syntax errors before applying it with frpc verify -c ./frpc.toml, and reload a running frpc’s proxy set without a restart via frpc reload -c ./frpc.toml (requires the webServer block to be configured).
6. Real-World Decision Matrix: Which Should You Choose?
Is absolute data sovereignty required?
│
┌─────────────┴─────────────┐
YES NO
│ │
[Use frp] How complex is your stack, and
(Self-Hosted) do you need UDP or AI/MCP tooling?
┌────────────┴────────────┐
▼ ▼
SIMPLE, HTTP/TCP, COMPLEX, or
needs AI Gateway/MCP needs UDP
│ │
[Use ngrok] [Use frp]
(Fast Setup) (Scale/UDP/P2P)
Choose ngrok if: - You work in a fast-paced environment where managing infrastructure distracts from core product engineering. - You need to inspect and replay complex webhook payloads in real time. - You want built-in OIDC/SAML identity gating without standing up your own reverse proxy. - You’re building agentic tooling and want MCP-aware traffic policy or multi-provider LLM routing without separate infrastructure. - Your workload doesn’t need UDP.
Choose frp if: - You require absolute data sovereignty and want unencrypted internal data streams to never touch third-party infrastructure. - You need custom apex domains, dedicated TCP/UDP port mappings, or high-bandwidth workloads without a metered SaaS plan. - You’re tunneling UDP-native protocols — game servers, VoIP, IoT. - You’re comfortable maintaining a VPS and want a project with an active, transparent release cadence.
Final Verdict
The debate between ngrok and frp is the classic infrastructure tradeoff: convenience vs. control. Ngrok turns complex network routing into an abstracted utility — and in 2026, it’s expanded that abstraction into AI traffic routing and MCP gateway duty, which matters if agentic workflows are part of your stack. Frp remains the standard for infrastructure engineers who prioritize ownership, UDP support, and zero licensing ceilings, backed by a project that — based on its recent release history — is still being actively developed rather than coasting.
Changelog
Corrections (factual errors in the original draft): - frp’s GitHub star count was rounded up to “108,000” in the original; verified current count via GitHub is 107,000+ stars (105k–108k across recently cached snapshots), with 15,100+ forks. Updated to reflect this. - The original deployment guide referenced frp v0.70.0, which does not exist as a published release. Verified against frp’s official Releases page: the current latest stable release is v0.69.1 (June 1, 2026). Updated all version references and download commands accordingly. - The original frps.toml example used vhostHttpPort / vhostHttpsPort. These are invalid TOML keys — frp’s actual config keys are vhostHTTPPort / vhostHTTPSPort (verified against frp’s official README). The original config as written would fail to bind an HTTP/HTTPS vhost port silently. Corrected. - The original frpc.toml examples used localIp. frp’s config field is case-sensitive and the correct key is localIP (verified against frp’s official README examples). Corrected across all config blocks. - Confirmed the original’s core claim that ngrok has no UDP support on any tier — verified directly against ngrok’s live pricing page (ngrok.com/pricing), which lists only HTTP, TCP, and TLS across Free, Hobbyist, and Pay-as-you-go.
Additions (new, sourced information): - Replaced the original’s vaguer ngrok pricing description with an exact, current table sourced directly from ngrok.com/pricing (plan names, prices, included data transfer, request limits, and protocol availability per tier). - Added a dedicated section on ngrok’s 2026 AI Gateway and MCP gateway capabilities (Traffic Policy–based MCP request authentication, ngrok.ai’s provider-routing/failover relaunch on July 1, 2026, and Free-tier AI Gateway access since April 2026) — new since ngrok vs. tunneling-tool comparisons were last written, and directly relevant to this blog’s coverage of zero-trust AI agent infrastructure. - Added a “What’s new in frp through mid-2026” section covering the formal minor-version compatibility policy (introduced v0.69.0), wire protocol v2 with AEAD control-channel encryption, the dynamic proxy Store feature (v0.68.0), SSH Tunnel Gateway (v0.53.0), and the alpha VirtualNet feature (v0.62.0) — all verified against frp’s official README and release notes. - Clarified that frp’s long-planned “v2” architectural rewrite is distinct from “wire protocol v2,” and noted the maintainer’s own mid-2026 statement that the rewrite’s timeline remains open-ended due to its complexity. - Added verification commands (frpc verify, frpc reload) to the deployment guide as practical additions not present in the original.
Structural changes: - Removed all leftover metadata/formatting artifacts from the original draft (stray “Bash”/“Ini, TOML” labels glued to code blocks, inconsistent code fencing). - Reformatted all shell and config examples into properly fenced, language-tagged code blocks.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Comments
Post a Comment