Why do Developer Advocates like network tunnels?

Alex Ellis

Over the past three years we’ve seen inlets has become a hit with developer advocates, but why? And how does it stack up against Tailscale, Ngrok and Wireguard?

Developers like me

Inlets began its journey on the cusp of 2019 over the holiday season as a Proof of Concept (PoC), with the simple idea of making a tunnel that could be self-hosted and didn’t have any artificial limits.

I built it for myself. I wanted a tunnel that was born in the cloud, built for Kubernetes, built for containers, without rate-limits and that followed the same principles that had made OpenFaaS so popular - simplicity, security and portability.

The incumbent solutions like Ngrok and Cloudflare Argo were not a good fit for several reasons:

  • They were tied to a SaaS, meaning all your data had to pass through the vendor’s servers
  • You had to buy your domain names from the parent company, or transfer it there
  • In the case of Ngrok, they were heavily rate-limited, even on paid plans, with stingy bandwidth limits
  • Ngrok was and possibly still is banned by many corporate networks, by simply blocking the domain name “*.ngrok.io” used to connect tunnels
  • Neither product had container images, Kubernetes integrations or Helm charts

They just were not built for the needs of Cloud Native practitioners. Ngrok was built many years ago when most developers wrote in Ruby or PHP and ran it directly on their own machine for development.

So inlets was a response to these issues, and quickly gained popularity with its intended audience.

Two of the maintainers of cert-manager started using the inlets-operator to get public IPs for KinD clusters, to test Let’s Encrypt integrations and to run demos at KubeCon.

And it was really popular with personal users and developer advocates who used it to run demos with customers, on live-streams and at events like KubeCon.

Nathan Peck at AWS built out an AWS ECS Anywhere lab and told me that traditional VPNs did not work well, and that he’d used inlets TCP tunnels to load balance instead:

The infamous CNCF parody account “Memenetes” noticed us and even added inlets to his Cloud Native Puzzle “Now with inlets and K3s”:

And inlets was presented at various conferences like the OSSummit and Cloud Native Rejekts by the community:

Ellen Korbes, used inlets at their time at Garden to get public ingress for demos.

Over the years since 2019, there have been too many users to mention individually, but here are a few:

Whilst not a developer advocates, here are three other examples I really enjoyed:

Mark Sharpley from the UK connected his solar-powered boat to the Internet with inlets so he could monitor it with Prometheus. That’s about as Cloud Native as it gets.

And Zespre Schmidt spontaneously wrote up a really comprehensive guide to inlets for personal use: A Tour of Inlets - A Tunnel Built for the Cloud

Johan Siebens, a Kubernetes and infrastructure contractor went on a content spree, writing dozens of tutorials and utilities for inlets, including a popular one on hosting tunnel servers for free on Fly.io and using ArgoCD to manage multi-cloud Kubernetes clusters.

Over the three years, we’ve had a lot of love from the community.

I want to say thank you from me. We’re still building inlets for developers and would love to hear from you on how you’re using it for personal use or at work.

The core of inlets is a single binary, but there are dozens of Open Source tools built around it:

The inlets-operator looks for LoadBalancer services in Kubernetes, then creates a cheap tunnel VM with the inlets-pro server pre-installed, runs a Pod in the cluster with the client, and then updates the service IP.

Ivan Velichko, then SRE at Booking.com, now developer at Docker Slim wrote a detailed review and explanation of the inlets-operator, that created tunnel servers for LoadBalancers for private clusters: Exploring Kubernetes Operator Pattern.

Inlets Operator animation

Inlets Operator animation

Not everyone needed to run inlets inside Kubernetes, after all, containerd, Docker and Firecracker are also Cloud Native runtimes.

That’s where the inletsctl CLI came in. It shares a cloud provisioning library with the inlets-operator, and can be used to set up a new tunnel server in less than 30 seconds.

inletsctl create \
  --provider digitalocean \
  --access-token-file ~/.digitalocean/token \
  --region lon1

There’s also options for Let’s Encrypt and for TCP tunnels.

After a few moments, usually under 30 seconds, you’ll get a “connection string” for the inlets-pro client which you can run on your machine.

Some users wanted to set up a TCP tunnel server, and multiplex multiple different TCP services over it. They’d started using HAProxy, but found it wasn’t available on Windows, so we wrote a tiny OSS TCP load balancer as an alternative to HAProxy which has over 400 stars on GitHub.

Nathan LeClaire and Sven Dowideit integrated the code directly into their new start-up product to save on writing boiler-plate code.

Inlets doesn’t just do remote port forwarding like Ngrok, it also does local forwarding.

