Dehydrated: Letsencrypt/acme client implemented as a shell-script

Overall sentiment

  • Many commenters are very positive about dehydrated, describing it as simple, reliable, and “just works” over many years.
  • A recurring theme is a preference for minimalism and explicit control versus heavier, more automated tools.

Dehydrated vs Certbot

  • Several people prefer dehydrated (or acme.sh) over Certbot due to:
    • Smaller dependency footprint (mainly bash, curl, openssl, coreutils) vs. large Python stack and plugins.
    • Easier auditing: a single, readable shell script vs many Python modules.
    • Avoiding Snap-based distribution, which some consider unsuitable or hostile for servers.
    • Frustrations with Certbot plugins, especially DNS plugins guessing the wrong domain or being hard to configure.
  • Others say Certbot is trivial to install via the system package manager (e.g., apt install certbot ...) and “just works,” especially with nginx integration.
  • There is disagreement over whether dependency count actually reduces supply-chain risk, but many still value “no new dependencies.”

DNS mode, flexibility, and hooks

  • DNS-01 mode is praised for:
    • Supporting internal servers not exposed on 80/443.
    • Wildcard certificates.
  • Dehydrated’s hook-based design is seen as a major strength:
    • It delegates DNS manipulation to user scripts, allowing integration with any DNS API or tooling (e.g., cloud CLIs, Vault).
    • Hooks are used for complex setups: vanity domains at scale, multi-load-balancer environments, S3-backed challenges, F5 integration, Kubernetes jobs.
  • Declarative domains.txt is valued: write desired domains, run dehydrated, and it reconciles state.

Shell vs other languages and security

  • Some argue shell scripts are not dependency-free and can be less secure or harder to reason about than Python or Go clients.
  • Others counter that relying only on already-installed base tools limits additional attack surface.
  • Parsing JSON in shell (as dehydrated does) is criticized as fragile; suggestions include using Python or jq.
  • Past security issues in other shell ACME clients are mentioned as cautionary examples.
  • There is side debate over:
    • Bash vs POSIX sh compatibility.
    • Python availability/versions on servers.
    • Go-based alternatives (e.g., lego), C-based clients (uacme), and concerns about their own supply chains.

Project stewardship and ecosystem

  • Dehydrated was sold to a company associated with ZeroSSL, with plans to keep it open source.
  • ZeroSSL’s offerings (IP certificates, long-lived free certs) are noted; some see broader ACME competition beyond Let’s Encrypt.
  • Other alternatives mentioned: Caddy, Traefik, nginx-proxy + acme-companion, cert-manager, and dockerized Certbot.