Just wanted to ask and see if this sounds like a good way to use Caddy.
I’m trying to automate the serving of custom domain’s https to users.
The current implementation of Caddy goes as follows:
We have caddy running on the main app (and that works correctly)
Now, the idea is that users will be able to submit a custom domain and the app serves specific content to this domain, and so to do this we ask the user create A records in the user’s custom domain to point www and non www to the server’s ip and then once these changes have propagated then we add the domain to our Caddy.config file and restart caddy. (this is also kind of working)
The problem is that this all seems a little too brittle - like if the new Caddy.config fails for whatever reason then nothing starts working.
Our current solution to that ^ is to have jobs to retry and some cron tasks to run daily and check all the custom domains and the Caddy.config are playing nicely.
Thanks for your time, let me know if you have any suggestions!
Don’t stop the web server.
Don’t stop the web server.
Don’t stop the web server.
Don’t stop the web server.
(Lots of people do this and wonder why or complain when their sites go down… doesn’t change the fact that stopping the web server – no matter which server you’re using, whether it be Apache or nginx or Caddy – tends to bring sites down…)
Use SIGUSR1 to reload configuration instead.
Better yet, instead of updating your config like that, I would use on-demand TLS instead, it’s designed for this purpose: Automatic HTTPS — Caddy Documentation
Uniquely, Caddy is the only server to offer this feature.
As long as each site is similar/the same, you won’t need to change your config at all.