A developer in the UK Government kept banging his head against the wall with the flakiness of “kubectl port-forward”, so we wrote a feature to help him: Fixing the Developer Experience of Kubernetes Port Forwarding.

Han Verstraete, who works at OpenFaaS Ltd uses local tunnels to access Prometheus, Grafana and OpenFaaS from within his KinD clusters whilst working on OpenFaaS Pro. You can find out how in my article: A Primer: Accessing services in Kubernetes.

Han also uses Zerotier to access his whole home network when he leaves the house. I’d tried to convince him to try switching to inlets a few times, but knew he was happy with what he had.

After he saw a draft of this blog post he told me:

“When I was on Ski holiday last month, I tried to ssh into one of my machines at home but ZeroTier was too flaky over my mobile connection. So I setup an Inlets tunnel and got into my machine without any issues.”

That reminds me of a time where I set up a tunnel server on Fly.io for one of my own family vacations. I also set up a Tailscale VPN and thought I’d compare the experience of either whilst away.

From the holiday cottage, I copied a file from my MacBook over to a machine on my home network. What surprised me was that inlets was faster on every run than Tailscale. That was even with Tailscale reporting a direct peer connection over UDP, without relay servers. Port-forwarding was marginally faster than inlets, but not enough to warrant the management and privacy issues it has.

Faster than a VPN

In a real-life test, inlets was faster than the most trendy, VC-funded VPN.

Let’s not forget, that I also use inlets. When I was working on a product that had to integrate with webhooks from GitHub.com and GitLab.com at the same time, I closed the lid on my laptop, opened it again in a cafe down the road and everything continued to work exactly the same.

You can’t do that with a static IP or port forwarding set up on your router.

Is inlets right for you as a developer or advocate?

With the popularity of free SaaS solutions like Ngrok and modern VPNs like Tailscale, you’ve got to ask yourself. Should you pay for an inlets subscription?

If you want to access your mom’s printer whilst on the road, from your iPhone, for free. There’s really nothing better than Tailscale for that.

Want to get remote access to every host on your network whilst away from home? Tunnels are great for accessing SSH, Kubernetes, RDP, or specific services. A VPN like Zerotier or Wireguard is better for getting raw access to everything on a machine or network.

You’re super cost sensitive and don’t want to pay anything to self-host a low-traffic HTTP endpoint, think about port-forwarding on your router, along with a machine to run a cron-job to update a dynamic DNS record. It’s a bunch of work, but it’s “free”. And of course, you give out the location of your home to any users.

If you are cost sensitive and occasionally need to debug webhooks, Ngrok will probably be fine, just don’t go beyond the rate limits. (This is easy to do - ask me how I know)

If you’re a commercial business looking at Ngrok or Inlets, inlets works out significantly cheaper and you can use it for much more than just webhooks.

If you’re a service provider and want to connect to customer devices and services, Tailscale may work out expensive (there is no public pricing available), and is really better for connecting entire hosts or subnets, than individual services. Check out what we’re doing with inlets uplink.

Want to make your Kubernetes home-lab accessible from anywhere like a managed Kubernetes service? Check out this tutorial for inlets

Want to go deeper on technical differences? Check out the inlets FAQ

So where does inlets excel?

  • Customer demos that require a public IP address.
  • When your ISP won’t give you a public IP, or you can’t take it with you. Yes. With inlets your IP will move with you. You can even use it on a train, plane or a solar-powered boat
  • You’re a developer advocate like Kat, Ellen, the cert-manager team, or Marino team - and you want to integrate with Istio, Kubernetes Ingress Controllers or need Load Balancers that have real IPs
  • You’re a vendor or part of the DevRel team and run a booth or talk at conferences - people in the audience and on the show floor will be able to access any demos you deploy to make them more interactive and memorable.
  • You’ve been burned by VPNs or SaaS tunnels and want something that just works in dev and production.

So why do developers advocates pay for inlets? They can run 2-5 tunnels at very low cost, it improves their effectiveness with demos, workshops and builds more customer engagement.

You can try inlets for free.

Or check out the code for the inlets-operator - a Kubernetes operator to automate tunnel clients and VMs with public IPs.

Inlets Operator in action

Probably the easiest way to get a Load Balancer from <pending> to publicly accessible with KinD, minikube, K3s, etc.

Want to talk to us?

Feel free to reach out for a call to talk more, or check out the links I’ve included above to see how other customers are using inlets today.

Subscribe for updates and new content from OpenFaaS Ltd.

By providing your email, you agree to receive marketing emails.

Setup your first HTTPS or TCP tunnel today. It's private, self-hosted with no bandwidth or rate-limits.

View pricing