AllinSSL: a self-hosted control plane for SSL certificate issuance, deployment and expiry monitoring

The gap AllinSSL targets: certificates that expire on infrastructure you do not log into daily

Certificate renewal is not hard on a single web server. It becomes hard when the same certificate has to land in a CDN, a WAF, a control panel and an object storage bucket, each with its own API and its own credential format. The usual answer is a shell script per target, which works until someone rotates an API key or a host is rebuilt.

AllinSSL is a self-hosted application that assumes you want one place to hold the DNS provider credentials, the ACME account, the deployment targets and the expiry schedule. The README lists the intended audience indirectly through its provider tables: DNS validation through Alibaba Cloud, Tencent Cloud and Cloudflare, certificate deployment to BaoTa Panel, 1Panel, Alibaba Cloud CDN and Tencent COS, and monitoring alerts by email, webhook and DingTalk. Those are Chinese cloud and hosting ecosystems first, with Cloudflare as the obvious international entry point.

If your stack is a single Nginx box with one certificate, this is more machinery than the problem needs. If your stack is a dozen domains spread across two CDNs, a panel and a bucket, the coordination problem is real and the tool is aimed at it.

Inside the box: Go backend, Vue frontend, SQLite, and a workflow engine in the middle

The repository is a monorepo. The architecture diagram in the README splits it into four layers. The frontend is Vue 3 with Naive UI, built by Vite inside a Turbo monorepo. The backend is Gin, exposing a RESTful API with session management and a middleware layer. Between them sits a workflow engine that fans out to five core services: certificate apply, certificate deploy, monitor scheduler and notification service, all reading and writing a SQLite database plus file storage.

The external edges are the interesting part. Certificate issuance goes through the ACME protocol, and the acknowledgements name lego as the Go ACME client powering core certificate issuance. Deployment goes out to cloud provider APIs, DNS providers for validation, and CDN or panel APIs for pushing the issued certificate. The go.mod file confirms the breadth of that integration surface: SDKs for Alibaba Cloud, Tencent Cloud, Baidu, Huawei Cloud, JD Cloud, Volcengine and Azure, plus Qiniu, OSS, SFTP, PKCS#12 and JKS keystore handling. The presence of tjfoc/gmsm suggests ShangMi (SM) certificate support alongside standard TLS.

The practical consequence of that design: the workflow engine is the single point where a renewal, a deployment and a notification are sequenced, and the SQLite file is the single point where state lives. Both are local. There is no documented clustering or external database option in the README, so the deployment model is one instance per environment.

Installing AllinSSL: script, Docker, binary, or a Go build

The README gives four install paths. The script installer is Linux-first; the README states that macOS and Windows script installation is not yet supported, and points those users at the manual binary steps. The one-line install fetches a shell script and runs it with the argument allinssl.

curl -sSO http://allinssl.bt.cn/install_allinssl.sh && bash install_allinssl.sh allinssl

A mirror host is documented for the same script if the primary host is unreachable.

curl -sSO http://download.allinssl.com/install_allinssl.sh && bash install_allinssl.sh allinssl

Docker is the shortest path to a running instance. The command below maps port 8888, mounts a data directory, and passes the username, password, secure entry path and timezone as environment variables.

docker run -itd \
  --name allinssl \
  -p 8888:8888 \
  -v /www/allinssl/data:/www/allinssl/data \
  -e ALLINSSL_USER=allinssl \
  -e ALLINSSL_PWD=allinssldocker \
  -e ALLINSSL_URL=allinssl \
  -e TZ=Asia/Shanghai \
  allinssl/allinssl:latest

The Dockerfile shows what happens on first boot. An entrypoint script checks for /www/allinssl/data/.initialized; if it is missing, it pipes the environment values into the CLI subcommands 5, 4, 6 and 7 to set username, secure entry, password and port, then touches the marker file. Change those environment variables before the first run, or the defaults in the README apply.

Building from source requires Go 1.23 or later according to the README, while go.mod declares go 1.24.0. The commands are git clone, go mod tidy, go build -o allinssl cmd/main.go, then ./allinssl start.

Once running, the first-time setup is three steps in the README: visit http://your-server-ip:port/<secure-entry>, add DNS provider and host provider credentials, and create a workflow. The secure entry is a path prefix, not a separate port, and the CLI subcommand 15 prints the panel URL if you lose it.

The CLI is a numbered menu, and that shapes how you automate it

AllinSSL's command line is not a set of named flags. It is a numbered menu, documented in the README as subcommands 1 through 17. Start, stop and restart are 1, 2 and 3. Secure entry, username, password and port are 4, 5, 6 and 7. Web service enable, disable and restart are 8, 9 and 10. Background scheduler enable, disable and restart are 11, 12 and 13. Disable HTTPS is 14, get panel URL is 15, update to the latest version is 16, and uninstall is 17.

./allinssl 15
./allinssl 16

