Certbot alternatives
Certbot is the best-known ACME client, but not always the best fit. Here are the main alternatives, what each is good at, and what to do when you have too many servers for per-server clients.
Certbot, from the Electronic Frontier Foundation, is the best-known ACME client and still a solid choice for one Linux server. People look for alternatives when they need wildcards with a DNS provider Certbot doesn’t cover well, a container- or Kubernetes-native setup, Windows support, or a way to manage many servers from one place.
The main alternatives
acme.sh
A pure shell-script ACME client with no dependencies beyond a shell and curl, and DNS API support for a very large number of providers. A favourite for routers, NAS devices and minimal systems. Note that since version 3.0 its default CA is ZeroSSL, not Let’s Encrypt; pass --server letsencrypt or set a default if you want Let’s Encrypt.
lego
A single Go binary with built-in DNS providers for most major hosts. Easy to drop onto any server or into CI. (EverTLS itself uses lego’s library for ACME and DNS.)
Caddy
A web server with automatic HTTPS built in: name a site in its config and Caddy gets and renews the certificate itself, with no separate client. Ideal for new deployments where you can choose the web server.
Traefik
A reverse proxy for Docker and Kubernetes that obtains certificates for the routes it serves. The natural choice when Traefik already fronts your containers.
cert-manager
The standard for Kubernetes: it issues certificates as Kubernetes resources and stores them as secrets for ingress controllers and services.
win-acme and Certify The Web
For Windows and IIS. win-acme is a free command-line client; Certify The Web is a graphical app with per-server licences. See our comparison.
Where per-server clients get hard
All of these run on the machine that needs the certificate, which is simple until you have many machines. Then the same questions keep coming up:
- Which certificates do we have, where, and when do they expire?
- Did last night’s renewal on that server actually work, and is the server serving the new certificate?
- Where are the DNS API keys, and how many servers have a copy?
- Who gets told when something fails, and what about the servers running Windows?
With certificate lifetimes falling to 100 days in 2027 and 47 in 2029 (see what changes), renewals happen far more often, and a silent failure on one forgotten server is an outage.
EverTLS: one place for every server
EverTLS is a central service with small agents for Linux and Windows. It doesn’t replace Caddy or cert-manager where those fit; it covers the servers they don’t, from one dashboard:
- Linux: nginx, Apache and HAProxy installs, plus PEM and PFX files, with a config test, reload, check that the new certificate is served, and rollback on failure.
- Windows: IIS bindings, the certificate store, PFX files and IIS Centralized Certificate Store.
- Validation: HTTP redirect, CNAME delegation with no DNS key, 190+ DNS provider APIs, or a key kept on your own server.
- CAs: Let’s Encrypt, Google Trust Services, ZeroSSL, SSL.com and Actalis, with automatic fallback to a backup CA.
- Visibility: every certificate and server in one list, endpoint monitoring, and alerts by email, Slack, Teams or webhook.
- Keys stay put: agents can generate the private key on the server, so it never leaves it.
Moving from Certbot
- Install the agent on a server. It discovers nginx and Apache sites and the certificates they use.
- For each site, choose Manage with EverTLS. EverTLS issues a new certificate and the agent switches the site to it.
- Once a site is managed by EverTLS, remove its Certbot renewal (
certbot delete --cert-name example.com) so the two don’t both renew it.
Free for two certificates; Pro covers 50 with unlimited agents.