Lego

Lego is an ACME (RFC 8555) client written in Go that automates obtaining, renewing, and revoking TLS certificates from Let’s Encrypt and any other ACME-compatible certificate authority. It ships two ways to use it: a standalone CLI binary for shell-driven automation and cron-style renewal, and a fully importable Go library (lego, certificate, challenge, registration) for embedding certificate lifecycle management directly inside another application.

Its defining feature is a plugin architecture of over 200 DNS providers, each implementing a common challenge.Provider interface and configured through consistent environment variables, so DNS-01 challenges work out of the box against nearly every major DNS host and cloud provider. Lego also supports HTTP-01 and TLS-ALPN-01 challenges, wildcard and SAN certificates, IP-address certificates (RFC 8738), and ACME Renewal Information (ARI). It is widely embedded by other infrastructure tools (Traefik, Caddy-adjacent projects, and countless internal deployment pipelines) as the ACME engine underneath their own certificate automation.

What You Get

• A CLI (lego) for scripted or cron-driven certificate registration, renewal, and revocation
• A Go library (lego, certificate, challenge, registration packages) for embedding ACME certificate management directly in your own service
• Over 200 built-in DNS provider integrations for the DNS-01 challenge, each configured via consistent environment variables
• HTTP-01 and TLS-ALPN-01 challenge solvers alongside DNS-01, plus support for custom challenge solvers
• Support for wildcard certificates, SAN certificates, IP-address certificates (RFC 8738), and CSR-based issuance
• ACME Renewal Information (ARI, RFC 9773) support for renewal scheduling, and certificate bundling/OCSP helpers

Common Use Cases

• Automating Let’s Encrypt certificate issuance and renewal for servers, load balancers, or internal services without a managed TLS provider
• Embedding ACME certificate management directly inside an ingress controller, reverse proxy, or PaaS control plane
• Running scheduled (cron/systemd-timer) renewal jobs for infrastructure that can’t rely on a hosted certificate manager
• Issuing certificates for domains hosted on any of 200+ supported DNS providers via the DNS-01 challenge, including in split-horizon or CDN-fronted setups
• Building custom ACME clients or tools for private/internal CAs that speak the ACME protocol

Under The Hood

Architecture Lego is organized in clean layers around a central acme/api.Core HTTP client: lego.Client (in lego/client.go) wires together certificate.Certifier, challenge/resolver.SolverManager, and registration.Registrar, each of which talks to the ACME server through the shared acme/api package (account, order, authorization, challenge, and certificate-renewal sub-clients). Challenge solving is decoupled through the challenge.Provider interface, resolved at runtime by challenge/resolver.SolverManager and Prober, so DNS-01, HTTP-01, and TLS-ALPN-01 are pluggable rather than hardcoded. The providers/dns/ tree contains 200+ self-contained provider packages, each implementing challenge.Provider against a distinct cloud/DNS API, which is the architectural core that gives lego its breadth. The CLI (cmd/, main.go, using urfave/cli/v3) is a thin layer on top of this same library API, not a separate implementation, so a change to the core client abstraction propagates automatically to both CLI and library consumers.

Tech Stack Lego targets modern Go (go 1.26 in go.mod) and depends on the urfave/cli/v3 framework for its CLI surface plus dozens of official and community cloud SDKs (AWS SDK v2, Azure SDK, Alibaba Cloud, GCP metadata, and many vendor-specific DNS API clients) pulled in only as needed by each providers/dns/* package. There is no database or ORM — state is either the ACME server’s own account/order objects or local files (accounts, certificates) written by the CLI. Builds and releases go through goreleaser (.goreleaser.yml) and a multi-stage Dockerfile/buildx.Dockerfile for the published goacme/lego Docker image; documentation is a separate Hugo site under docs/ deployed via its own GitHub Actions workflow.

Code Quality The repository ships over 500 _test.go files, with nearly every one of the 200+ DNS providers carrying its own dedicated test suite alongside the core acme, certificate, challenge, and registration packages. .golangci.yml configures an extensive linter set enforced in CI (tests-lint.yml), and build.yml/release.yml run the full test and release pipeline on every change. Errors are handled idiomatically as Go error values throughout rather than panics, package boundaries are narrow and single-purpose, and naming is consistent across the DNS provider packages (each exposing the same NewDNSProvider/NewDNSProviderConfig pattern and Env* constants), which keeps a very large codebase navigable.

What Makes It Unique Lego’s distinguishing choice is treating DNS providers as a first-class, uniformly-interfaced plugin system rather than a handful of hardcoded integrations — the sheer breadth (200+ providers, each independently maintained and tested) is unusual among ACME clients in any language. Combined with exposing the exact same client used by its own CLI as a public, importable library, lego functions equally well as an end-user tool and as the ACME engine embedded inside other infrastructure software, which is why it underpins certificate automation in several other well-known open-source projects rather than being used only standalone.