// the find
adyanth/cloudflare-operator
A Kubernetes Operator to create and manage Cloudflare Tunnels and DNS records for (HTTP/TCP/UDP*) Service Resources
A Kubernetes operator that manages Cloudflare Tunnels and their DNS records as CRDs instead of hand-rolled cloudflared manifests. It's for people running internal apps or home-lab clusters who want new Services to get a tunnel route and a DNS record automatically instead of editing a cloudflared config.yaml and restarting a pod by hand every time.
It actually did the CRD versioning work most hobby operators skip: there's a v1alpha1->v1alpha2 conversion webhook with its own tests, which means they hit a real schema change and handled it properly instead of just breaking existing users. TunnelBinding uses finalizers to reverse the DNS record and config entry on delete, so you don't end up with orphaned CNAMEs pointing at a tunnel that no longer serves that hostname. Test setup goes beyond unit tests - there's a controller-runtime envtest suite plus a separate e2e test directory, and CI runs lint/test/release as separate workflows.
Every TunnelBinding change restarts the whole cloudflared Deployment to pick up the new config, so adding one more app to a shared tunnel bounces every other app using it - fine for a home lab, not something you want on a tunnel serving multiple production services. It's explicitly alpha and says so in the README, so expect CRD or behavior changes between versions with the migration docs being the only safety net. UDP support rides on a Cloudflare feature that's itself in early access, so that part can change or break outside this project's control. It's a single-maintainer project built from someone's home-lab setup, not Cloudflare-backed, and it needs a Cloudflare API token with tunnel/DNS edit scope sitting in a cluster Secret - worth thinking about blast radius if that secret leaks.