A Kubernetes Operator for Cloudflare Tunnel Route Mappings
I have written a Kubernetes operator to help provision Cloudflare Tunnel route mappings automatically.
The problem was fairly simple. I already had Cloudflare Tunnel running in the cluster, and I had a small number of routes configured manually, but I did not want to keep managing every hostname through the Cloudflare UI as more sites moved over. I also did not want to fall back to a wildcard route, because not every domain and subdomain was intended to move that way.
Operationally, I wanted the route mappings to behave like the rest of the platform: declared in Kubernetes, managed through GitOps, and reconciled predictably from source control rather than maintained by hand in a web interface.
So I built an operator for that specific gap.
The operator watches TunnelPublicHostname resources and reconciles public hostnames into an existing Cloudflare Tunnel configuration. The preferred model is ingress-backed publication, where workloads continue to use normal Kubernetes Ingress, Traefik continues to own routing and middleware, and the operator handles publication of the hostname through the tunnel. It also supports direct-origin publication for the cases where going through ingress is not the right fit.
It is worth being clear about the boundary: this does not create or run the tunnel itself. The tunnel connection still needs to exist separately. What the operator manages is the public hostname routing side, which is the part that becomes tedious once the number of applications starts to grow.
I have also added some extra control around reconciliation and policy handling, including safer ownership behaviour for shared tunnel configuration and optional controls such as per-hostname rate limiting. The aim was not just to automate route creation, but to do it in a way that fits a more controlled platform model.
I have been running and testing it over the last month or so, and it is now at the point where it is useful enough to share.
The repository is here:
That includes the project README, examples, and Helm chart for anyone who wants to see how it works or try it in a cluster of their own.
I did use AI during development, but this was not a case of handing over the problem and hoping for the best. The project was designed up front, worked through against a reference architecture, reviewed as it evolved, and supported by manual development as well.
I also have a few applications that may eventually move behind Pangolin, so if I do not find a clean management model there either, I may end up building something similar for that in addition.