Certd: self-hosted certificate automation with a pipeline model

What Certd solves, and who actually needs it

The README states the problem plainly: free certificates expire after 90 days, and that window may shrink. Renewal is not a file edit. Certd's documentation says there is no way to extend a certificate without changing the file itself, so what the project calls renewal is a full re-issuance followed by a redeployment. That framing matters, because it defines the product as a workflow engine rather than a certificate store.

The intended user is someone with more than a couple of hostnames. Certd supports DNS-01, HTTP-01 and CNAME proxy validation, wildcard certificates, and multiple domains packed into one certificate. On the other end it ships deployment plugins for hosts, Alibaba Cloud, Tencent Cloud, Synology, Baota, 1Panel, Kubernetes and CDNs. The README puts the plugin count at 110+. If your problem is one nginx box and one domain, this is more machinery than you need.

The project also targets teams that cannot hand SSH credentials to a SaaS. Certd runs on your own server, stores authorization data locally, and offers 2FA, encrypted credentials and site hiding. The README is explicit that certificates and authorization data are highly sensitive and that private deployment is the expected mode.

The pipeline model: how issuance and deployment are wired

Certd's central abstraction is the pipeline. A pipeline is created for a certificate, then deployment tasks are attached to it, and a schedule runs the whole thing. The README calls this a pipeline-based certificate application and deployment mode and notes it has been copied by other projects, which is at least a signal about how the model reads to users.

The data flow is: the pipeline runs, the certificate is requested through the configured validation method, and each attached deployment task receives the resulting certificate in the formats it needs. Certd supports pem, pfx, der, jks and p7b output, which is why the same issued certificate can feed an nginx host, a Java keystore and a cloud load balancer without separate issuance runs. The README also documents a manual download path for targets with no plugin.

Two ecosystem pieces extend the reach. Certd Client is an official agent that runs on the application server, discovers local nginx, Apache and IIS sites, pulls certificates from Certd and deploys them. It exists for hosts that should not expose SSH. SSL-Assistant is a third-party client that scans nginx config on a host and pulls certificates from Certd, aimed at the same no-SSH scenario. Both are separate downloads, not part of the server image.

Installing Certd with Docker and running a first pipeline

The README recommends Docker deployment and links to a one-line install script for the case where Docker is not yet present. The script downloads and runs an installer from the project's Gitee repository, and the README notes it installs Docker and Certd automatically.

curl -fsSL https://gitee.com/certd/certd/raw/v2/docker/run/install.sh | bash

If you already run Docker and prefer to control the image, use the documented image names. The default registry is Alibaba Cloud, with Docker Hub and GitHub Packages as alternatives. Tags are split by channel and by base image: `certd:latest` tracks the newest development build, `certd:stable` is described as the production-ready tag, `certd:slim` is based on Debian slim for glibc DNS compatibility, and `certd:armv7` targets ARMv7. The README says to use `certd:latest` if you are unsure, which is a slightly odd recommendation given it also says `latest` is less stable than `stable`.

Once the container is up, the documented flow is three steps. Create a certificate pipeline, run it to issue the certificate, then add deployment tasks. The README's worked example deploys to nginx on a host. If no plugin fits, the UI offers a manual download of the certificate files. Finally, set the pipeline to run on a schedule so the certificate is re-issued and redeployed before it expires. The README points to a step-by-step walkthrough at step.md and to the documentation site for the rest.

Where Certd stops being the right tool

The honest limitation is in the project's own wording: there is no true renewal. Every cycle is a new certificate and a new deployment. If a target system cannot reload its certificate without a restart you are unwilling to perform, the pipeline will keep issuing certificates that never take effect. The README does not document rollback for a failed deployment, so a broken deployment task is something you find in the logs, not something the tool undoes.

Security is pushed onto the operator. The README's safety notes say to serve the app over HTTPS, put a web application firewall in front of it, harden the server, and take backups. That is a list of things Certd does not do for you, and the reason is structural: the instance holds certificate private keys and cloud credentials. A self-hosted certificate manager with weak perimeter security is a worse position than a managed service.

There is also a scope split. The README describes a paid professional edition, with sponsor benefits including priority feature requests and professional features. The repository's own package scripts reference a `packages/pro/` directory and a publish flow that commits to it. So the open source edition is not the whole product surface, and features you want may sit behind the paid tier. The README does not itemize which features are professional-only.

Certd compared with Certimate and AllinSSL

The related searches surface Certimate and AllinSSL alongside Certd, and the comparison is mostly about deployment breadth versus weight. Certd's distinguishing choice is the pipeline plus plugin architecture: 110+ deployment plugins, a client agent for hosts without SSH, and a RESTful API for integration. The cost of that breadth is a server component, a database, a UI and a scheduler to operate.

A lighter alternative in the same space is the ACME client you probably already have. certbot with a deploy hook does issuance and deployment in a few lines of shell, with no database and no web UI. It gives up centralized monitoring, multi-user management, the plugin catalog and the multi-format output. If your deployment targets are two nginx servers, certbot plus a systemd timer is the smaller system and has fewer moving parts to secure.

Certd's other differentiator is the deployment target list itself: Alibaba Cloud, Tencent Cloud, Synology, Baota, 1Panel, Kubernetes, CDNs. If your infrastructure is Chinese cloud and panel hosting, that coverage is the practical reason to pick it over a generic ACME client.

Maintenance cost, licence and upgrade path

Certd is not archived, and the last push to the default branch was on 2026-09-20. Releases have been frequent: v1.44.4 on 2026-09-12, v1.44.3 on 2026-09-06, v1.44.2 on 2026-09-03. The README claims worry-free upgrades and backward compatibility across versions, and links to a dedicated upgrade page. Treat that as a claim to verify against the changelog before a major jump, not as a guarantee.

The operational cost is a running service. You need a host, a database (SQLite, PostgreSQL, MySQL or MariaDB), HTTPS in front, a firewall, and backups of a store that holds private keys. The official client and the third-party SSL-Assistant agent each add another process on the application servers. None of that is heavy individually, but it is a system to own rather than a script to forget about.

The licence is AGPL-3.0 for the repository. If you only run the container for your own certificates, that is the ordinary case. If you modify Certd and expose it to users over a network, the AGPL's network clause is the part to read carefully with your own counsel. This is not legal advice; the point is that a self-hosted tool with a copyleft network clause is a different commitment from a permissively licensed one.

Editorial conclusion

Certd is worth adopting if you run many domains and want issuance, deployment and expiry monitoring under one self-hosted roof, and you are willing to run it behind HTTPS on a host you control. Skip it if you have a handful of certificates and a working certbot renewal unit, or if you cannot accept AGPL-3.0 terms for the server component. Before committing, verify two things on your own machine: that the deployment plugin you need exists for your target, and that the stable image tag you plan to pin actually matches the release you intend to run.

Frequently asked questions

Official sources

1. certd/certd on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases