DockFlare one year later: still just Docker labels for Cloudflare Tunnels

If you use Cloudflare Tunnels with Docker, you probably know the routine. Deploy a container, open the Cloudflare dashboard, create the hostname and route, configure Access, then do it all again for the next service. DockFlare handles that part through Docker labels. Add the labels to your compose file, start the container, and DockFlare takes care of the Cloudflare Tunnel route, DNS, and Access policy. About a year ago, I posted DockFlare v1.8 here (latest version is now v3.1.6). Since then it has grown quite a bit, mostly thanks to feedback from this sub and GitHub: agents, so one DockFlare instance can manage containers across multiple Docker hosts reusable Access Groups and identity provider support an optional email suite using Cloudflare Email Routing, including webmail, aliases, and inbound/outbound workers quite a long list of security improvements and fixes The basic idea is still the same: three labels next to your service, no published ports, and no inbound router ports. Yes, Cloudflare itself isn't self-hosted, and that's a fair objection. I tried Traefik and Nginx Proxy Manager, but I never felt particularly comfortable opening ports on my router and keeping dynamic DNS in sync. My domains were already on Cloudflare, so Tunnel combined with their free tier became the approach that worked best for me. If you're already running Cloudflare Tunnel and haven't looked at DockFlare in a while, maybe give it another shot: dockflare.app github.com/ChrispyBacon-dev/DockFlare And if you tried DockFlare previously and it didn't stick, I'd genuinely like to know why. That feedback is probably more useful to me than hearing that everything works. I'm also curious how people here are handling Cloudflare Tunnels today. Docker labels, config files, another automation tool, or still doing it through the dashboard? Thanks, Chris

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论