Self-Hosting for Data Sovereignty: The Open-Source Shift in Reverse Proxies and Ingress Tunnels

Introduction: The Enterprise Ingress Dilemma

In modern cloud-native architectures, developers and operations teams frequently face a persistent challenge: how do you securely expose internal services, staging environments, edge devices, or local Kubernetes clusters to external networks or client traffic?

For years, managed developer tools like ngrok became the default standard. With a simple command-line invocation, engineers could bypass NAT (Network Address Translation), negotiate CGNAT (Carrier-Grade NAT), and establish a public HTTPS URL mapped directly to a local port.

However, as organizations scale and cloud-native workloads mature, reliance on third-party SaaS ingress tunnels introduces architectural and regulatory friction. When internal traffic is routed through a third-party managed SaaS server, that provider’s infrastructure sits directly in the data path — a real concern for enterprise security architects, compliance managers, and infrastructure engineers.

Data protection frameworks such as GDPR, HIPAA, SOC 2 Type II, PCI-DSS, and the EU’s NIS2 directive shape how organizations must handle payload data, third-party exposure, and incident response — though, as covered below, they don’t all regulate the same thing, and it’s worth being precise about which law does what before you architect around it.

The alternative is self-hosted data sovereignty: taking control of both the control plane and the data plane so an organization can eliminate third-party telemetry, enforce zero-trust access control, and meet its own compliance obligations directly. This guide walks through four production-grade options driving that shift — frp (Fast Reverse Proxy), zrok (built on OpenZiti), Inlets, and the newer entrant Pangolin — and is fact-checked against each project’s own documentation and source code as of August 2026.

1. The Compliance and Architectural Push Toward Data Sovereignty

Why SaaS Ingress Tunnels Complicate Compliance

Managed tunneling SaaS platforms operate as multi-tenant reverse proxy systems. When a local agent creates a tunnel to a SaaS platform:

• Traffic interception & decryption: TLS commonly terminates at the SaaS provider’s edge to enable feature integrations like request inspection, webhook logging, and web dashboards, meaning the provider’s infrastructure briefly holds decrypted application data in memory.
• Limited telemetry and audit control: Organizations often cannot fully verify where transit logs are stored or how long request/response bodies are retained on infrastructure they don’t operate.
• Supply-chain and single-point-of-failure risk: Outages or security incidents at the SaaS provider can affect the availability and confidentiality of internal enterprise endpoints.

It’s worth noting this isn’t strictly binary — ngrok, for example, offers enterprise-tier options such as a “Bring Your Own Cloud” (BYOC) deployment model and dedicated private editions that run inside a customer’s own environment, aimed at exactly this kind of concern. Self-hosting remains the more complete answer for teams that want the control plane and data plane entirely under their own operational ownership without paying for an enterprise tier to get there, but it’s not the only path to reducing third-party exposure.

[ Traditional SaaS Tunnel Flow - Sovereignty Risk ]
Local Service  --->  Local Tunnel Agent  --->  [ Managed SaaS Cloud ]  --->  Public User / Client
                                                (TLS Termination &
                                                Data Path Exposure)

[ Self-Hosted Tunnel Flow - Complete Data Sovereignty ]
Local Service  --->  Local Tunnel Agent  --->  [ Enterprise Self-Hosted Gateway ]  --->  Public User / Client
                                                (Under Full Control of SecOps
                                                & Compliance Policy)

Getting the Regulatory Landscape Right

It’s tempting to lump GDPR, HIPAA, PCI-DSS, SOC 2, and NIS2 together as “the reasons you need data sovereignty,” but they don’t all do the same job, and conflating them makes it harder to build the right control for the right requirement:

• GDPR is the one most directly concerned with where personal data flows and is stored — cross-border transfer restrictions and data-residency expectations are core to it.
• HIPAA governs protected health information (PHI) in US healthcare contexts — access controls, audit trails, and safeguards for PHI in transit and at rest.
• PCI-DSS governs cardholder data specifically — network segmentation, encryption in transit, and restricting who (including third parties) can see cardholder data.
• SOC 2 Type II is an attestation framework built around trust-service criteria (security, availability, confidentiality, etc.) rather than a law; it’s about demonstrating your controls operate effectively over time, including controls over vendors.
• NIS2 (Directive (EU) ²⁰²²⁄₂₅₅₅) is primarily a cybersecurity risk-management and incident-reporting directive for essential and important entities in the EU — it mandates risk-management measures, 24-hour incident reporting, supply-chain security requirements, and management-level accountability. It does not itself function as a data-residency law the way GDPR does, though its supply-chain provisions are directly relevant to third-party exposure risk, which is where it does connect to the tunneling discussion.

