Acmebot: DNS-01 certificate automation for Azure, with Key Vault as the store

The problem it solves is scale, not difficulty

Acmebot helps Azure platform and operations teams automate ACME certificate issuance and renewal without building a dedicated certificate pipeline. It uses DNS-01 validation, stores private keys and issued certificates in Azure Key Vault, and exposes a dashboard and HTTP API for day-to-day operations.

The framing matters. Almost every Azure service can issue a certificate on its own, and the built-in mechanism is fine for one service. The problem Acmebot addresses is the fleet: the same certificate across an App Service, a Front Door and an Application Gateway, with renewals happening on independent schedules and an alert going to the wrong place when one fails.

The five bullets in the motivation section are the requirement list that describes who it is for. Store SSL/TLS certificates securely in Azure Key Vault. Centralize certificates for multiple Azure services and domains. Automate certificate fleets with per-certificate renewal state and predictable operational behavior. Monitor certificate operations through Application Insights and webhooks. Keep DNS provider credentials and Azure access scoped to the resources Acmebot manages.

The last one is the security argument, and it is the most interesting. DNS-01 validation means the service has to create a TXT record in your DNS zone to prove domain control, which means it needs DNS provider credentials. A centralised ACME client therefore holds credentials that can write to your DNS, and the scoping requirement is the mitigation: the credentials should be able to touch only the zones Acmebot manages.

Key Vault is the other half of that story. Private keys do not sit in a container, they are stored in Azure Key Vault, and the project describes the practical effect as key store and certificate management with the keys under Key Vault's control.

The licence is Apache License 2.0, and the documentation is at acmebot.dev with the guide at acmebot.dev/guide.

ARI-aware renewal, and why the state is per certificate

The renewal logic is where the engineering is, and the feature list is more specific than a typical certificate bot.

There is ARI-aware renewal scheduling for each managed certificate, with CA-provided renewal windows, `Retry-After` timing, and an expiry-based fallback. And there is independent renewal state and next-check timing per certificate, built for long-running certificate fleets.

ARI is the ACME Renewal Information mechanism, and it changes the renewal model in a specific way. Instead of the client guessing when to renew based on a fraction of the lifetime, the CA tells the client when a certificate should be renewed, usually through a short-lived HTTP resource. So instead of renewing at two thirds of a ninety day life, the client can renew at the moment the CA suggests, which for a short lived certificate is a large saving on the number of issuances and a large reduction in the risk of a missed renewal.

The `Retry-After` timing is the part that matters when a CA is busy, which is most of the time for a free CA. The server says when to come back rather than the client retrying on its own schedule and getting rate limited harder.

And the expiry-based fallback covers the case where the CA does not offer ARI, so the client has something to do. That is a real design consideration, because the fallback has to be conservative enough to never miss an expiry and the ARI path has to be precise enough not to renew too early.

Independent state per certificate is what makes the fleet claim hold. A single global next-check timer means one certificate that fails can either delay every other certificate or be retried on a shared schedule. Per-certificate state means one bad domain does not affect the others, and the service can report on each one individually.

The claim is worth weighing against the alternative. A managed certificate feature inside each Azure service handles renewal for you but gives you no central view and no shared store. A script with certbot handles a handful of domains but has no state, no dashboard and no per-certificate recovery. Acmebot is the middle option, and it costs you an Azure Function app and a Key Vault to get there.

One implementation, many Azure surfaces

The certificate types supported are zone apex names, wildcards and SANs, multiple domains. The services supported are the more interesting list.

Certificates can be used with App Service covering Web Apps, Functions and Containers, and Container Apps including a custom DNS suffix. Then Front Door in both Standard and Premium, Application Gateway v2, API Management, Web PubSub in Premium, Event Grid Namespaces, SignalR Service in Premium, and Virtual Machine.

The parenthetical about tiers matters in practice. Several of these are Premium-only or have a Flex Consumption equivalent, and if you are on the Standard tier of Front Door or on the Consumption plan of an App Service, some of those integrations are not available to you.

The Container Apps entry with a custom DNS suffix is the one to look at, because a custom domain suffix on a Container Apps environment needs the certificate to be issued for a name that is not a normal zone apex, and the environment's own wildcard handling has to line up with what the certificate covers.

