I started a new OSS project over the holidays last year, it was a side-project and not meant to be anything big.
My team at the time needed a way to receive webhooks from GitHub to test CI/CD for OpenFaaS Cloud. The obvious options didn't work - we couldn't use Ngrok because it was banned by corporate policy and we couldn't use other tooling due to port blocking. I explored some of the other tooling out there, but the team had no budget.
I wanted to create a simple solution using Golang and websockets so that we could receive webhooks through HTTP. The reason this works through private networks is that the client speaks first, and then establishes the persistent connection.
The classic use-case for a tunnel is to receive webhooks from GitHub and other API providers.
The project was called inlets and the 1.0 release received lots of comments on Hacker News, this was enough to convince me to spend more time on the project.
inlets
inlets is a reverse-proxy and L7 HTTP tunnel that allows users behind NAT, firewalls, and those within private networks to expose their local services to the Internet.
The project has over 5k GitHub stars and 30 contributors. Follow the official Twitter account for news and updates - @inletsdev
Inlets is formed of a server and client component. We run the client on our computer and then the server on a VM or host which has a public IP. The cheapest option would be something like a DigitalOcean droplet at 5 USD / mo.
You can even share local websites made with create-react-app and cloud native tools like Prometheus, Grafana, and OpenFaaS.
Darren Shepherd made some contributions and replaced some of my bespoke websocket code with a library used in Rancher, that became the 2.0 release which received even more comments and upvotes.
After the initial success of inlets I developed inlets-pro which adds L4 / TCP proxying and automatic TLS. You can now expose any kind of service to the Internet such as Caddy or CassandraDB. The first thing I tried with inlets-pro was to run Kubernetes on my Intel NUC along with cert-manager to get a TLS certificate directly on the computer plugged in to my home network.
Inlets also gained a logo, a GitHub org, a place on the CNCF landscape, stickers, and a t-shirt design.
Checkout the two projects on GitHub:
As the year end on, I saw other opportunities to expand and make inlets even easier to use.
inlets on the road
I spoke at Cloud Native Rejekts in San Diego on inlets as a solution to the IPv6 address-space problem. You can get the slides below:
My live demo showed cert-manager, k3s, and OpenFaaS being served over a mobile hotspot, using a battery pack and a Raspberry Pi 4.
Recorded demos are for wimps.
— Alex Ellis (@alexellisuk) November 17, 2019
journalctl -u k3s showed the IPv6 address I got from tethering confused k3s.. here we go with IPv6 disabled @inletsdev with TLS served from the RPi pic.twitter.com/BgTwNoIX51
Ellen Korbes included inlets in a talk titled "Kubernetes developer tooling" and spoke at several large events.
Presenting inlets @alexellisuk pic.twitter.com/WMn3uaeYv8
— Simon P (@SimonHiker) October 30, 2019
Thanks to Iheb for designing the logo. I sent him a pack of free SWAG to say thank you.
Received some @openfaas #swag and the new @inletsdev t-shirt 🙂 #teamserverless
— Iheb ☁️ (@iboonox) November 4, 2019
Thank you @alexellisuk pic.twitter.com/KH2tuYNTg2
Inlets gained a place on the CNCF Landscape amongst other service proxies like MetalLB, Nginx, and Traefik
Really excited to see @inletsdev growing up and leaving home with its own @github org and a place on the @CloudNativeFdn Landscape.
— Alex Ellis (@alexellisuk) October 16, 2019
A big thank you to @iboonox for providing a logo. Website will be coming soon.
Check it out, give it a ⭐️https://t.co/5pPjk2MlpH pic.twitter.com/NuDqCgkN5g
Here's my original conceptual diagram, found in an old notepad, the current design is still very close to this.
My original design sketch for @inletsdev OSS, back from late last year.
— Alex Ellis (@alexellisuk) December 23, 2019
Going back through old notes, some OSS features, ideas and experiments took a while to get off the ground. pic.twitter.com/3r6ktZZgpT
Automation for inlets / inlets-pro
Inlets and inlets-pro also has automation either through the inletsctl
CLI which provisions a cloud host and gives you a connection string, or through the Kubernetes Operator called the inlets-operator.
The inlets-operator detects services of type LoadBalancer in your private Kubernetes cluster, provisions a cloud server and then runs a Pod with the inlets client. That means anything you run in your Kubernetes cluster can be exposed on the public Internet.
Wrapping up
You can run inlets using a single binary, it has two parts - inlets server
and inlets client
. Both parts can run on any network, you can even bridge between two private VPCs, but most users find inlets useful for connecting private networks to the Internet.
There's been strong inital interest in inlets-pro, which also works with inletsctl and inlets-operator. You can get a free trial or request a demo on the homepage
The easiest way to start is to try out inletsctl, which will provision a host on DigitalOcean, GCP, Packet, Civo, or Scaleway. You'll get a command at the end which you can customise and use to connect your local services to the Internet.
All inlets tooling works on regular compute, Raspberry Pi and ARM64 out of the box.
What are the other use-cases?
- getting incoming network connections
- CDN & edge access to APIs and websites
- sharing work freelance websites and work with clients
- integrating APIs with partners
- command and control of edge devices
- connecting VPCs or private networks
- port-forwarding Kubernetes services
inletsctl kfwd
and "kurun"
Add your use-case to ADOPTERS.md
Connect with the community
-
Become one of my GitHub sponsors
-
Follow @inletsdev on Twitter and help us reach 1k followers
-
Discuss the project in #inlets on OpenFaaS Slack