Let's Encrypt Did the Math for You: What ARI Renewal Exemptions Actually Buy a Self-Hosted PaaS at Tenant Scale

If you mint one TLS certificate per tenant subdomain, Let's Encrypt lets you onboard exactly 50 new tenants a week. Tenant 51 waits until next week. No override, no appeal — unless you change how renewals work.

That number is not a guess. Let's Encrypt's Certificates per Registered Domain limit caps issuance at 50 certificates per registered domain every 7 days, and it is global across all accounts. Every tenant-51.yourpaas.com cert counts against the same budget as tenant-1.yourpaas.com. But here is the part most self-hosted platform operators miss: renewals coordinated through ACME Renewal Information (ARI, RFC 9773) are exempt from all rate limits. So the steady-state cost of holding certificates for 200 tenants — or 20,000 — can be zero limit budget, while onboarding bursts and fleet-wide reissues are where the walls actually are.

A concrete worked example: 200 tenants onboarding onto per-subdomain certs takes a minimum of four weeks at the cap (50/week), but once issued, their renewals consume no rate-limit budget at all if your ACME client speaks ARI.

This post works out the exact headroom math for a git-push PaaS, shows where ARI changes the answer versus the legacy renewal exemption, and lists what turning ARI on concretely takes in cert-manager today.

The four limits that bind a PaaS​

Let's Encrypt publishes a full rate limits page (last updated August 2026). Most of it will never bite a small deployment. Four limits will bite a platform that auto-provisions certificates per tenant:

Two design notes matter before doing arithmetic. First, the registered-domain limit uses the Public Suffix List to decide what a "registered domain" is, so all subdomains of yourpaas.com share one 50/week budget — but a tenant bringing their own custom domain (tenant.com) brings a fresh budget with it. Second, Let's Encrypt explicitly recommends that large integrators use one account for many customers, which concentrates the 300-orders-per-3-hours budget in one place you can monitor instead of scattering it across per-tenant accounts.

The onboarding math: 50 new tenants a week, no more​

Take the standard git-push PaaS model: each tenant gets tenant-name.yourpaas.com with its own certificate, all under your one registered domain. The binding constraint on growth is the 50-per-week domain cap:

• 200 tenants to onboard: 200 ÷ 50 = 4 weeks minimum, and that assumes zero renewals competing for budget and zero failed validations burning orders.
• A launch spike of 100 signups in a week: the first 50 get HTTPS immediately; the other 50 get rate-limit errors (too many certificates already issued) until the token bucket refills — roughly one cert slot every 202 minutes.
• Steady state after onboarding: each tenant's cert renews roughly every 60 days. 200 tenants means ~23 renewals a week. Under the legacy renewal rule (same exact identifier set counts as a renewal), those are exempt from the orders and registered-domain limits — so steady state fits comfortably. Onboarding is the wall, not renewal.

Now change one variable: tenants with custom domains. Each custom domain is its own registered domain with its own 50/week budget, so the domain cap stops binding entirely. What binds instead is New Orders per Account: 300 per 3 hours through your single ACME account. That is ~16,800 orders a week — plenty for onboarding, but a fleet-wide forced reissue (say, rotating keys across 20,000 custom-domain certs at once) would need ~67 three-hour windows, or about 8 days, serialized through one account.

If you plan to operate at that scale, that is the number to put in the capacity plan — or the number on the rate-limit override request form, which exists for the orders and registered-domain limits but explicitly not for the duplicate or authz-failure limits.

And the honest alternative to all of this: a wildcard certificate (*.yourpaas.com) covers every tenant subdomain with one cert and one renewal. It needs DNS-01 validation and it concentrates risk — one key, one renewal event — but if your tenants do not need individual certificates, the cheapest rate-limit strategy is needing fewer certificates. ARI matters most when you have decided, for tenant isolation or custom-domain reasons, that per-tenant certs are the architecture.

ARI vs legacy renewal: the exemption gap that actually matters​

Let's Encrypt recognizes a renewal two ways, and they are not equal. This is the distinction the whole post turns on:

• ARI renewal (preferred): your client polls the CA's renewalInfo endpoint, renews inside the CA-suggested window, and sends the new order with a replaces field pointing at the old cert. Conditions from the official docs: the order must share at least one identifier with the cert it replaces, and that cert must not have been previously replaced via ARI. Meet those, and the order is exempt from every rate limit — including the 5/week duplicate cap and the authz-failure counters.
• Legacy renewal: the order contains the exact same identifier set as an earlier cert. These are exempt from New Orders per Account and Certificates per Registered Domain — but still subject to the 5-per-exact-set duplicate cap and the authorization-failure limits.