The practical takeaway is the same either way — minimizing the number of third parties in your data path reduces exposure across all of these frameworks simultaneously — but if you’re citing a specific regulation to a compliance team, cite the one that actually says what you’re claiming.

Defining Data Sovereignty in Edge and Tunneling Architectures

To achieve real data sovereignty in remote-access and service-exposure architecture, you generally need three things:

1. Control plane isolation — auth policies, identity provider integration, and routing configuration run entirely within your own infrastructure.
2. Data plane isolation — payload traffic never traverses a non-contracted third party, with end-to-end encryption from client or ingress proxy directly to the backend.
3. Auditability and zero-trust governance — connection events, byte transfers, and authorization decisions feed directly into your own SIEM and identity stack.

2. Technical Evaluation Criteria for a Self-Hosted ngrok Alternative

When selecting a self-hosted ngrok alternative, weigh:

• Protocol and layer flexibility — Layer 7 (HTTP/1.1, HTTP/2, gRPC, WebSockets) as well as Layer 4 (TCP, UDP, database wire protocols)?
• Zero-trust network access (ZTNA) integration — does it rely on exposed public listening ports, or can it run outbound-only with identity-based access?
• Kubernetes-native capabilities — Ingress controller integration, CRDs, automated provisioning?
• Performance and multiplexing overhead — connection pooling, keep-alives, and latency under concurrency?
• Licensing and support model — genuinely open source, source-available, or commercial, and is there a support SLA?

3. Deep Dive into Self-Hosted Solutions

3.1 frp (Fast Reverse Proxy)

frp is a mature, high-performance reverse proxy written in Go, maintained by fatedier and contributors, designed to expose local servers behind NATs and firewalls. It’s one of the most widely deployed self-hosted tunneling tools in edge computing, IoT fleet management, and hybrid enterprise environments, and it’s genuinely open source under the Apache License 2.0 — that part of the original claim checks out.

                   +----------------------------------+
                   |       Self-Hosted Cloud / VPS    |
                   |                                  |
   Client  =======>|   frps (FRP Server)              |
 (Internet)        |   - Listens on Public Ports      |
                   |   - Handles TLS / Multiplexing   |
                   +----------------------------------+
                                    ^
                                    | Encrypted Control &
                                    | Data Tunnel (Multiplexed)
                                    v
                   +----------------------------------+
                   |       Private Enterprise Network |
                   |                                  |
                   |   frpc (FRP Client)              |
                   |        |                         |
                   |        v                         |
                   |   Internal App / API / DB        |
                   +----------------------------------+

Architecture. frp uses a dual-binary model: frps runs on a public server and handles port mapping and routing; frpc runs inside the private network and initiates an outbound connection to frps, maintaining a persistent, multiplexed connection.

Transport options. frp supports more transports than a simple TCP relay — as of the current frpc/frps configuration schema, the transport.protocol field accepts tcp, kcp (a UDP-based low-latency protocol), quic, websocket, and wss. QUIC support in particular is a meaningful addition for high-latency or lossy links, since it multiplexes streams over UDP without head-of-line blocking.

Proxy types. frp still supports the modes worth knowing:

• TCP / UDP — direct Layer 4 exposure for databases, SSH, and custom sockets.
• HTTP / HTTPS — Layer 7 exposure with domain-based virtual hosting and header/URL rewriting.
• STCP (Secret TCP) — requires the connecting client to prove a shared key before traffic is exposed, hiding the service from port scanners.
• XTCP (P2P TCP) — uses STUN-style negotiation to attempt a direct peer-to-peer connection between clients, bypassing the relay server for bandwidth-heavy workloads.

What’s newer. frp has an alpha-stage VirtualNet feature, gated behind an explicit featureGates = { VirtualNet = true } flag, that creates a TUN interface and does IP-level routing between machines rather than simple port forwarding — closer to a lightweight mesh network than a classic reverse proxy. It currently requires elevated (root/admin) permissions and is supported on Linux and macOS. Separately, the maintainer has said publicly that frp is working toward a v2 built around a more Envoy-like, highly extensible L4/L7 proxy core, though it’s explicitly not wire-compatible with v1 and is still in early development — don’t plan production architecture around it yet.

