I use caddy rather traefik. It's much easier to manage the Caddyfile compared to the traefik YAML config IMO, and we just keep three separate Caddyfiles for local, production and on-prem deployments. There are a plethora of great plugins, we use the coraza WAF plugin for caddy and it works well.
Having had used traefik, caddy and now caddy proxy, I like the latter because labels are simple pointers to actual caddy features (reasonably documented).
I used to have all my docker compose files in elaborate structures but moved to portainer for simplicity. Together with caddy proxy it rocks (well, there are several things missing but I have hope)
Same here. I enjoyed Traefik for being able to use docker tags for my reverse proxy configuration. The mechanism is great, however I did not like Traefiks internal config structure. Caddy is much easier for me to understand and matches my (small scale) use cases much better. Using Caddy via Docker labels through caddy-docker-proxy is about as perfect as it gets (for me).
I love Caddy, I wish the docs were better on production deployments, too many unanswered questions about best practices especially RE: storage and config management. Like how local storage is supposed to be handled when you're using external storage? Allegedly it can be treated as stateless but maybe not?
You basically just have to pray the guy who made the module you need knows what he is doing, because there's no standards for documentation there either. Maintainers really need to put their foot down on random ass modules with 0 documentation providing critical functionality (i.e. S3 storage backend).
Yes. If you don't need all of the service discovery and auto-scaling shenanigans (or are willing to script it yourself), you can gleefully skip Traefik, Docker Swarm, Kubernetes etc. and just use Caddy! It can really do most things and it does them well.
