acme.sh is not a great ACME client for automating renewal of TLS certificates. It sure is relatively easy to set up, provided you are fine with reading through the GitHub wiki containing all its “documentation.” It is particularly bad for automating adding new domains and stuff.

The configuration for a domain is stored in a file .acme.sh/$domain/$domain.conf. But neither is the format documented (or particularly well though-out), nor are there commands to properly work with it. You cannot simply update a single field.

acme.sh knows too much about the API URIs. It knows aliases for Let’s Encrypt et al. Further, it has an option --test/--staging (because why not introduce unnecessary aliases?) that changes the configuration to use rate limit-free API URIs for testing. As a fix for the unintuitive (and fairly useless) permanent configuration change, acme.sh disobeys the configuration when it notices a staging URI and autoblackmagically uses a production URI instead.

The “validation methods”:

webroot
just copies the HTTP-01 file to a directory, expecting a running Web server to serve it
standalone
uses a built-in Web server; can be told to listen on a port different from 80 if you have a reverse proxy using port 80
alpn
same as standalone, but for port 443 and TLS-ALPN-01
dns
DNS-01 using a bunch of scripts implementing a bunch of registrars’ APIs
dns manual
DNS-01, expecting the user to put the response into the DNS
dns alias
the same as the usual dns mode, telling acme.sh to put the response somewhere else (presumably the canonical name for the original _acme-challenge domain)
Apache
NGINX
These sound like truly terrible ideas.