In normal steady state, both work. The gap opens in exactly three scenarios:

1. Fleet-wide forced reissue. A key rotation, a mass-revocation event, or an emergency migration means reissuing many certs faster than one-per-34-hours per identifier set. Without ARI, the duplicate cap (5/week, no overrides) hard-blocks you per tenant. With ARI, the reissue is exempt — and ARI is also the channel Let's Encrypt uses to tell clients to renew early: a suggestedWindow in the past means "renew now," which is how the ecosystem coordinated emergency rotations without every operator reading a blog post first.
2. Reinstall and config-loss loops. Let's Encrypt's own docs name the common causes of duplicate-cap hits: reinstalling the client to troubleshoot, or deleting ACME client state on every deploy so each deploy looks like a brand-new issuance. A PaaS that wipes cert-manager state on redeploy will burn through 5 duplicates fast; ARI's replaces chain survives this only if client state (which cert is current) survives, so persistent ACME account and order state is a prerequisite, not a nicety.
3. Short-lived certificates. This is the one that turns ARI from an optimization into a requirement — see the next section.

Note what ARI never exempts you from needing: first issuance is never a renewal. Every new tenant's first cert spends real budget. ARI makes your installed base free to hold; it does not make growth free.

Turning ARI on: cert-manager 1.21, staging, and budgeting​

The good news is that the client side has caught up. cert-manager 1.21 ships experimental ARI support (RFC 9773) behind the ACMEUseARI feature gate: when enabled, cert-manager polls the renewalInfo endpoint, schedules renewal inside the CA-suggested window, and attaches replaces to the renewal order so Let's Encrypt counts it as an ARI renewal. If you run the ingress layer of a Cluster-API fleet on cert-manager — and most self-hosted PaaS builds do — enabling ARI is a version bump plus a feature gate, not a new component.

Three things stay mandatory anyway, and the TODO item that prompted this post is explicit that they do:

1. Validate against staging first. Let's Encrypt's staging environment carries deliberately higher limits precisely so you can burn through onboarding simulations, reinstall loops, and renewal-path changes without spending production budget. Any ARI rollout that has not done a full renewal cycle against staging is untested where it counts — the replaces handshake only happens at renewal time, which is 60 days after you think you deployed it.
2. Keep your own request budget. One ACME account for the fleet, monitored order rates, alerts well before 300-per-3-hours. ARI exempts renewals; it does not exempt a bug that mints new orders in a loop.
3. Persist ACME client state. As noted above, the replaces chain needs to know which cert is current. Ephemeral client storage turns renewals into duplicate-capped "new" issuance — the exact failure ARI was supposed to prevent.

To make the incentive land, Let's Encrypt announced back in April 2024 — in an engineer's guide to integrating ARI — that ARI-coordinated renewals would be exempt from rate limits at all. That was the CA paying clients to adopt the protocol, and with cert-manager 1.21 the default Kubernetes path to collecting that payment is finally open.

Why this gets more urgent: certificates are getting shorter​

The renewal math above assumes 90-day certificates renewed every ~60 days. That assumption is expiring. Let's Encrypt has published its timeline for shorter lifetimes: an opt-in 45-day tlsserver profile, a roughly 6-day shortlived profile now generally available as an opt-in, and the default classic profile stepping down to 64 days in February 2027 and 45 days in February 2028, driven by CA/Browser Forum requirements.

Shorter lifetimes multiply everything in this post. A 6-day certificate renews on the order of twice a week per tenant — a 200-tenant fleet goes from ~23 renewal orders a week to ~400. Under legacy renewal rules those still dodge the domain cap (same identifier set), but every tenant's cert now sits permanently near the duplicate cap's blast radius, and any fleet-wide event needs 400 exempt-or-not orders a week instead of 23. ARI goes from "nice exemption" to the load-bearing mechanism that makes short-lived certs operable at all — which is presumably why the short-lived profile and ARI are being pushed as a pair.

For a PaaS operator, the practical read: enable ARI before you opt into shorter profiles, not after. The 2027–2028 default-lifetime step-down will arrive on its own schedule whether your renewal path is ready or not.

The bottom line​

The rate-limit story for a self-hosted PaaS has three lines: growth is capped (50 new subdomain certs a week per domain, 300 orders per 3 hours per account), steady-state renewal is free if your client proves it is a renewal, and ARI is the proof that survives every scenario — forced reissues, reinstall loops, and the short-lived future. The capacity plan fits on an index card, and the implementation is a cert-manager upgrade plus staging validation.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.