Lego v5.4.1 supports more than 200 DNS providers
Lego v5.4.1 is both a command-line ACME client and a Go library. It registers accounts, obtains certificates from a new request or existing CSR, renews them, revokes them, and bundles issuer certificates. ACME v2 support includes HTTP-01, DNS-01, and TLS-ALPN-01 challenges, plus newer work such as IP address certificates and renewal information. The headline advantage is provider reach: the README lists more than 200 DNS services behind one challenge interface.
That reach makes Lego useful when one platform controls domains across several registrars or cloud accounts. A custom solver can cover a private DNS system, and the Go library lets an application own account registration and certificate storage. The tradeoff appears before any certificate request: our 6.6 MB checkout referenced enough provider SDKs that source setup was still downloading after 682 seconds. Users of a release binary avoid that compilation path, while library users should inspect what their module and final binary retain.
HTTP uses port 80, TLS-ALPN uses 443, and DNS handles wildcards
The HTTP-01 path can start Lego's built-in listener on port 80 or write the token into an existing server's public webroot. TLS-ALPN-01 needs permission to bind on port 443. Those methods work when the target hostname reaches the machine running the challenge. DNS-01 is the practical route for wildcards and remote issuance, but it grants the client power to change DNS records. Use the narrowest provider credential available and test cleanup after validation.
Provider behavior is the part that needs release-specific checks. The repository contained 2,636 files and roughly 192,976 source lines at commit 5556944, much of that surface serving different DNS APIs. Open issue 2774 describes a Beget configuration where presenting a challenge erased root A and MX records. Issue 2563 reports an outdated iwantmyname endpoint returning 404. Neither report applies to every provider, but each is serious for the affected one. A staging CA does not protect unrelated DNS records, so inspect the zone too.
What happened when we ran it
Our sandbox began installing Lego from commit 5556944 and stopped after 682 seconds with exit code 1. Go attempted to download toolchain 1.26.0, then fetched modules through proxy.golang.org. The tail showed stream errors for the Akamai EdgeGrid, Infoblox, and Tencent Cloud dependencies, including HTTP/2 internal errors. Installation never completed, so the build and test stages were not reached. The log does not establish a defect in Lego's Go source.
The failed run still exposes a practical source-build dependency. A small 6.6 MB repository does not mean a small or offline-friendly module fetch when more than 200 DNS providers pull their client libraries into one project. The main module currently declares Go 1.26.0, which triggered a toolchain download in our Go 1.24 container. Lego's installation page says Go 1.25+ and also offers release archives, Docker, Snap, AUR, and community-maintained packages. For production, pin one of those artifacts and keep a verified copy.
Four files per certificate make storage part of the deployment
The CLI writes certificate state below .lego in the current working directory by default. For each domain, the documentation describes 4 files: a bundled certificate, private key, issuer certificate, and JSON metadata. Account state lives nearby. A configuration file can name servers, accounts, challenges, and certificates, and removed entries are archived. That is manageable on one host, but containers and schedulers need persistent storage with deliberate ownership, permissions, backup, and restore behavior.
Our scan found 6 CI workflow files, a Dockerfile, and no separate tests directory in the 2,636-file checkout. The missing directory is not proof that a Go project lacks tests because Go commonly places test files beside package code. More important for an operator is lifecycle wiring. Lego can issue and renew, but a cron job, systemd timer, container scheduler, or parent application still decides when to run it. The service using the certificate also needs a safe reload after files change.
The library gives control and requires account-key discipline
Embedding Lego v5 means implementing an ACME user with an email, registration record, and private signing key. The library example creates that key, registers with the CA, chooses challenge providers, requests a certificate, and tells the caller to save the returned certificate and key bytes. That flexibility suits an existing control plane. It also places account recovery, private-key protection, concurrent renewal, error handling, and storage transactions in application code rather than a ready-made service.
Delayed issuance deserves a compatibility test with private or unusual CAs. Open issue 1601 says Lego ignores a server's Retry-After value while polling a processing order, and issue 2517 asks the CLI to persist renewal information and respect its retry timing. The repository's 192,976 source lines include support for several ACME extensions, yet these open requests show that protocol coverage and operating policy are separate questions. A CA with slow signing or strict polling expectations should be tested end to end before rollout.
Release v5.4.1 is current, while old provider requests remain open
GitHub recorded 9,845 stars, 102 combined issues and pull requests, and a September 1, 2026 push. Release v5.4.1 arrived on August 31, only 10 days after v5.4.0. That is current maintenance by both push and release activity. The open queue also contains provider requests dating back several years, which is understandable for a catalog that depends on outside APIs and volunteer access. The combined count should not be read as 102 bugs.
Lego is an easy recommendation when a supported provider works in staging and a pinned v5.4.1 binary fits an existing renewal job. Our 682-second install failure makes the full source path harder to endorse in an ephemeral or restricted builder without a module mirror. Keep DNS credentials narrow, persist the .lego directory, back it up, and verify both certificate reload and challenge cleanup. If those tasks sound like unwanted platform work, Caddy or another certificate-managing service is the better product choice.