Native ACME still needs a renewal plan

Putting certificate renewal inside the web server can remove an integration without removing the operational conditions that make renewal work. Choose an ACME client around the challenge your deployment can answer and the state it can preserve. The word “native” does not justify moving a working certificate process before those conditions have been checked.

Looking back from November 2026, NGINX's 12 August 2025 announcement introduced a preview of a Rust-based dynamic ACME module for NGINX Open Source and Plus. Its challenge support at that point was HTTP-01, with a port 80 listener. That is the historical proposal being assessed here, not a claim that today's module has exactly the preview's capabilities.

A local listener is only part of reachability

HTTP-01 asks the certificate authority to validate control of a name through an HTTP challenge. The Let's Encrypt challenge documentation, a mutable reference consulted in November 2026, describes port 80 validation and the limitation that HTTP-01 cannot issue wildcard certificates. Those properties matter before a team compares client convenience.

A listener in an example configuration does not establish that the authority can reach it. The domain's DNS, public routing and any proxy in front of the server participate in that path. A deployment with several frontends also needs the challenge response to reach the validating request reliably. These are design questions to resolve for the actual environment, not defects established in NGINX's module.

Consider a service whose edge receives public HTTP while an internal NGINX instance receives only forwarded application traffic. Enabling a module on the internal instance would not, by itself, make the challenge public. Someone still has to decide which component answers validation and how a request gets there. This is an illustrative topology, not an AL+ installation.

A deployment that cannot expose the required HTTP path may need a different challenge and a client that supports it. A wildcard requirement also changes the choice. That is a reason to keep a suitable existing arrangement or evaluate an alternative; it is not a reason to weaken the service's network boundary merely to adopt native renewal.

Renewal state belongs in the deployment design

The current official module reference explains persisted state and sensitive key material. It also exposes an important historical difference: before module 0.2.0, the state directory was not created by default. A configuration copied without its version context could therefore carry a different persistence assumption from the August preview.

The same reference lists prebuilt packages associated with NGINX 1.29.0 and later. Its challenge directive appeared in module 0.2.0 and now lists HTTP-01 and TLS-ALPN-01. These are two different version axes: the server and the module. Neither should be collapsed into a statement that all installations of a familiar NGINX version already have the feature.

The module repository's installation requirements, also read in November 2026, distinguish a source build from package availability. For source builds they list NGINX 1.22.0+, Rust 1.81.0+ and OpenSSL 1.1.1+, alongside other build dependencies. They require matching the target NGINX and dependencies, particularly the SSL implementation. Package compatibility and module presence should be checked in the deployment inventory, rather than inferred from the marketing term “built-in.”

For a disposable container, durable state needs a deliberate home outside the container's disposable filesystem. For several instances, an owner needs to decide which instance requests certificates and how the others obtain what they need. Shared in-memory storage and disk persistence solve different problems. Simply increasing a shared-memory zone does not turn it into recovery storage after replacement.

State also contains secrets. The operational plan should name who can read it, how restoration works and what happens when an instance is replaced. This article executes no TLS configuration, certificate issuance or production change. These are proposed acceptance questions, not a verified configuration recipe.

Keeping an external client can be the simpler system

The strongest case for staying with an external client is an existing process that already meets the deployment's challenge, renewal and recovery requirements. Replacing it creates migration work and another set of failure conditions to understand. Fewer components in a diagram do not automatically mean less work across the service's lifetime.

The native approach has a real advantage when the same maintainers own the server and certificate lifecycle and can support the module's requirements. Renewal intent can sit closer to the serving configuration. That may remove a separate handoff between issuing a certificate and making the server use it. The benefit is conditional on the deployment fitting that arrangement; no measured reduction in incidents is claimed here.

Conversely, central certificate management across different services may justify keeping issuance separate. An organization should compare where responsibility is clearest, not count how many executables it can remove. The announcement's claims about simpler management are the vendor's case for adoption, not independent proof of a safer outcome for every topology.

Choose the boundary that can survive replacement

For custom software development, make certificate ownership part of the maintenance handover. Record the selected client and module versions, the challenge route and the location of durable state. Include how a replacement instance resumes renewal and how a maintainer learns that renewal has stopped working.

The August preview made a useful alternative available. It did not make HTTP reachability or renewal continuity somebody else's problem. Adopt the native client where those responsibilities fit the server's operating model, and retain another client where the challenge or deployment requires a different boundary.