Configuration example (current TOML format):

# frps.toml (server)
bindPort = 7000
vhostHttpsPort = 443

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

webServer.addr = "127.0.0.1"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "STRONG_DASHBOARD_PASSWORD"

transport.tls.force = true

# frpc.toml (client)
serverAddr = "tunnel-gateway.yourcompany.com"
serverPort = 7000

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

transport.protocol = "quic"   # or "tcp", "kcp", "websocket", "wss"
transport.tls.enable = true

[[proxies]]
name = "internal-api-service"
type = "https"
customDomains = ["api-staging.yourcompany.com"]

Strengths. Lightweight, single-binary runtime; no external dependencies; low resource footprint; versatile L4/L7 routing plus P2P via XTCP; genuinely Apache-2.0 open source with an active maintainer and a real (if still pre-1.0) release cadence.

Trade-offs. No built-in identity/access management — securing L7 routes for OIDC/OAuth2 still means pairing frp with something like Nginx, Traefik, Caddy, or an OAuth2 proxy in front of it. The VirtualNet feature is alpha and not yet something to depend on in production.

3.2 zrok (Zero Trust, Built on OpenZiti)

zrok is an open-source project maintained by NetFoundry, built on top of OpenZiti, NetFoundry’s zero-trust overlay networking project. Both zrok and the core OpenZiti fabric are genuinely open source under the Apache License 2.0 — confirmed directly from NetFoundry’s own documentation, not just marketing copy. NetFoundry separately sells a licensed management suite and enterprise support for teams that want help operating OpenZiti at scale, but the fabric itself carries no license cost to self-host.

                                +---------------------------+
                                |      OpenZiti Fabric      |
                                |   (Self-Hosted Controller |
                                |      & Ziti Routers)      |
                                +---------------------------+
                                        /           \
                 Outbound Control      /             \ Outbound Control
                 & Data Channel       /               \ & Data Channel
                                     v                 v
+-------------------------------+   +----------------------------------+
|   Client Device / Consumer    |   | Private Service Environment      |
|                               |   |                                  |
| zrok access (mTLS Ephemeral)  |===>| zrok share (Dark Endpoint)       |
| No Inbound Network Attack     |   | No Open Inbound Firewall Ports   |
| Surface                       |   | Native Micro-Segmentation        |
+-------------------------------+   +----------------------------------+

The model. zrok eliminates open inbound firewall ports. Both the sharing side (your private API or app) and the consuming client establish outbound-only, mTLS-secured connections into the OpenZiti fabric — access is mediated by identity, not by IP address or an open port.

Sharing modes. zrok supports several backend modes, not just plain HTTP proxying: proxy mode forwards to a target address, web mode serves a directory as a static site, and drive mode exposes a directory as a virtual network drive over WebDAV, with a zrok copy command for one-way sync.

Self-hosting, accurately described. A production self-hosted deployment isn’t just “run a couple of Docker containers” — the current guides walk through standing up an OpenZiti controller and router, then the zrok controller, one or more zrok frontends, and a metrics bridge, backed by PostgreSQL, RabbitMQ, and InfluxDB. This is a real, multi-component system, which is exactly the operational trade-off the original draft’s licensing table already (correctly) flagged.

A security nuance worth calling out. By default, zrok shares — public and private — use what the project calls the “open” permission mode: any user of your zrok instance who knows the share token can access it. A --closed flag on zrok share (paired with --access-grant <email> to name specific accounts) restricts a private share to explicitly authorized identities. If you’re deploying zrok specifically for its zero-trust story, --closed shares with explicit access grants are the configuration that actually delivers on that story — the default is more permissive than “zero trust” implies at first glance.

Corrected CLI example. The original draft’s example commands were close but used a non-representative token format and an unnecessary --bind flag on the client. A more accurate walkthrough:

# 1. Point the CLI at your self-hosted instance and authenticate
zrok login --api-endpoint https://zrok.yourcompany-internal.net <api-token>

# 2. Share a local service privately, restricted to named accounts
zrok share private --headless --closed --access-grant teammate@yourcompany.com 127.0.0.1:9090

# Output includes a share token, e.g.: wr3hpf2z5fiy

