Self-Hosting for Data Sovereignty: The Open-Source Shift in Reverse Proxying
IT
Quick answer
Self-Hosted ngrok Alternatives: frp, Zrok & Inlets for Data : 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.
The Enterprise Imperative: Why Managed Tunnels No Longer Cut It
Exposing local services to the internet for testing, webhooks, or remote access is a daily necessity in software development and infrastructure management. For years, managed SaaS providers like ngrok and Cloudflare Tunnel have been the default solution. For enterprise infrastructure engineers, compliance officers, and security teams, however, routing internal traffic through a third-party, managed SaaS provider is increasingly hard to justify under strict regulatory frameworks.
Enterprises operating under GDPR, HIPAA, SOC 2, or FedRAMP face a data sovereignty requirement: data should remain subject to the laws and governance structures of the jurisdiction where it was collected. When you use a managed SaaS reverse proxy, your internal APIs and webhook payloads are routed through servers controlled by a third party, sometimes in a different legal jurisdiction than your own.
This has driven a shift toward self-hosted, production-grade tunneling tools. Open-source gateways such as frp (Fast Reverse Proxy), Zrok (built on the OpenZiti zero-trust network), and Inlets for Kubernetes let infrastructure teams keep the gateway in-house — not just to avoid SaaS subscription fees, but to retain control over where traffic terminates and who can inspect it.
This piece looks at the current state of these three tools, how they compare, and where the compliance picture is genuinely settled versus still evolving.
1. The Data Sovereignty and Compliance Landscape
The Problem with SaaS Reverse Proxies
Tools like managed ngrok install a lightweight client on your private network that establishes an outbound tunnel to the provider’s edge servers. The provider generates a public URL, and traffic sent to that URL is routed through the provider’s infrastructure back into your network. This is convenient, but it carries real compliance considerations:
- Data residency: If a developer in Germany tests a local API using a managed tunnel whose edge server sits in the US, that cross-border routing needs a lawful transfer mechanism. It’s worth being precise here: a transatlantic transfer isn’t automatically illegal. The EU–US Data Privacy Framework (DPF), adopted by the European Commission in July 2023, currently provides an adequacy basis for transfers to certified US organizations, and it survived its first legal challenge at the EU General Court in September 2025. But the DPF’s history is one of repeated invalidation — it replaced Safe Harbor (struck down 2015) and Privacy Shield (struck down in the 2020 Schrems II ruling) — and a further challenge is now pending before the CJEU, with added uncertainty following a June 2026 US Supreme Court ruling on FTC commissioner independence that the European Data Protection Board has flagged as relevant to the DPF’s oversight commitments. For compliance teams, this history is exactly why some organizations choose to remove the cross-border question entirely rather than rely on a framework that has been overturned twice before.
- TLS termination at the edge: By design, L7 (HTTP) managed proxies terminate TLS at the provider’s edge, decrypt traffic to route it to the correct tunnel, then re-encrypt it. Even with a trustworthy provider, this means a third party holds the keys to your traffic in transit.
- Availability coupling: Relying on a SaaS tunnel provider ties your internal remote-access and webhook-testing workflows to that provider’s uptime.
- Metered pricing at scale: Per-user or bandwidth-metered SaaS pricing can become expensive as usage grows.
The “Bring Your Own Infrastructure” (BYOI) Approach
To reduce dependence on third-party transfer mechanisms, some organizations self-host their tunneling gateway on infrastructure they control — deploying the relay server in a chosen region, under their own audit and access-control regime. The three tools below represent different approaches to this.
2. frp (Fast Reverse Proxy): The Bare-Metal Workhorse
frp (fatedier/frp on GitHub) is a reverse proxy written in Go for exposing a local server behind a NAT or firewall. It’s one of the most widely deployed self-hosted tunneling tools: as of mid-2026 the repository has roughly 107,000 GitHub stars, is used by 180+ public dependent projects, and is licensed under Apache-2.0. The current stable release is v0.69.1.
Architecture and Data Sovereignty
frp has two components: frps, the server you deploy on infrastructure you control, and frpc, the client on the internal machine. Because you choose where frps runs, you control the jurisdiction traffic passes through — deploying frps on a server in eu-central-1 keeps that hop within German/EU borders.
One nuance worth flagging for compliance-minded readers: frp’s transport-level encryption between frpc and frps is TLS by default since v0.50.0, but payload-level encryption and compression for individual proxies (transport.useEncryption, transport.useCompression) are off by default and must be explicitly enabled per-proxy. Self-hosting frp gets you jurisdictional control automatically; it doesn’t automatically maximize encryption without configuration.
Features Relevant to Enterprise Use
- Protocol support: TCP, UDP, HTTP, HTTPS, and STCP.
- STCP and XTCP for zero public exposure: STCP (Secret TCP) lets a service be registered with
frpswithout opening a public port — an authorized visitor client must present a matching pre-shared key to connect. XTCP goes further, using STUN-based NAT hole-punching to attempt a direct peer-to-peer connection between clients, falling back to STCP if the NAT type doesn’t support it. - Connection pooling and multiplexing: frps can maintain a pool of pre-established connections to reduce per-request latency, and TCP stream multiplexing is supported since v0.10.0.
- KCP and QUIC transport modes, an SSH tunnel gateway (added in v0.53.0) that lets clients connect via plain
ssh -Rwithout runningfrpc, and an alpha-stage VirtualNet (TUN-based) feature for IP-level routing between peers. - Configuration format: As of v0.52.0, frp uses TOML, YAML, or JSON; the legacy INI format is deprecated and receives no new features.
It’s also worth noting that frp’s maintainers have an in-progress, not-yet-released v2 rewrite — a more Envoy-like L4/L7 proxy core — described in the project’s README as significantly more complex than expected and without a firm release date.
When to Choose frp
frp suits teams that want a flexible, protocol-agnostic, fully self-hosted relay and are comfortable managing their own server and TLS configuration. It’s a reasonable substitute for a traditional VPN when you need targeted, per-service remote access rather than full network-level connectivity.
3. Zrok: Zero-Trust Networking Built on OpenZiti
Zrok is developed by NetFoundry and built on OpenZiti, NetFoundry’s open-source zero-trust network overlay. Rather than forwarding ports, Zrok establishes an identity-based, encrypted overlay between endpoints — in OpenZiti’s model, there are no listening ports on the public internet, and access is granted by cryptographic identity rather than IP address.
A Major Version Change Worth Knowing About: v2.0 / zrok2
Zrok shipped a significant v2.0 release in March 2026. If you’ve seen older Zrok tutorials, the command syntax has changed:
- The binary is now
zrok2, notzrok. The two can be installed side by side — v2 uses its own environment directory (~/.zrok2), its own environment-variable prefix (ZROK2_*), and its own systemd units, so upgrading doesn’t disturb an existing v1 install. - Reserved sharing was replaced by a namespace/names model. The old
zrok reserve/zrok release/zrok share reservedcommands are gone;zrok2 create shareandzrok2 delete sharenow manage both public and private shares, with a--share-tokenflag available onzrok2 share privatefor a persistent vanity token. - A new
zrok2 access dynamicProxycommand was added, which receives name-mapping updates directly from the controller rather than parsing the Host header.
Public vs. Private Sharing
Zrok supports two sharing modes:
- Public sharing (
zrok2 share public <target>) generates a public HTTPS URL — useful for third-party integrations like Stripe or GitHub webhooks that need a conventional public endpoint. - Private sharing (
zrok2 share private <target>) generates a share token instead of a URL. A collaborator or CI/CD pipeline runszrok2 access private <token>to reach the service. No public DNS record or open port is ever created, and traffic is carried end-to-end over the OpenZiti fabric between the two endpoints — a router relaying traffic to work around strict NAT cannot decrypt it, since encryption keys are held only at the endpoints.
Zrok also supports a “closed” permission mode (--closed, added in v0.4.26 and carried forward into v2) that restricts a share to environments owned by the account that created it, plus an --access-grant option to allow specific additional accounts.
Hosted vs. Self-Hosted, and Pricing
Zrok is Apache-2.0 licensed and can be self-hosted on Linux, Docker, or Kubernetes, or used as a hosted service at zrok.io (rebranded commercially as “zrokNET” on NetFoundry’s pricing page, with the free hosted tier offering 5 GB/day, 25 environments, 50 share backends, and 50 private access frontends at the time of writing). Self-hosting removes the usage caps entirely but requires standing up your own OpenZiti controller — a meaningfully higher operational lift than deploying an frp server.
When to Choose Zrok
Zrok fits organizations that want zero-trust, identity-based access control and want private shares to never touch the public internet at all. Because it’s a newer, more actively evolving codebase than frp, teams should plan for the v1→v2 migration path if they’re starting fresh or upgrading an existing deployment.
4. Inlets: The Kubernetes Tunneling Product Line
Inlets was created by Alex Ellis, also the founder of OpenFaaS. It targets teams that need to expose services from clusters without a public IP — bare-metal Kubernetes, Raspberry Pi clusters, or edge sites — by creating an outbound tunnel from the private cluster to a lightweight “exit node” in a public cloud region of your choosing.
A Licensing Correction: Inlets Is Not an Open-Source Tunnel
This is an important distinction the “open-source shift” framing needs to make clearly: the inlets-pro tunnel binary itself is closed-source, commercial software. Per the project’s own FAQ, only inlets-operator and inletsctl — the orchestration tooling that provisions exit-node VMs and wires up the tunnel — are MIT-licensed. The inlets-pro binary that actually carries traffic requires a paid license key (personal, commercial, or enterprise tiers) issued by OpenFaaS Ltd., under a commercial EULA, and will not run without one. The original, fully open-source inlets project (HTTP-only, no TLS automation) still exists in project history but has been effectively superseded by inlets-pro and is not the actively maintained path.
This doesn’t disqualify Inlets from a data-sovereignty conversation — you still choose where the exit node lives, and traffic can be end-to-end encrypted without the vendor holding keys — but it does mean Inlets sits closer to ngrok’s commercial model than to frp’s or Zrok’s fully open-source one. If “no vendor relationship and no license cost” is a hard requirement, Inlets doesn’t meet it; if “self-hosted exit node in a jurisdiction I control” is the requirement, it does.
Data Sovereignty and Architecture
Because you choose the exit node’s cloud region, you control where traffic terminates geographically. Inlets supports both L4 (TCP) and L7 (HTTP) tunneling; with inlets-pro’s L4 mode, TLS termination happens inside your own cluster (e.g., at an internal ingress controller) rather than at the exit node, so the exit node relays encrypted bytes it cannot inspect.
The Inlets Operator
inlets-operator, the MIT-licensed Kubernetes operator, watches for Service objects of type LoadBalancer. When one appears, instead of provisioning an expensive cloud load balancer, it spins up a lightweight exit-node VM on a provider of your choice (DigitalOcean, Hetzner, AWS, and others via API), configures the tunnel, and wires it to the internal pod.
The Current Product Line (2026)
Inlets has expanded beyond the original CLI tool into a small product family: inlets Pro (self-hosted tunnels, licensed per the above), Inlets Cloud (a managed tunnel offering with instant HTTPS/SSH bundled into a subscription), and Uplink (a newer, Kubernetes-native control layer aimed at SaaS vendors who need to connect many customer environments back to a shared control plane, rather than at the single-tenant self-hosted use case this article focuses on).
When to Choose Inlets
Inlets is a reasonable fit for Kubernetes-heavy teams that want the operational simplicity of an automated exit-node provisioning workflow and are comfortable paying for a commercial license in exchange for that convenience and support. Teams whose primary motivation is avoiding vendor licensing costs altogether are better served by frp or Zrok.
5. The New Frontier: Zero-Trust Tunneling for AI Agents and MCP Servers
Data-sovereignty tunneling is increasingly being extended to a new category of traffic: AI agents and MCP (Model Context Protocol) servers reaching back into internal tooling. This is a genuinely new development as of 2026 rather than an established practice, so it’s worth treating as such.
In March 2026, NetFoundry announced an expansion of OpenZiti into what it calls an “AI enclave” — zero-trust gateways specifically for agent and LLM traffic:
- openziti/mcp-gateway aggregates and exposes MCP tools over the OpenZiti overlay (or over Zrok) instead of a locally-bound stdio process or a publicly listening HTTP endpoint. It requires zrok v2.0.x or later, reflecting how tightly the two projects are now coupled.
- An accompanying LLM gateway provides an OpenAI-compatible proxy with semantic routing across providers (OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex AI, Ollama, and other OpenAI-compatible endpoints), authenticated with the same OpenZiti identity used for MCP tool access — the stated goal being one identity, one audit trail, across both model calls and tool calls.
- ziti-mcp-server, released around the same time, is itself an MCP server — it exposes roughly 200 tools covering the OpenZiti Management API to any MCP-compatible client (Claude Desktop, Cursor, and others), letting an agent manage identities, services, and policies on a Ziti network through natural-language requests, authenticated the same way a human operator would be.
For readers tracking the AI-infrastructure angle of tunneling: this is the clearest example so far of a tunneling vendor building purpose-specific infrastructure for agent traffic rather than repurposing a general-purpose tunnel for it. It’s early — these projects were released in the same month as Zrok v2.0 and are still evolving — but it’s a concrete signal that the zero-trust tunneling vendors see agent-to-tool connectivity as a distinct problem worth dedicated tooling, not just “webhook tunneling with extra steps.”
6. Comparative Matrix
| Feature/Requirement | frp | Zrok (OpenZiti) | Inlets |
|---|---|---|---|
| Primary use case | Bare-metal, generic TCP/UDP tunneling | Zero-trust, identity-based public and private sharing | Kubernetes ingress, cloud-native L4/L7 tunneling |
| Licensing | Fully open source (Apache-2.0) | Fully open source (Apache-2.0) | Orchestration tooling (inlets-operator, inletsctl) is MIT; the inlets-pro tunnel binary is closed-source and commercially licensed |
| Security model | Port forwarding; STCP/XTCP pre-shared-key secrets | Zero-trust overlay; E2EE between endpoints on private shares | Outbound WebSocket tunnel; L4 pass-through with internal TLS termination |
| Encryption by default | TLS between frpc/frps since v0.50.0; per-proxy payload encryption is opt-in | End-to-end on private shares by design | Depends on tunnel mode; L4 mode preserves internally-terminated TLS |
| Data sovereignty | High — fully self-hosted, region of your choice | High — self-hosted or hosted, E2EE on private shares | Moderate-to-high — you choose the exit node’s region, but you depend on a commercial vendor for the tunnel binary |
| Kubernetes native | Manual configuration | Containerizable, requires setup | Native operator with automated exit-node provisioning |
| Public IP requirement | Required for frps | Not required for private shares | Required for the exit node |
| Operational complexity | Moderate | Higher — requires an OpenZiti controller, or v1→v2 migration if upgrading | Low-to-moderate — automated via the operator |
7. Best Practices for a Self-Hosted Tunneling Strategy
- Don’t assume self-hosting means encrypted by default. As the frp example shows, transport-level TLS between client and server may be on by default, but payload-level encryption for individual proxies often isn’t. Check each tool’s defaults rather than assuming “self-hosted” implies “maximally encrypted.”
- Terminate TLS internally where the tool supports it. Using L4/TCP passthrough (frp, inlets-pro) and terminating TLS on your internal ingress means your relay server never holds decrypted traffic, reducing what an attacker gains by compromising it.
- Place relays in the region your compliance requirement actually specifies, and keep a record of why — this documentation matters if a regulator or auditor asks how a given data flow is justified, especially while frameworks like the DPF remain subject to ongoing litigation.
- Audit access regularly. For frp, review the
allowPortsrestriction on the server config. For Zrok, review closed-share access grants and rotate share tokens on a schedule rather than treating them as permanent. - Monitor tunnel traffic as you would any other ingress path. Feed logs into your SIEM, and track bandwidth patterns with Prometheus or OpenTelemetry — self-hosting removes a vendor’s edge from the picture, but the tunnel is still a bridge into your private network and should be treated as one.
Conclusion
The convenience of managed SaaS reverse proxies comes with real compliance tradeoffs for organizations under strict data-protection regimes — but the picture is more nuanced than “SaaS tunnels are illegal, self-hosted tunnels are safe.” Cross-border transfers can be lawful under mechanisms like the DPF, and self-hosting a tool doesn’t automatically mean traffic is more encrypted than it would be otherwise; both claims need checking against how a specific tool is actually configured.
What is true is that frp, Zrok, and Inlets each give infrastructure teams a way to choose exactly where a tunnel terminates and, in Zrok’s case, to avoid a public endpoint entirely for internal sharing. Of the three, frp and Zrok are genuinely open source with no licensing cost; Inlets trades a commercial license for a more automated Kubernetes workflow. Which one fits depends on whether the priority is protocol flexibility (frp), zero-trust identity-based access (Zrok), or Kubernetes-native automation backed by vendor support (Inlets).
Changelog
Corrections: - Removed the framing that routing data through a US-based SaaS tunnel is automatically illegal under GDPR/Schrems II. Added accurate context on the EU–US Data Privacy Framework (adopted July 2023, upheld by the EU General Court in September 2025, appeal pending at the CJEU, and facing renewed EDPB scrutiny since a June 2026 US Supreme Court ruling on FTC independence). - Corrected the article’s framing of Inlets as an “open source ngrok alternative.” Only inlets-operator and inletsctl are MIT-licensed; the inlets-pro tunnel binary itself is closed-source and requires a paid commercial license under OpenFaaS Ltd.’s EULA. This is now stated explicitly, including in the comparative matrix. - Updated Zrok command syntax and concepts throughout: Zrok shipped v2.0 in March 2026, renaming the binary to zrok2, replacing the reserved-sharing model with a namespace/names system, and removing zrok reserve/zrok release/zrok share reserved. The original draft used v1 syntax (zrok share private, zrok access private) without noting this transition. - Clarified that frp’s transport-level TLS is on by default (since v0.50.0) but per-proxy payload encryption and compression are opt-in — the original draft implied self-hosting alone maximizes encryption. - Softened “military-grade” and similar promotional language per editorial standards; replaced with neutral, factual descriptions.
Added: - Current frp facts: ~107k GitHub stars, Apache-2.0 license, latest stable release v0.69.1 (June 2026), config format migration from INI to TOML/YAML/JSON (since v0.52.0), SSH Tunnel Gateway (v0.53.0), alpha VirtualNet feature (v0.62.0), and the in-progress, unreleased frp v2 rewrite. - A new Section 5 covering 2026 zero-trust infrastructure for AI agents and MCP servers: openziti/mcp-gateway, an accompanying OpenAI-compatible LLM gateway, and ziti-mcp-server (which exposes the OpenZiti Management API — roughly 200 tools — to MCP clients), all announced by NetFoundry in March 2026. - Inlets product-line detail: Inlets Cloud (managed) and Uplink (Kubernetes-native control plane for SaaS vendors), alongside the self-hosted inlets-pro path the rest of the article focuses on. - Zrok’s “closed” permission mode (--closed, --access-grant) for restricting private-share access to specific accounts. - Licensing row added to the comparative matrix to make the open-source-vs-commercial distinction visible at a glance.
Sources checked: github.com/fatedier/frp (README, releases), github.com/openziti/zrok (README, CHANGELOG, releases), blog.openziti.io (“Introducing zrok v2.0”), netfoundry.io/docs (zrok overview, private shares, v1→v2 migration guide), zrok.io/pricing, inlets.dev (product pages, FAQ), github.com/inlets/inlets-pro (EULA.md), github.com/inlets/inlets-operator, prnewswire.com (NetFoundry AI enclave announcement), github.com/openziti/mcp-gateway, blog.openziti.io (ziti-mcp-server post), and current legal-analysis coverage of the EU-US Data Privacy Framework (Recording Law, EuropeanMartech, Skadden, IAPP).
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Comments
Post a Comment