inlets-pro: a self-hosted tunnel for exposing local HTTP and TCP services

A tunnel where you hold the public end

inlets is described as reinventing the concept of a tunnel for a Cloud Native world, and the argument is about who controls the data.

The framing is that with inlets you are in control of your data, unlike with a SaaS tunnel where shared servers mean your data may be at risk. The tunnel client usually runs in a private network, and the server may run on a network with a public IP. When the two are connected, it is like the private server is actually on the Internet.

That is the whole architectural idea in one sentence, and it is the difference from the hosted tunnel services. A hosted tunnel provider owns the public endpoint, the DNS and the termination. inlets puts both ends in your own infrastructure, so you can host the tunnel server wherever you want for low latency, expose as many HTTPS websites as you like, expose whatever TCP ports you need, and use your own DNS instead of paying per domain.

The other claim on the list is about rate limits. The readme puts it as getting more done, without running into rate-limits imposed by a service provider. For a team that has hit a provider's connection ceiling or its per-domain pricing, that is the actual reason to run the thing yourself.

The use cases listed are concrete: exposing your local endpoints on the Internet, self-hosting Kubernetes or K3s clusters, deploying and monitoring apps across multiple locations, supporting your customers remotely, and hybrid cloud for legacy TCP applications. The blog links cover the TCP side specifically, with a tutorial on tunnelling a private Postgresql database and one on connecting on-premises databases to Kubernetes in the cloud.

One clarification is worth taking at face value. Inlets is not a VPN, it is for exposing local services on another network or on the Internet. That distinction matters because a VPN moves your client into a remote network, while inlets brings a public address to a service that stays where it is.

One binary that is both client and server

Every inlets tunnel has two parts, its server and its client, but they are one binary and can run entirely within userspace. That single design decision explains most of the deployment options.

It is a single binary for MacOS, Windows and Linux, and it works on bare-metal, in VMs, in containers and on Kubernetes. The same executable is started with different arguments depending on which role it plays, which is why there is no separate server package to install, no client package to install, and no version skew between the two ends to think about.

Running entirely within userspace is the other half of it. A tunnel that needs a kernel module, a privileged init or a specific network namespace is a tunnel that only runs on the platforms its author tested. Keeping it in userspace means the same artifact runs in a container image and on a laptop, and it means the tunnel can be deployed next to the service it exposes rather than on a dedicated host.

The distribution options follow from that. The binary can be obtained as a stand-alone executable or via a container image, and a container image is published at ghcr.io/inlets/inlets-pro with tags listed on the container package page. For Kubernetes there is a third path: set it up manually, with Helm, or with a Kubernetes Operator, and the readme points at the helm chart in the repository and at inlets-operator if you want an integration for your LoadBalancers on Kubernetes.

The Makefile in the repository shows the shape of the Helm side, because the charts are the packaged part of the project. There are three charts, inlets-http-server, inlets-tcp-server and inlets-tcp-client, and the default make target verifies the chart images in the remote registries with arkade before packaging them. A separate upgrade-charts target upgrades the images in the remote registries with arkade, and the charts target packages each chart with helm, moves the resulting tarballs into docs/charts and then regenerates the chart repository index with helm repo index against the https://inlets.github.io/inlets-pro/charts URL.

That last step tells you the charts are published as a Helm repository rather than only living in the tree, so a cluster installs them with helm repo add and a normal dependency entry.

Installing the binary and the container image

The install path in the readme is a two-line download that leaves an executable in the current directory.

    curl -SLsf https://github.com/inlets/inlets-pro/releases/download/0.9.23/inlets-pro > inlets-pro
    chmod +x ./inlets-pro

Note that the URL pins the release to 0.9.23, which is not the current version. The recent releases are 0.12.0 on 2026-10-08, 0.11.19 on 2026-10-07 and 0.11.18 on 2026-10-05, and the readme points to the releases page for a binary for a different architecture. So the pinned example is a starting point that you should update, and the releases page is the place to confirm what the current artefact is called for your platform.

The container route is the same binary in an image at ghcr.io/inlets/inlets-pro, with the tags page linked from the readme. Since the client and the server are the same executable, the image serves both roles, and the difference between a client container and a server container is in the arguments and the configuration rather than in the image.

The last push was on 2026-10-20, after the 0.12.0 release on 2026-10-08, so the tree is fresher than the latest tagged release. The project is not archived, and the default branch is master.