# 3. On an authorized machine, access the private share
zrok access private wr3hpf2z5fiy

Strengths. A genuinely zero-open-port model with native mTLS and micro-segmentation; real Apache-2.0 licensing at every layer; backend modes beyond HTTP (files, WebDAV); built-in per-share permission modes for finer-grained access control than a simple shared secret.

Trade-offs. Meaningfully higher operational complexity than a single-binary reverse proxy — you’re standing up and operating a distributed system (controller, router(s), frontend(s), message broker, metrics store), not just a relay. The default permission mode is more open than the “zero trust” framing suggests unless you explicitly lock it down.

3.3 Inlets

This is where the earlier draft needed the biggest correction. Inlets Pro is not open source. The original, HTTP-only “inlets OSS” project (v1/v2) was free and open source, but its own GitHub repository now describes it as superseded and no longer receiving updates. The actively maintained product — inlets Pro, built by Alex Ellis (founder of OpenFaaS) — is a closed-source binary distributed under a commercial End User License Agreement: you need a paid license key or Gumroad subscription to run it, and the source is not published. The surrounding tooling, inlets-operator (which auto-provisions exit-node VMs for Kubernetes LoadBalancer services) and inletsctl (a CLI for creating exit-servers), are separate open-source utilities, but the tunnel engine they orchestrate is commercial software, not “dual-licensed open source.”

+-------------------------------------------------------------------------+
|                  Public Cloud VPS / Edge Gateway                        |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | inlets-pro exit-node (Receives Public Traffic)                  |   |
|   | Listens on Ports 80 / 443                                       |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+
                                    ^
                                    | Secure Control & Data Tunnel
                                    | Encrypted WebSockets / TLS
                                    v
+-------------------------------------------------------------------------+
|                 Private Enterprise Kubernetes Cluster                   |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | inlets-operator (Auto-provisions exit-nodes)                    |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|   +-------------------------------+---------------------------------+   |
|   | inlets-pro client (Multiplexes tunnel traffic)                  |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|                                   v                                     |
|   +-----------------------------------------------------------------+   |
|   | Ingress-Nginx / Traefik / Envoy Service (ClusterIP)             |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+

What it does well. inlets Pro tunnels raw Layer 4 TCP over encrypted WebSockets, which matters for Kubernetes ingress controllers that need to see raw TCP to inspect TLS SNI, handle mTLS, or drive cert-manager automation. The inlets-operator watches for Service objects of type LoadBalancer in a cluster with no cloud load balancer available, provisions a small VM on a supported cloud provider, and wires up the tunnel automatically — genuinely useful for bare-metal, on-prem, or edge Kubernetes.

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
  annotations:
    dev.inlets.operator/provider: "digitalocean"
    dev.inlets.operator/region: "ams3"
    dev.inlets.operator/plan: "s-1vcpu-1gb"
spec:
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https
  selector:
    app.kubernetes.io/name: ingress-nginx

What’s new since the original draft. Alex Ellis’s team now also offers Inlets Uplink, aimed specifically at SaaS and platform teams that need to run many customer-facing tunnels from a Kubernetes control plane — priced as a flat monthly control-plane fee plus a per-tunnel charge, again as a commercial license rather than an open-source release.

Strengths. Purpose-built for Kubernetes, with genuine L4 TCP transparency and cert-manager integration; automated exit-node provisioning across major clouds; a company behind it that offers real commercial support.

Trade-offs. It is commercial software you license, not something you can audit, fork, or run without paying — a materially different trust and cost model than frp or zrok. If “no third-party dependency at all” is the goal, Inlets’ relationship with OpenFaaS Ltd as the exit-node software vendor is worth weighing even though the traffic itself never leaves your infrastructure.

3.4 Pangolin — A Newer Entrant Worth Knowing About

Since the tunneling landscape has moved since the original draft was written, it’s worth adding a fourth option that didn’t exist in its current form when comparisons like this were first being written: Pangolin, a self-hosted tunneled reverse-proxy platform built on WireGuard (via a custom userspace client called Newt) and Traefik, with identity and access management built in from the start rather than bolted on. It markets itself directly as a self-hostable alternative to Cloudflare Tunnel, and it gained real traction quickly — its creators reported over 12,600 GitHub stars and 140,000+ installs within five months of launch. It’s open source, and the company behind it also offers an optional managed cloud coordination layer for teams that want automatic failover without giving up self-hosted data flow.