The first command prints the login URL and username on Linux; the README notes the Windows equivalent is .\allinssl 15. The second triggers an overwrite update to the latest version. That number-as-interface choice is efficient for a human at a terminal and awkward for configuration management, because the meaning of a number is not self-describing in a provisioning script. The Docker entrypoint works around this by piping values into 4, 5, 6 and 7, which is a good illustration of the pattern: you can automate it, but you are automating against positional numbers.

Note also that the scheduler is separately switchable from the web service. Disabling the background scheduler (11) stops renewals and monitoring while leaving the console reachable. That split is useful during maintenance, and it is also a way to silently stop renewing certificates if someone forgets to re-enable it.

Where AllinSSL is the wrong tool

The README does not document rollback. There is no described mechanism for reverting a deployed certificate to a previous one, and no stated backup or restore procedure for the SQLite database that holds workflows and provider credentials. If a deployment pushes a bad certificate to a CDN, the documented path back is to fix it through the provider's own console, not through AllinSSL.

The provider coverage is also asymmetric. DNS validation names Alibaba Cloud, Tencent Cloud and Cloudflare with an ellipsis, and certificate deployment names BaoTa Panel, 1Panel, Alibaba Cloud CDN and Tencent COS. If your DNS lives somewhere not on that list, the ACME challenge has no documented path through this tool, and you would be running a general ACME client instead. The go.mod dependency list is broader than the README tables, which suggests more integrations exist in code than are advertised in the documentation, but the README is what a new operator has to plan against.

Finally, the architecture is single-node. SQLite plus local file storage, no external database, no described high-availability mode. For a homelab or a small fleet that is fine. For a platform team that needs the certificate control plane to survive the loss of one VM, the README offers nothing.

Licensing is the other boundary. The project is AGPL-3.0. If you modify it and let users interact with it over a network, the licence's network clause is the thing your legal team will want to read. This is a description of the licence identifier, not legal advice.

Alternatives: Certimate, Certd, and plain ACME clients

The README's acknowledgements are unusually candid about lineage. Certimate and Certd are both named as workflow design references, and the JD Cloud DNS implementation is credited to certimate. That matters because the three tools occupy the same niche, and the choice between them is mostly about provider coverage and deployment shape rather than a fundamental difference in concept.

Certimate is the closest comparison. It shares the workflow-oriented model that AllinSSL credits it for, and it is a Go project in the same space. The difference an operator will notice first is which providers each one has wired up: AllinSSL's advertised deployment targets lean toward Chinese panels and clouds, and its go.mod shows SDKs for Alibaba Cloud, Tencent Cloud, Huawei Cloud, Baidu, JD Cloud, Volcengine, Qiniu and Azure. Certd is the other workflow reference, and it is the name people search alongside AllinSSL.

Below all three sit the plain ACME clients. lego is what AllinSSL uses internally for issuance, and acme.sh and Certbot are named in the acknowledgements as prior art. Those tools issue certificates well and deploy them poorly. If your deployment target is one Nginx reload on the same machine, an ACME client plus a cron entry is less to run and less to secure. AllinSSL earns its footprint only when the deployment step is the part that hurts.

The service-shaped alternatives, OHTTPS and Httpsok, appear in the same search results. The structural difference is hosting: those are services you hand credentials to, while AllinSSL is software you run yourself, which is the reason to pick it and also the reason you now own its patching.

Maintenance, upgrades and what you are taking on

The repository is not archived and the last push was on 2026-09-04. Releases are infrequent rather than continuous: v1.1.1 on 2025-09-18, v1.1.2 on 2026-01-21, and v1.1.3 on 2026-05-28. The default branch is named 1.1.3, so branch naming tracks releases rather than a long-lived main line, which is worth knowing before you point a CI checkout at it.

Upgrades have a documented path: CLI subcommand 16 updates to the latest version and is described as an overwrite install. That phrasing is the operational warning. An overwrite install replaces the binary, and the README does not describe a migration step for the SQLite schema between versions. Back up /www/allinssl/data before running it, because that directory holds the database and the .initialized marker that the Docker entrypoint depends on.

The dependency list is the other maintenance cost. go.mod pulls SDKs from Alibaba Cloud, Tencent Cloud, Huawei Cloud, Baidu, JD Cloud, Volcengine and Azure, plus lego for ACME. Each of those vendors rotates API versions and deprecates endpoints on its own schedule, so the upgrade treadmill is driven by upstream SDK churn as much as by AllinSSL's own releases. That is the price of the multi-provider design, and it is the thing to weigh against running a handful of small scripts you fully understand.

Editorial conclusion

Adopt AllinSSL if you already hold credentials for the DNS, CDN or panel providers it lists and you want one console that issues, deploys and watches expiry dates instead of a cron job per host. Do not adopt it if you need a supported commercial product with an SLA, or if you cannot accept AGPL-3.0 obligations for however you expose it. Before deploying, verify the secure entry path printed by the panel, confirm your provider appears in the DNS validation and certificate deploy tables, and check whether the Docker image's default credentials are still in place, because the entrypoint only writes them when /www/allinssl/data/.initialized is absent.

Frequently asked questions

Official sources

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