Otherwise you need some infrastructure: logging, monitoring, some way to manage upgrades, backups, testing recovery, oh and those private keys are better not be leaked anywhere, so you need encryption for backups, which brings key management and so on.

[1] https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx

I actually evaluated a bunch of acme clients, wasn't satisfied with the code of any of them and wrote my own. But even from those I looked at certbot was always the worst choice, it's ridiculous letsencrypt is promoting it, better choices were POSIX shell clients or statically linked clients, like those written in Go and other compiled languages.

https://certbot.eff.org/

I wouldn't be surprised if that's how he's managing 100 servers, or something similar.

I suppose I could have made that known in my post.

Actually, it is. Some reverse proxies such as Traefik handle TLS certs automatically. You practically need to explicitly not want to do it.

A practical example I ran into lately, we had a small system run on GKE and Google Cloud Loadbalancer and struggled to automate the certificate renewal process. Because the cluster/project was for an internal tool this automation was given a low priority and we still have to "manually" swap a certificate every few months (and if we forget to we get an angry slack DM).

TLDR; there are still many combinations of networked services that still do not ~easily~ support certificate automation, even ones you expect really should by now.

https://docs.certera.io

https://letsencrypt.org/docs/client-options/

Based on this:

https://medium.com/@pentacent/nginx-and-lets-encrypt-with-do...

Now, in our setup, everything is running on a different port, so it is easy to set up additional services all coming from the same hostname with the same IP address.

If you think something is set-it-and-forget-it, you haven't been around long enough.

Only if you're blindly running shell commands the effects of which you don't understand.