Let's Encrypt's 6-Day Certificates Are GA: The Renewal Math Your PaaS's ACME Automation Needs to Survive It

Two Let's Encrypt deadlines land on the same day this is being written. As of today, July 8, 2026, the tlsclient mTLS profile is gone for good — no more renewals, full stop. And six months earlier, in January 2026, Let's Encrypt took its opt-in shortlived profile — certificates valid for 160 hours, just over six days — generally available. For a blog reader running a managed CDN, six-day certificates are a checkbox in a dashboard. For a self-hosted, git-push PaaS that issues and renews every tenant's custom-domain certificate itself, it's a different renewal cadence, a different failure surface, and — if you're not paying attention to how your renewal job schedules its work — a real collision with your DNS provider's API rate limit, not Let's Encrypt's.

That last part is the part nobody's blog post about "shorter certificates = better security" mentions, and it's the one your on-call rotation will actually notice.

The timeline: what changes and when​

The shortlived profile isn't the only clock running. Let's Encrypt has published a staged roadmap that takes every certificate — not just the opt-in short-lived ones — from 90 days down to 45 by 2028:

Two things matter about that table for a platform that terminates TLS for other people's domains. First, the "opt-in" window is where you actually have time to prepare — by the time 45-day becomes the default in 2028, you want to already have run 6-day certificates for your riskiest workload for a year. Second, the authorization-reuse column is easy to skim past and shouldn't be: it's the length of time Let's Encrypt will let you issue a new certificate for a domain without re-validating control of it. Going from 30 days to 7 hours means your renewal pipeline can no longer coast on "we proved we own this domain last month" — it's re-proving control on almost every renewal, which means every renewal now depends on your DNS-01 or HTTP-01 challenge infrastructure actually working, every single time.

The renewal math: where this actually breaks, and where it doesn't​

Here's the claim worth stress-testing: going from a 90-day (or even 45-day) renewal cadence to 6 days is "an order of magnitude more renewal traffic." That's true as a multiplier, but the interesting question for a platform operator is where the constraint actually bites — and the honest answer is not where most people assume.

Let's Encrypt's own account-level rate limit is 300 new orders per account per 3-hour window (a continuous refill of roughly one order every 36 seconds, ~2,400/day sustained). It's tempting to do the math — "10,000 tenant domains renewing every 3 days is 3,333 orders/day, comfortably under 2,400... wait, over it" — and conclude that's your wall. It mostly isn't. Let's Encrypt exempts genuine renewals (same exact identifier set, and especially ARI-coordinated ones under RFC 9773) from that New Orders per Account limit. Renewals are the traffic short-lived certificates generate, so the limit engineered to stop runaway new-domain issuance mostly doesn't apply to you.

What doesn't get a free pass is the Duplicate Certificate limit: 5 certificates per exact set of identifiers per rolling week. At a 90-day cadence you touch that ceiling only if something is badly broken — one domain renewing roughly once a quarter is nowhere near 5-in-a-week. At a 6-day cadence, a domain renews on a ~3-day cycle by design, which is already using 2-3 of that weekly budget of 5 in steady state. Add a client that retries every failed attempt without backoff — a completely normal failure mode when a DNS provider hiccups — and you can burn through the remaining budget in an afternoon, then sit locked out of reissuing for that domain until the weekly window rolls over. At 90-day certs that same retry storm was invisible noise; at 6-day certs it's an outage.

The bigger and less obvious constraint sits one layer below Let's Encrypt entirely: your own DNS provider's API. DNS-01 challenges need a TXT record created, propagated, and cleaned up — at minimum two API calls per renewal. Route 53 caps ChangeResourceRecordSets at 5 requests per second per account. Cloudflare's global API limit is 1,200 requests per 5 minutes (~4/sec sustained). Neither of those is a problem if renewals trickle out continuously across the day. They become a problem the moment your renewal job is a nightly cron sweep — the pattern that was completely fine at 90-day cadence, because even a large fleet only had a couple hundred domains due for renewal on any given night.

Run the numbers across tenant scale, comparing daily renewal volume against what a naive "renew everything in one batch window" job would need to push through your DNS provider:

Spread continuously, even a 100,000-domain fleet on 6-day certificates sits at well under 1 request per second against the DNS API — trivial. Batched into the kind of 30-minute nightly window that worked fine at 90-day cadence, that same fleet needs 37 requests/second against a provider that caps at 5. That's not a hypothetical edge case; it's the exact operational pattern ("renew everything overnight when traffic is low") that most ACME automation defaults to, because it was the right call under the old cadence. It stops being the right call well before 100,000 domains — the 10,000-domain row is already close enough (3.7 of a 5 req/sec budget) that any concurrency in the renewal client, or a second workload sharing the same DNS account, tips it over.

What actually needs to change in your ACME automation​

None of this requires new infrastructure so much as it requires retiring assumptions that were correct at 90-day cadence and quietly become wrong at 6-day cadence:

• Stop batch-scheduling renewals. Replace the nightly sweep with continuous, staggered renewal — each domain's renewal check spread across a random offset in its window — so DNS API load stays flat regardless of fleet size, instead of spiking once a day.
• Move to ARI, not a static day-count threshold. ACME Renewal Information adds a renewalInfo endpoint that returns a server-suggested renewal window per certificate — poll it and renew inside that window instead of hardcoding "renew at day 60." It's also how you get the broadest rate-limit exemption for genuine renewals. Check your ACME client's support before opting into shortlived: cert-manager, the tool most Kubernetes-based PaaS builds reach for, still doesn't have ARI support as of this writing — a feature request open since 2023.
• Add retry backoff with a hard ceiling, tied to the Duplicate Certificate budget. A renewal client that retries failures aggressively was harmless at 90-day cadence and is a self-inflicted lockout at 6-day cadence. Cap retries so a single flaky DNS propagation window can't consume your 5-per-week budget for a domain before a human notices.
• Alert on hours, not days. A renewal job silently stuck for a week was a near-miss at 90-day cadence (you had ~83 days of slack left) and an active incident at 6-day cadence (you have almost none). Monitoring thresholds built around "check weekly" need to become "check daily, alert within hours."
• Batch your DNS API calls per zone, not per domain. Route 53 and Cloudflare both support submitting multiple record changes in a single request — collapsing per-domain TXT create/delete calls into per-zone batches is the difference between the "continuous" and "batched" rows in the table above at real scale.
• Test the shortlived profile against Let's Encrypt's staging environment first. It's the same profile, same 160-hour lifetime, without spending your production rate-limit and Duplicate Certificate budget while you find the bugs in your own renewal scheduling.

The upside is real and worth naming plainly: a leaked or misissued 6-day certificate is a problem for less than a week instead of up to 90 days, and it needs no revocation-checking infrastructure at all — Baseline Requirements exempt short-lived certificates from carrying OCSP/CRL information in the first place, because the certificate expires faster than most revocation checking would even propagate. The trade is real too: your renewal pipeline goes from "quarterly maintenance task" to "load-bearing, continuously-running system," and it will find every assumption your batch-cron-shaped automation was quietly relying on.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, custom domain and TLS included. Its own ACME automation is built around continuous, ARI-aware renewal rather than a nightly batch job, because a self-hosted PaaS that owns tenant TLS doesn't get to treat certificate lifetime as someone else's infrastructure problem. Star the repo on GitHub and see how the renewal layer is built before 45-day certificates become the default.