acme.sh is a pure shell-script ACME client, an alternative to Certbot with no external dependencies beyond a standard Unix shell — a common choice on minimal or resource-constrained servers.
Basic issuance
acme.sh --issue -d yourdomain.com -d www.yourdomain.com \
--webroot /var/www/htmlInstalling the certificate to your web server's expected location
acme.sh --install-cert -d yourdomain.com \
--cert-file /etc/nginx/ssl/cert.pem \
--key-file /etc/nginx/ssl/key.pem \
--fullchain-file /etc/nginx/ssl/fullchain.pem \
--reloadcmd "systemctl reload nginx"acme.sh installs a cron job automatically during setup to handle renewal, running the same install command (including the reload command) whenever a certificate is actually renewed — so your web server picks up the new certificate without manual intervention.
What to do if acme.sh's renewal cron job isn't running as expected
Checking whether acme.sh's cron entry was actually installed correctly (`crontab -l` should show an acme.sh reference) and reviewing acme.sh's own log output for recent renewal attempts are the first troubleshooting steps if automated renewal doesn't seem to be functioning.
How acme.sh's approach differs from Certbot for those choosing between the two
acme.sh is a pure shell script with no Python dependency, making it attractive for minimal or resource-constrained environments, while Certbot offers more extensive plugin support and broader documentation — both are fully capable, actively maintained ACME clients, and the choice often comes down to environment constraints or personal preference rather than a meaningful capability gap.
What installation options acme.sh offers beyond the default cron-based approach
Beyond standard cron, acme.sh can also be configured to run via systemd timers on systems that prefer that scheduling mechanism, or integrated into container-based deployments through its Docker image — flexible enough to fit various infrastructure preferences beyond the default installation method.
How to configure acme.sh to use a specific CA other than Let's Encrypt
acme.sh supports configuring an alternative default CA through its --set-default-ca flag, letting you use a different ACME-compatible certificate authority if you have a specific reason to prefer one over Let's Encrypt's default — the same underlying ACME protocol works consistently across supporting CAs.
Why acme.sh's lightweight, dependency-free design suits certain constrained environments
Being a pure shell script without a Python or other language runtime dependency makes acme.sh well suited to minimal container images, embedded systems, or any environment where installing a full language runtime just for certificate management would be disproportionate overhead.
What to do if acme.sh's install script fails on an unusual or minimal Linux distribution
acme.sh's install script depends on a small number of common Unix utilities (curl or wget, and standard shell tools) — on a genuinely minimal distribution missing one of these, installing the specific missing dependency first, identified from the install script's error output, resolves most installation failures.
How to back up acme.sh's configuration and issued certificates
Backing up acme.sh's home directory (typically ~/.acme.sh) preserves your account configuration, issued certificates, and renewal settings — restoring this directory on a new or rebuilt server lets acme.sh resume managing the same certificates without needing to reissue from scratch.
A closing note on choosing acme.sh versus Certbot for your specific situation
Both acme.sh and Certbot are fully capable, actively maintained tools — acme.sh's lighter weight makes it attractive for minimal or constrained environments, while Certbot's broader plugin ecosystem and documentation may suit a more standard, feature-rich server setup better.
A final practical tip before trusting automation fully
Testing acme.sh's renewal process with its built-in staging or test mode before relying on it against your actual production certificates builds confidence the automation works correctly in your specific environment before it's trusted unattended.