Before any of this, there is a commercial condition that sits above the installation steps. A valid license key or Gumroad subscription is required to launch or deploy inlets, and by using the software you agree that you have purchased a license and are bound by the terms of the End User License Agreement, which is the EULA.md file at the top of the repository. The subscription is bought through a Gumroad listing, monthly or annual.

That is the first thing to settle before spending an afternoon on a deployment, because the binary will not start without a key. The recorded licence is unknown, so the EULA file is the document to read rather than any summary of it.

The documented use cases, and what each one needs

The readme separates its guidance into a cloud-native section and a section on modernising apps and exposing private services, and the split reflects two different deployment shapes.

For cloud natives, the links are Kubernetes Ingress with the inlets-operator, exposing Ingress with the helm chart, reliable local port-forwarding from Kubernetes, connecting on-premises databases to Kubernetes in the cloud, and monitoring multi-cloud Kubernetes with Prometheus and Grafana.

The local port-forwarding case is the one worth examining, because it is where the single-binary decision pays off. Port-forwarding from a cluster usually means the kubectl port-forward command holds a connection open, and if your laptop sleeps or the connection drops, the tunnel is gone. A tunnel that runs as a deployment inside the cluster with a proper server component does not have that failure mode, because the lifetime of the tunnel is the lifetime of the pod rather than the lifetime of a terminal.

For the modernising section, the links cover exposing one or more local HTTP services via HTTPS, the case where you cannot get a static IP from your ISP, connecting existing apps to public cloud, and tunnelling a private Postgresql database. That last one is the clearest statement of what a TCP tunnel is for: a database on a private network with no public address, reachable by a client that connects to the tunnel server's public endpoint, with the TCP traffic tunnelled through to the database.

The point of the TCP support is that a lot of legacy infrastructure has no HTTP in front of it. A database, an SSH server, a queue, an old internal API, none of it speaks TLS-terminated HTTP in a way a web tunnel can front. Exposing a Postgres port through the tunnel is what lets a modern cloud application reach it without a VPN and without a public IP on the database host.

The FAQ reference is linked from the readme as the place to read more about how inlets differs from other solutions, and the documentation site at docs.inlets.dev is the primary reference for the CLI as well, with a CLI reference guide at docs/cli-reference.md inside the repository.

Where inlets sits against a hosted tunnel and against a VPN

Two comparisons are worth making, and the readme makes the VPN one itself.

A hosted tunnel service, the kind where a vendor runs the public endpoint and you run a client agent, is the closest alternative. The difference in approach is ownership. The hosted service gives you a public address and a managed connection for a monthly fee, and the tunnel traffic passes through infrastructure you do not own, which is the shared-server risk the readme points at. inlets replaces that endpoint with a server you run, which means you choose where it lives, you choose the DNS, and you are not bound by per-domain or per-connection pricing.

The cost of that swap is operational. You now run a public-facing server, you have to keep it patched and monitored, you have to obtain and renew certificates for the HTTPS services it fronts, and if it goes down your tunnels go down. A hosted service absorbs all of that into a monthly fee, and for a solo developer exposing one service for a demo, the hosted option is usually the better trade.

A VPN is the other comparison, and the readme explicitly separates itself from that. A VPN connects your client into a remote network, which changes your routing and puts the client behind the remote gateway's NAT. inlets inverts that: the service stays where it is and the public endpoint moves to it. For an application server that needs to be reachable from the internet without changing its own network position, that inversion is the whole point.

There is a third path that the readme does not mention but the ecosystem implies: doing it yourself with an SSH reverse tunnel and a small amount of glue. That gets you a public endpoint for free, but you get no HTTPS termination, no dashboard, no TCP multiplexing for many services, and you inherit the operational cost without the tooling. The tooling in this repository is what inlets-pro is selling, along with the licence.

The honest summary of the trade is that inlets-pro converts a monthly per-service fee into a server you run plus a subscription, and the conversion makes sense when you have several services, need your own DNS, need TCP as well as HTTP, or have hit a provider's limits.

Editorial conclusion

inlets-pro fits a team that wants to own its tunnel endpoint and DNS rather than pay a SaaS provider per domain or per connection, and it does not fit a user looking for a free or self-service tool, because the readme states that a valid license key or Gumroad subscription is required to launch or deploy it. Before evaluating it, read EULA.md in the repository, since the licence is recorded as unknown in the repository metadata while the project ships an End User License Agreement, and confirm your chart images pull from ghcr.io/inlets/inlets-pro with the tags you intend to run.

Frequently asked questions

Official sources

1. inlets/inlets-pro on GitHub
2. Issues
3. Project website
4. README
5. Releases