Boulder

Boulder is the Go-based ACME certificate authority that powers Let’s Encrypt, delivered as software for your own infrastructure. It suits developers exploring ACME and organizations aligned with Let’s Encrypt’s Web PKI mission; teams seeking a general-purpose production CA should look elsewhere. Its architecture is capable, but deployment security and operational responsibility are substantial.

Overview

ACME gives a certificate authority a standard way to verify control of an identifier, then lets a subscriber issue or revoke certificates for identifiers it controls. Boulder implements that workflow as a self-hosted authority rather than a hosted certificate service, so your organization must run, secure, and maintain it.

The system divides responsibilities among web front ends, registration and validation authorities, a certificate authority, storage authority, publisher, and CRL updater. Components communicate through gRPC and persist ACME accounts, authorizations, challenges, orders, and certificates. Separating CA functions by security context is a meaningful defensive design: the certificate authority receives instructions from the registration authority. The trade-off is a larger system with more components to deploy and protect.

Key features

ACME certificate workflow

Boulder supports ACME issuance and revocation, and its documented local setup works with Certbot or another ACME client. That makes it useful for developers validating client behavior or building integrations around an ACME authority.

Modular authority services

Its front ends, registration and validation services, CA, storage, publishing, and CRL updating are distinct pieces rather than one undifferentiated process. Teams that need to reason about trust boundaries gain a clear component model, while operators inherit the complexity of coordinating and securing those services.

Production security model

The deployment guidance calls for mutual TLS certificates issued by a special-purpose CA, firewalling between components, and limiting exposed ports. Those controls are appropriate for a serious deployment, but they are implementation work for the operator rather than turnkey protection.

Development environment

Docker and Docker Compose are the maintainers’ recommended route for development and experimentation. The environment uses publicly available private key material, exposes debug ports, and is described as brittle when components fail; the README explicitly says it is unsuitable for production. Treat it as a learning and integration environment, not a production blueprint.

Pricing

There are no paid tiers, seat allowances, certificate quotas, or trial terms to evaluate. The zero price removes licensing fees, not the engineering and operational cost of running a multi-service certificate authority.

Platforms

Boulder is available through an API on Linux as self-hosted, on-premises software. Its documented Docker-based development workflow is aimed at local experimentation, while production operation requires an independently designed deployment.

Who it's for

Choose Boulder when you need to study or extend the ACME workflow, want to run the software behind Let’s Encrypt, or have a team prepared to implement its security and operations model. It is a poor default for an organization wanting a supported, general-purpose production PKI: the project is built for Let’s Encrypt and Web PKI baseline requirements, and maintainers warn that other deployments may not receive timely support.

Pros and cons

Pros

• Full ACME authority workflow: supports verification, issuance, and revocation through standard ACME clients.
• Strong separation of duties: distinct services and security contexts limit the CA’s responsibilities.
• Open source and self-hosted: MPL-2.0 licensing permits use without a software charge and keeps deployment under your control.

Cons

• Not a production-ready development stack: public private keys, debug ports, and brittle failure behavior make the Docker setup inappropriate for live service.
• Significant operational burden: gRPC-connected components, storage, mutual TLS, firewalling, and port restrictions require substantial implementation work.
• Narrow project focus: Let’s Encrypt mission priorities mean support may not be timely for unrelated organizations.

Alternatives

Let’s Encrypt is the better choice when you need publicly trusted free certificates rather than the software that operates an authority.

OpenCA PKI fits teams seeking open-source PKI management across Linux, macOS, and web environments.

step-ca is preferable for a smaller authority design with a configured intermediate, offline root, and authority-wide issuance policies.

EJBCA Community Edition suits learning, testing, and prototyping with basic PKI functionality, but its community edition is not intended for production.

OpenXPKI offers a fully functional community code base with Debian packages, example configuration, documentation, and mailing-list support.

XiPKI is another free open-source PKI option under Apache License 2.0.

cert-manager is the focused alternative for managing X.509 certificates in Kubernetes and OpenShift workloads.

Dogtag Certificate System provides open-source certificate authority software and requires access to 389 Directory Server.

Browse more options in Public Key Infrastructure Software.

Verdict

Boulder is a strong choice for ACME development, experimentation, and organizations operating within Let’s Encrypt’s mission that can fund careful deployment engineering. Its modular security architecture is the main reason to choose it. Look elsewhere if you need a broadly supported production CA, because the development environment is explicitly unsafe for production and maintainers caution that other organizations may not receive timely support.