Certimate: a self-hosted ACME client that deploys certificates to 150+ destinations

The gap Certimate fills between ACME clients and cloud consoles

Most ACME clients stop when the certificate file lands on disk. That is fine when the same machine serves the traffic. It stops being fine the moment the certificate has to live somewhere else: an Alibaba Cloud CDN distribution, an AWS CloudFront distribution, a Kubernetes secret, a WAF rule set, a load balancer that only accepts uploads through a vendor API. The usual answer is a cron job, a shell script, and a set of API credentials pasted into that script.

Certimate targets exactly that gap. The README describes it as an "open-source and free self-hosted SSL certificates ACME tool" that automates issuance, deployment, renewal and monitoring through a visual workflow. The repository's go.mod lists vendor SDKs for Alibaba Cloud, AWS, Azure, Akamai and G-Core, which is consistent with the claim of 150+ deployment destinations: each destination is implemented as a Go integration rather than a shell call. The intended user is an operator who manages certificates across several providers and wants the state of each one visible in one place, without running a database or a runtime alongside it.

How the workflow engine, challenge solvers and provider adapters fit together

The repository layout separates the moving parts. cmd/ holds the entry points, internal/ holds the application logic, pkg/ holds reusable packages, migrations/ holds schema migrations for the embedded store, and ui/ holds the front end. The Dockerfile builds the UI with node:24-alpine, then copies ui/dist into a golang:1.25-alpine stage that compiles the server with CGO_ENABLED=0, and finally ships the binary in a plain alpine:latest image. That three-stage build is why the README can call the result zero-dependency: the front end is compiled into the same binary that serves it.

A workflow is the unit of work. The README says it supports requesting single, multiple and wildcard domain certificates, plus IP address certificates, with RSA or ECC keys. Challenges can be DNS-01 or HTTP-01. Output formats include PEM, PFX and JKS. The DNS-01 path is the one that matters for wildcards and for hosts that are not reachable from the ACME server, and the README claims more than 70 domain registrars as DNS providers. The documentation site links a separate article on completing ACME DNS-01 challenges with CNAME records, which is the standard way to delegate the _acme-challenge name to a zone you control.

Deployment is the second half. A workflow issues the certificate, then hands it to one or more deployment targets. Notification channels (email, Discord, Slack, Telegram, DingTalk, Feishu, WeCom) report the outcome. The whole chain is configured through the web UI rather than a config file, which is the main structural difference from an ACME client you drive from the shell.

Installing Certimate with Docker and running the first workflow

The README gives two installation paths. The binary path downloads an archive from GitHub Releases, extracts it, and runs the executable. The Docker path is the one most people will use, and the README prints it verbatim:

docker run -d \
  --name certimate \
  --restart unless-stopped \
  -p 8090:8090 \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/timezone:/etc/timezone:ro \
  -v $(pwd)/data:/app/pb_data \
  certimate/certimate:latest

The port mapping is 8090 on both sides. The volume mount that matters is $(pwd)/data to /app/pb_data: that directory is where the application stores its data, so if you drop that line the container starts clean every time. The two read-only timezone mounts keep scheduled renewals aligned with your local clock. The Dockerfile's entrypoint runs ./certimate serve --http 0.0.0.0:8090, which is why the container listens on all interfaces rather than loopback.

After the container is up, the README says to visit http://127.0.0.1:8090 in a browser. The default administrator account is listed as [email protected] with the password 1234567890. Change those before the service is reachable from anywhere but your own machine; the README does not describe a forced password change on first login.

For a local build instead of a container, the Makefile exposes a target that installs the UI dependencies, builds the front end, and runs the server:

make local.run

That target expands to go mod vendor, npm --prefix=./ui install, npm --prefix=./ui run build, and go run main.go serve --http 127.0.0.1:8090. The Makefile also defines a build target that cross-compiles for linux, darwin and windows on amd64 and arm64 into the dist directory.