The CA list is worth reading too, because it is not just Let's Encrypt. Support is for ACME v2 compliant Certification Authorities, and the list is Let's Encrypt, GlobalSign which requires EAB credentials, Google Trust Services which requires EAB credentials, SSL.com which requires EAB credentials, and ZeroSSL which requires EAB credentials.

The EAB note is a practical detail. External Account Binding is a mechanism where the CA requires a client to present a pre-issued credential, which is how the commercial CAs tie a certificate request to an account you have with them. It is an extra setup step, and it is the reason the ACME v2 support matters, since older versions of the protocol did not have it.

So a team that wants Let's Encrypt needs no extra credential, and a team that wants a commercial CA has one account setup to do per provider. That is the price of the choice, and it is a choice the project deliberately supports rather than hard coding to a single free CA.

Deploying it, and the one cloud boundary

Acmebot v5 is generally available, and the deployment is a single click through an Azure template. The template provisions the required Function App on the Flex Consumption plan, Storage, Application Insights, Log Analytics, and optionally a new Key Vault.

That list is the architecture. The Function App is where the ACME logic runs, and Durable Functions is credited in the thanks section, which is the Azure Functions extension for writing workflows as code rather than as a chain of triggers and queues. ACME issuance is an inherently stateful, multi-step process with retries and waiting, and Durable Functions is a good fit for that. DnsClient.NET is the other credited project, the .NET DNS client used to create the validation records.

The one hard boundary is stated plainly. The v5 deployment template supports the Azure public cloud only, because Flex Consumption is not available in Azure China or Azure Government.

That is worth understanding rather than discovering. The restriction comes from the compute platform, not from the certificate logic, so an organisation operating in a sovereign cloud cannot use this deployment even though the code itself might work. There is a Terraform module badge for the azurerm provider, so there is an infrastructure-as-code path as well as the portal template, and the getting started guide covers detailed setup instructions and DNS provider configuration.

The repository layout is a .NET solution with the usual separation. There is an `Acmebot.slnx` solution file, a `Directory.Build.props` for shared build properties, a `global.json` pinning the SDK, and directories for `deploy/`, `docs/`, `samples/`, `src/` and `tests/`. The `samples/Acmebot.Acme.Sample/` directory holds a sample, which is the fastest way to see how the library is meant to be called.

The documentation site has a guide directory, and the community routes are the standard ones: Discussions for questions, Issues for bugs, plus a contributing guide, a support file, a security policy and a code of conduct.

Open source with a commercial support option beside it

The project is explicit about its commercial arrangement, and it is a model worth understanding because it is becoming common in infrastructure tooling.

Commercial support for Acmebot v5 is now available from Polymind Inc. It is optional and intended for organisations running Acmebot in production, and it can cover deployment planning, v4-to-v5 migration, Azure and DNS provider configuration, troubleshooting, and operational guidance.

And the next paragraph is the important one. Acmebot remains fully open source and free to use under the Apache License 2.0, and community questions and bug reports continue to be handled through GitHub Discussions and Issues.

So the arrangement is open source with a paid front door for the organisations that want someone to call. The Apache 2.0 licence means the code is usable without restriction, and the v4-to-v5 migration in the support list is a tell, because a major version boundary in a service like this is where the operational risk lives, and the migration is exactly the kind of work an organisation will pay to have covered.

There is also a sponsorship route, with a sponsor badge for ZEN Architects and a link to become a sponsor. Sponsorship funds the development, and commercial support is a separate arrangement for a different need.

On versions, the recent releases are v5.1.3 on 2026-07-30, v5.1.4 on 2026-08-26 and v5.1.5 on 2026-09-30, and the last push was on 2026-10-10, so the project is on a steady patch cadence within the 5.1 line rather than pushing minor releases frequently, which is a sensible rhythm for a service whose own behaviour changes less often than its clients' needs do.

Editorial conclusion

Acmebot fits an Azure platform team that has a lot of services and domains to cover and wants certificate renewal handled in one place with the keys in Key Vault rather than in a filesystem on a VM, because the service covers App Service, Front Door, Application Gateway, Container Apps and more from a single function app. Skip it if you are not on Azure, since the deployment template supports the Azure public cloud only, and skip it if you need a private certificate authority or a non-ACME source. Before you deploy, read the getting started guide for the DNS provider configuration, and check whether DNS-01 delegation is something you can add records for. The last push was on 2026-10-10 and the current release is v5.1.5.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. polymind-inc/acmebot on GitHub
3. Project website
4. README
5. Releases