Open-Source Testing · letsencrypt

pebble

Pebble is a lightweight ACME test server built by Let's Encrypt to help developers test ACME client implementations. It mimics the Let's Encrypt protocol without the production complexity, making it ideal for integration testing and protocol experimentation.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/letsencrypt/pebble

782

GitHub stars

175

Forks

Primary language

MPL-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	letsencrypt/pebble
Owner	letsencrypt
Primary language	Go
License	MPL-2.0 — OSI-approved
Stars	782
Forks	175
Open issues	40
Latest release	v2.10.1 (2026-04-20)
Last updated	2026-07-03
Source	https://github.com/letsencrypt/pebble

What pebble is

Go-based RFC 8555 ACME server that intentionally drops state between invocations and randomizes keys/certificates to prevent production misuse. Supports HTTP-01, TLS-ALPN-01, and DNS-01 challenge validation with configurable validation ports (default 5002 for HTTP, 5001 for TLS-ALPN).

Quickstart

Get the pebble source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/letsencrypt/pebble.git2cd pebble3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

ACME Client Integration Testing

Developers building ACME clients can spin up a local Pebble instance to test certificate request workflows, challenge handling, and renewal logic without needing access to Let's Encrypt staging.

Protocol Feature Testing & Development

ACME protocol developers can use Pebble as a testbed for new or breaking protocol changes before committing them to Boulder, the production Let's Encrypt CA.

Local Development & CI/CD Pipelines

Teams can include Pebble in Docker Compose setups or CI workflows to automatically validate certificate issuance logic in applications without external dependencies or rate limits.

Implementation considerations

Requires Go toolchain (go install) or Docker; no pre-built binaries beyond container images distributed via GitHub Container Registry.
Configure validation ports (5002 HTTP-01, 5001 TLS-ALPN-01) to avoid privilege escalation or port conflicts; ports are user-configurable via JSON config.
Use PEBBLE_VA_NOSLEEP environment variable for full-speed testing or PEBBLE_VA_SLEEPTIME to control artificial validation delays (default 0-15 seconds).
DNS resolution defaults to system resolver; configure -dnsserver flag or use pebble-challtestsrv sidecar for reliable DNS-01 validation in isolated environments.
Enable -strict false flag if stability across releases is critical for CI; default may change to -strict true in future versions, introducing breaking changes.

When to avoid it — and what to weigh

Production Certificate Authority Needs — Pebble explicitly drops all state between invocations, randomizes keys, and is designed with guardrails against production use. Do not deploy to production under any circumstances.
Rate-Limit Testing — Pebble does not enforce rate limits, making it unsuitable for validating client behavior under quota constraints. Boulder or Let's Encrypt staging is required for that testing.
Pre-Authorization or Cross-Account Revocation — Pebble lacks support for ACME pre-authorization and does not support revoking certificates issued by different accounts, limiting protocol coverage versus Boulder.
Strict Domain Validation Requirements — Pebble performs less input validation than Boulder/Let's Encrypt; domain names rejected by production may be accepted, creating false-positive test results.

License & commercial use

Mozilla Public License 2.0 (MPL-2.0), a weak copyleft OSI-approved license. Permits commercial use, modification, and distribution provided source changes are disclosed under the same license; no patent grant.

MPL-2.0 allows commercial use in testing/development contexts (e.g., as part of a CI pipeline or internal QA tool). However, if you modify Pebble and distribute the modified version, those changes must be open-sourced under MPL-2.0. Consult legal review for embedded or redistributed scenarios. Use as-is in internal tools is unencumbered.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Strong
Assessment confidence	High

Security considerations

Pebble is intentionally insecure for testing: randomizes keys, drops state, and includes guardrails against production use. TLS certificates are generated randomly; accept them in test tools via INSECURE_SKIP_VERIFY or custom CA bundles. Validate ports (5002, 5001, 14000, 15000) are not exposed to untrusted networks in shared environments. Stateless design eliminates persistent credential compromise risk but also means no audit trail.

Alternatives to consider

Boulder (Let's Encrypt)

Production ACME server with full protocol support, rate limiting, and persistent storage. Operationally complex; requires MariaDB, gRPC, and orchestration. Use for production or comprehensive protocol testing.

Let's Encrypt Staging (acme-staging-v02.api.letsencrypt.org)

Free, public staging environment with production-like behavior, rate limits, and real certificate validation. Requires external network; not suitable for offline or air-gapped CI/CD. Recommended for final pre-production client validation.

ACME.sh / Certbot with --test-mode

Lightweight ACME clients with built-in test modes pointing to Let's Encrypt staging. Simpler for end-to-end testing of certificate provisioning but does not provide a local test server for other clients to validate against.

Software development agency

Build on pebble with DEV.co software developers

Start with Pebble today using Docker Compose or Go. Ideal for CI/CD integration and protocol development. Check the GitHub repo for examples and documentation.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

terratest fscan goss

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing API Development DevOps & Infrastructure Cloud Deployment Talk to DEV.co

pebble FAQ

Can I use Pebble in production?

No. Pebble explicitly drops all state between invocations, randomizes certificates, and includes guardrails to prevent production use. It is designed for testing only. Use Boulder or Let's Encrypt for production.

Why does Pebble randomize keys and certificates?

To force clients to implement ACME correctly and avoid hardcoding assumptions about URLs, key formats, or certificate attributes. This encourages specification-compliant clients.

How do I test DNS-01 challenges with Pebble?

Use the -dnsserver flag to point to a DNS server (e.g., pebble-challtestsrv included in the repo) that serves your test domains. System DNS resolver is used by default but may cache, causing false failures.

What ACME features does Pebble not support?

Pre-authorization, revoking certificates issued by a different account, strict domain validation, and rate limiting. These gaps are documented; patches welcome.

Work with a software development agency

Need help beyond evaluating pebble? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source testing integrations — and maintain them long-term.

Ready to Test ACME Implementations?

Start with Pebble today using Docker Compose or Go. Ideal for CI/CD integration and protocol development. Check the GitHub repo for examples and documentation.

Talk to DEV.co Schedule a Consultation