// the find
go-acme/lego
Let's Encrypt/ACME client and library written in Go
lego is a Go ACME client for Let's Encrypt and other CAs, usable as both a CLI tool and a library. It's the engine behind a lot of other TLS automation tooling (Traefik and Caddy both use lego internally for their ACME support), and it's aimed at anyone who needs certificate issuance/renewal scripted rather than handled by certbot.
Tracks ACME spec evolution closely — RFC 8555, 8737 (TLS-ALPN), 8738 (IP certs), and even draft-stage extensions like RFC 9773 (ARI) and the profiles draft, so it doesn't lag behind Let's Encrypt's own rollout. Over 200 DNS provider integrations for dns-01, each with generated docs (zz_gen_*.md) kept in sync with the code rather than hand-maintained. Clean separation between library packages (acme/, challenge/, certificate/) and the CLI (cmd/), so you can embed just the ACME client without dragging in the CLI's storage/config assumptions. Test coverage is genuinely there, not token — most packages have real _test.go files including mocked DNS challenge tests, not just the popular providers.
The README leads with a donation plea, which is a signal worth taking seriously: this is effectively load-bearing infrastructure for a chunk of the Go TLS ecosystem, maintained on a volunteer/sponsorship model with an unclear bus factor. With 200+ community-contributed DNS providers, the depth of testing and maintenance responsiveness almost certainly varies a lot provider to provider — check the specific one you need before assuming parity with Cloudflare or Route53. The CLI's storage layer writes accounts/certs as JSON/PEM files on local disk (cmd/internal/storage) with no built-in locking or HA story, so running it across multiple instances needs your own coordination layer. Scheduling renewals is left entirely to the user — no daemon mode, systemd timer, or built-in cron; you're expected to wire that up yourself via hooks.