Once you are logged in, the first real use is a workflow with two nodes: a certificate node that names your domains and picks the CA and challenge type, and a deployment node that names the destination and supplies its credentials. The README states that Let's Encrypt, Actalis, Google Trust Services, SSL.com and ZeroSSL are among the supported ACME CAs. You supply DNS provider credentials for DNS-01, or leave port 80 reachable for HTTP-01. The README does not walk through the node editor step by step, so the documentation site at docs.certimate.me is the place to look for the field-by-field configuration.

Where Certimate is the wrong tool

The visual workflow is the product, and it is also the constraint. If your certificate issuance already lives in a Git repository as a Terraform module or an Ansible role, moving it into a web UI takes it out of code review. Certimate stores workflow definitions in its own data directory, not in a file you can diff. The repository includes a migrations/ directory, which implies a schema that changes between releases, and the README links a migration guide for v0.4. That is a signal that upgrading across minor versions can require following a documented procedure rather than pulling a new image. The README does not document rollback.

Credentials are the second constraint. A workflow that deploys to a cloud CDN needs an API key with write access to that CDN. Certimate's self-hosted model keeps those credentials on your own host rather than a vendor's, which is the point, but it also means the security of every certificate in every account depends on the security of that one host and its data directory. The README's disclaimer is explicit that the software is distributed as-is without warranty and that users take full responsibility for outcomes.

Scale is the third. A team that issues two certificates a year for one domain gets nothing from a workflow engine that the ACME client already bundled with their reverse proxy provides. Certimate earns its place when the number of destinations, or the number of accounts, makes manual upload the bottleneck.

Certimate compared with Certd, Allinssl and acme.sh

The related searches around this project name Certd and Allinssl, which are the closest comparisons: both are self-hosted certificate management tools with a UI and multi-provider deployment. The meaningful difference to check is provider coverage and the shape of the workflow model, since all three solve the same problem. Certd and Allinssl are separate projects with their own documentation; this article does not cover their internals, and the README of Certimate does not compare itself to either.

The comparison that is easier to make is with acme.sh, because the difference is architectural rather than a matter of degree. acme.sh is a shell script driven by flags and a cron entry; its configuration is a file on disk, and deployment is whatever hook you write. Certimate is a Go server with an embedded front end and a database, driven through a browser. acme.sh fits a single host with a deploy hook you already trust. Certimate fits a fleet of destinations where you want the deployment steps to be selectable rather than written. The trade is that acme.sh has no service to keep running, and Certimate does.

Maintenance cost, release cadence and the MIT licence

The repository is not archived, and the last push was on 2026-08-17. The release list shows v0.4.31 on 2026-08-17, v0.4.30 on 2026-08-10, and v0.4.29 on 2026-07-31, so point releases have been arriving roughly weekly in that window. A weekly cadence cuts both ways: fixes land quickly, and the surface you have to re-verify on upgrade is larger than with a tool that ships twice a year. The migrations/ directory and the v0.4 migration guide are the concrete things to read before jumping versions.

Licensing is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The README adds a disclaimer of warranty and places responsibility for outcomes on the user. That is a statement about liability, not a restriction on use. If you embed Certimate in a product you distribute, the MIT terms are permissive, but the vendor SDKs pulled in through go.mod carry their own licences, and those are worth checking if your distribution model is not purely internal. Nothing here is legal advice.

The operational cost is one container and one mounted directory. The README claims roughly 16 MB of memory, which is plausible for a Go binary with CGO disabled, but this article has not measured it and you should treat the figure as the project's own claim.

Editorial conclusion

Adopt Certimate if you already hold credentials for the DNS provider and the hosting platform that terminate your certificates, and you want one self-hosted place where issuance, deployment and renewal are recorded together. Skip it if you only need one certificate on one server and acme.sh or certbot already covers that, or if your deployment target is not among the providers the documentation lists. Before you put it in front of production traffic, verify three things: that your target destination appears in the provider reference, that the data directory you mount actually persists across a container restart, and that the default admin account has been changed away from the credentials the README prints.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes