The only “dry run” is to actually run it, generally speaking any kind of test that isn’t the real thing won’t actually fully emulate the real thing and won’t turn up all the problems that might occur.
You could try set up something to run validations off the ACME staging server instead to check first, but Caddy will retry against the staging server anyway if it encounters any errors on production.
To be clear - this is 50 domains per week per registered domain.
That means you could requisition separate certificates for sub1.example.com through sub50.example.com in one week, but going for sub51.example.com will get rate limited until next week. (This is one pretty good use case for a wildcard!)
If you’re requesting certificates for different registered domains, the rate limit you’ll probably want to note is this one:
For users of the ACME v2 API you can create a maximum of 300 New Orders per account per 3 hours.
—Rate Limits - Let's Encrypt
But Caddy v2 should keep on top of this for you without any major issues. Basically if every customer has a single unique registered domain, you could onboard ≤100 customers per hour indefinitely. Just throw the lot at Caddy, it’ll handle it all.
That’s exactly correct. First handshake is slow, the rest are as normal since Caddy will have the certificate on hand after that.
Adding and removing programmatically has the benefit of a certain level of permanence and Caddy knows to continue maintaining the cert for the domain you’ve chosen. On-Demand TLS certificates will drop out if Caddy stops getting requests for them, I believe. Francis would probably set up On-Demand TLS, based on his posts; Matt appears to recommend the programmatic approach.
I myself like the simplicity and lack of requirement for extra software external to Caddy, that would actually perform this programmatic updating, so On-Demand TLS is appealing to me in that regard. But the programmatic approach also has its merits. I’d definitely strongly weigh the latter if I was already writing any kind of API interaction for my back end systems.
I don’t believe so. Running as some kind of service will direct stdout to a logger, e.g. journalctl for systemd.
If you’re opposed to a process supervisor, yeah this’ll probably do the job - although the aforementioned stdout output won’t roll. I’ll invite anyone else on the forums with ideas to chip in here, though.
Very curious! If you can get a repro, we’d love to investigate that one.