Where it fits relative to frp, zrok, and Inlets. Pangolin’s pitch is squarely aimed at the gap the frp section above calls out — a self-hosted tunnel with centralized SSO-backed authentication, role-based access control, TOTP, and per-resource access rules out of the box, without needing to separately deploy an OAuth2 proxy or an OpenZiti fabric to get there. It trades some of zrok’s zero-open-port purity (Pangolin’s central server still terminates connections and needs to be reachable) for a considerably simpler operational model than standing up OpenZiti, and it trades some of frp’s minimalism for built-in identity features frp doesn’t natively have.

4. Architectural Comparison Matrix

Capability	ngrok (SaaS)	frp	zrok (OpenZiti)	Inlets Pro	Pangolin
Data sovereignty	Limited by default; BYOC/private edition available on enterprise plans	Full control	Full control	Full control (engine is commercial software)	Full control
License	Proprietary SaaS	Open source (Apache 2.0)	Open source (Apache 2.0)	Commercial (closed source, license key)	Open source
Network layer support	L4 & L7	L4 (TCP/UDP), L7 (HTTP/S), P2P, experimental IP-level VirtualNet	L4 & L7 over a zero-trust fabric; also files/WebDAV	L4 TCP & L7 HTTP/WebSockets	L4 (WireGuard) & L7 (via Traefik)
Inbound firewall ports	None required (SaaS)	Requires open port on frps	None required (dark by default)	Requires open port on exit-node	None required on protected resources
Kubernetes integration	Custom ingress controller	Manual / Helm	Operator / SDK	Native inlets-operator	Not Kubernetes-native
Identity/access control	SaaS OAuth / IP allowlists	Token auth; needs an external IdP proxy for SSO/OIDC	Native mTLS identities; per-share permission modes	License-key auth; TLS	Built-in SSO, RBAC, TOTP
Deployment footprint	Cloud SaaS + local agent	Dual single binary (frps/frpc)	Controller + router(s) + frontend(s) + metrics stack	Exit-node VM + client	Central server + Traefik + Newt clients

5. Security Hardening Blueprint for Self-Hosted Ingress Tunnels

Deploying a self-hosted gateway shifts security governance entirely to your internal SecOps team. A production checklist:

+---------------------------------------------------------------------------------------------------+
|                                PRODUCTION HARDENING CHECKLIST                                     |
+---------------------------------------------------------------------------------------------------+
|  [1] TLS 1.3 Strict Enforcement   --> Terminate or pass-through TLS 1.3; disable legacy ciphers.  |
|  [2] Identity Proxy & OIDC        --> Gate public L7 endpoints behind OAuth2-Proxy / Keycloak.    |
|  [3] Rate Limiting & DDoS         --> Enforce connection limits and burst controls via eBPF/Nginx.|
|  [4] Audit Telemetry Integration  --> Pipe JSON connection logs directly to SIEM (Splunk/Datadog).|
|  [5] Least-Privilege Segmentation --> Isolate tunnel agent processes using Docker/AppArmor/SELinux.|
+---------------------------------------------------------------------------------------------------+

1. Enforce OAuth2/OIDC at the gateway level. Never expose administrative panels or unauthenticated staging APIs directly. Pair frps or an inlets exit-node with OAuth2-Proxy, Authelia, or Authentik backed by your enterprise IdP. (zrok and Pangolin get identity enforcement closer to natively — see above.)
2. Segment the blast radius. Run tunnel clients inside isolated container networks or unprivileged Linux users; use Kubernetes NetworkPolicy objects to stop a compromised tunnel-client pod from scanning adjacent services.
3. Centralize audit logging. Stream connection lifecycle logs — source IPs, TLS handshake parameters, byte counts, token identifiers — to an immutable log store or SIEM. [ Tunnel Gateway ] ---> [ Syslog / Vector Agent ] ---> [ SIEM: Splunk / Elastic / Datadog ]

6. Strategic Recommendations

• Local development, staging, IoT fleets: frp remains the fastest path to a lightweight, zero-cost, genuinely open-source tunnel for internal APIs, SSH sockets, or edge hardware.
• Strict zero-trust / regulated environments where no inbound port is acceptable at all: zrok, provided you configure --closed shares deliberately rather than relying on the open-by-default permission mode, and you’re willing to operate the OpenZiti fabric it depends on.
• Cloud-native, on-prem, or hybrid Kubernetes ingress: Inlets Pro, going in with eyes open that you’re licensing commercial software, not adopting an open-source dependency.
• Small teams or self-hosters who want SSO-gated access without standing up OpenZiti or Kubernetes: Pangolin is the newest and, for that specific use case, arguably the lowest-friction option of the four.

