NGINX Proxy Manager
I wasn&#x27;t trying to imply that Caddy is bad, so I hope it didn&#x27;t come off like that.  I was trying to highlight how things that seem simple might only be simple to people that already have a comprehensive understanding of the topic.  I&#x27;ll give you some follow up examples:<p>&gt; What asterisks are almost _always_ for: wildcards!<p>However the link you gave doesn&#x27;t include a single mention or example of using wildcards, so I can&#x27;t even educate myself.  Was that the link you intended to share?<p>The problem for me in understanding that particular config is that I don&#x27;t know enough about HTTP to know if you can set headers with asterisks in them.  I can&#x27;t look at that config snippet and figure out immediately if it&#x27;s matching incoming requests and sending the matched requests to the backend or if it&#x27;s adding the headers to incoming requests (that are matched some other way) before sending them to the backend.<p>The root of the confusion for me is that other reverse proxies match on a location for that type of stuff (ex: &#x2F;wss&#x2F;) and I simply don&#x27;t know enough about websockets to make an educated guess about how Caddy is deciding where the traffic gets routed.  That&#x27;s not the kind of thing I&#x27;d show up on your forum asking about either.  I can figure it out if I need to, but that likely involves spinning up a Caddy server and watching the traffic to see what&#x27;s going on.<p>Something as simple as `set-header` or `match-header` instead of `header` would make it easier for me to read and learn the config because it adds enough context that I can immediately figure out what the config is doing.  If it&#x27;s setting headers, that instantly tells me that my lack of knowledge is related to how the matching is happening and I can ignore all the other stuff like the asterisks and the capitalization, at least temporarily.  In my specific case, I wanted to translate that config to nginx, so figuring out how the matching works is all I really need.<p>At the risk of sounding stupid, I&#x27;ll say I <i>still</i> don&#x27;t understand if it&#x27;s routing traffic based on matched headers or adding headers to already matched traffic.  This [1] answer seems like a similar config for nginx, but it&#x27;s routing traffic based on matching those headers.<p>You have to remember that you can look at a config and instantly map it to the http spec.  You probably know the context instantly because one of the possibilities is too stupid to consider.  The thing is there&#x27;s <i>always</i> going to be someone trying to learn that knows nothing and the contextual hints I&#x27;m talking about make a huge difference for someone that doesn&#x27;t know everything.<p>&gt; What do you mean &quot;set up on your own&quot;? Our download page does it for you.<p>The download page only gives me a binary, right?  I need to deal with setting up a system service.  It&#x27;s not <i>hard</i>, but it&#x27;s extra steps because I need to redo it every time there&#x27;s an update or I need to automate it somehow.  For my specific use case, running a Docker container (locked to a stable tag) that auto updates is ideal.<p>&gt; Or Docker images can be automated to include it as well.<p>That kind of illustrates the point I was trying to make.  Setting up an automated Docker build to bake in the functionality I want is significantly different than getting it out of the box.  Imagine telling a young person trying to learn &quot;start by setting up an automated Docker build that bakes Caddy + the DNS plugin into the container.&quot;  Is it reasonable to expect the <i>users</i> of Docker images to be on the same level as the <i>developers</i> of them?<p>&gt; Takes about 2-5 minutes to set up, including getting credentials from your DNS provider.<p>Unless you&#x27;re an experienced sysadmin or a Docker expert, getting to the point where you can start to configure DNS challenges is a huge amount of learning and work.  It would take me half a day to set up a good quality, CI built Docker image with the Cloudflare DNS plugin baked in and I&#x27;ve spent hundreds (if not thousands) of hours working with Linux, Docker, CI, etc..  It might take 5 minutes to *configure* if you already know what you&#x27;re doing.<p>&gt; no other servers come with Cloudflare-specific support baked in with automatic ACME challenge solvers<p>Traefik has Cloudflare DNS support baked in to the official Docker image.  It&#x27;s not nearly as easy as Caddy, but it has it.<p>I qualified my opinion up front saying &quot;for a home lab scale setup&quot;.  I agree 100% that Caddy is a better product on a technical level, but for a certain scale of setup NGINX Proxy Manager provides a better user experience for me because it&#x27;s a single container with everything I need baked in, someone else maintains it, and the GUI makes simple reverse proxy configs easier than anything I&#x27;ve ever used (including Caddy).<p>I wasn&#x27;t trying to say Caddy is bad and I&#x27;m sorry if it came off like that.  The only constructive feedback I can give is that if there was an official Docker image with the Cloudflare DNS plugin baked in it&#x27;s likely I would have put in the time to learn Caddy.  I think you underestimate the amount of effort it takes for someone that isn&#x27;t an expert in the space to get up to speed.  For myself I would set aside a full day to familiarize myself with running Caddy, but once I add in the need to build (and maintain) my own Docker image it gets to the point where, pragmatically, I ended up choosing a &quot;good enough&quot; solution over what I&#x27;d consider &quot;the best&quot; solution (I tried Caddy first).<p>1. <a href="https:&#x2F;&#x2F;serverfault.com&#x2F;a&#x2F;923254&#x2F;133882" rel="nofollow">https:&#x2F;&#x2F;serverfault.com&#x2F;a&#x2F;923254&#x2F;133882</a>