Conclusion

The move away from managed SaaS ingress tunnels is real, but the reasoning behind it deserves the same rigor as the architecture itself. Not every compliance framework says what it’s often assumed to say, and not every “open-source alternative” is open source all the way down — Inlets Pro being the clearest example here. frp, zrok, and Pangolin genuinely are open source and genuinely do put the full data path under your own control; Inlets Pro puts the data path under your control while the engine itself remains a paid, closed-source product. Knowing which is which is the difference between an accurate compliance argument and one that falls apart under a vendor-security-review question.

---

Sources

• fatedier/frp — GitHub repository, README, and releases
• frp official documentation (gofrp.org)
• zrok overview — NetFoundry Documentation
• zrok — Open Source licensing page, NetFoundry Documentation
• zrok self-hosting deployment guide (Linux) — NetFoundry Documentation
• zrok Permission Modes — openziti/zrok GitHub docs
• OpenZiti — Zero Trust Networking, Secured by Identity
• inlets PRO — GitHub repository and licensing terms
• inlets.dev — product site
• Inlets Uplink pricing — OpenFaaS Gumroad listing
• Pangolin — GitHub repository
• Pangolin — Y Combinator launch page
• NIS2 Directive — European Commission, Shaping Europe’s Digital Future
• ngrok BYOC / private edition — AWS Marketplace listing

---

Changelog

Editorial pass — August 28, 2026

1. Removed the meta description line from the top of the draft (not part of the article body).
2. frp: Confirmed Apache 2.0 licensing directly against the fatedier/frp repository (the correct upstream — not to be confused with unrelated forks). Added currently-supported transport protocols (quic, kcp, websocket, wss alongside plain tcp), which the original draft didn’t mention. Added the alpha VirtualNet TUN-based feature and a note on the in-progress, not-yet-compatible frp v2 effort, both sourced from the project’s own README and release notes.
3. zrok: Confirmed Apache 2.0 licensing for both zrok and the underlying OpenZiti fabric directly against NetFoundry’s documentation. Replaced the vague “Docker Compose or Kubernetes charts” self-hosting description with the actual current component list (controller, frontend, metrics bridge, PostgreSQL, RabbitMQ, InfluxDB). Corrected the CLI example (token format, added the --closed/--access-grant flags) and added a security-relevant fact the original draft missed entirely: zrok shares default to an “open” permission mode accessible by any user on the instance, not the closed-by-default model the “zero trust” framing implies.
4. Inlets: This was the largest correction. The original draft described Inlets Pro as part of an open-source family with a “dual-licensed model.” In fact, Inlets Pro is closed-source, commercial software requiring a paid license key; only the discontinued, HTTP-only legacy “inlets OSS” project and the surrounding orchestration tooling (inlets-operator, inletsctl) are open source. Updated the comparison matrix and prose accordingly, and added the newer Inlets Uplink product with its current public pricing.
5. Regulatory framing: The original draft implied GDPR, HIPAA, SOC 2, PCI-DSS, and NIS2 all similarly mandate data residency. Added a section clarifying what each framework actually governs, in particular correcting the claim that NIS2 “strictly regulates data residency” — it’s primarily a cybersecurity risk-management and incident-reporting directive; GDPR is the framework that actually drives data-residency obligations.
6. ngrok balance: Added a factual note that ngrok offers BYOC and private-edition deployment options at the enterprise tier, which tempers the draft’s implicit “SaaS means zero control” framing for that segment of customers.
7. Added Section 3.4 (Pangolin): A newer, fast-growing, genuinely open-source self-hosted tunnel/reverse-proxy platform (WireGuard + Traefik, built-in SSO/RBAC) that didn’t appear in the original draft, added to keep the comparison current and to fill the “built-in identity” gap the draft itself flagged in frp.
8. Updated the architectural comparison matrix (Section 4) and strategic recommendations (Section 6) to reflect all of the above, and converted the ASCII comparison table to a proper Markdown table.
9. Added a Sources section linking primary documentation for every corrected or added claim.