cloud66 · lvangool · May 20, 2026
diff --git a/security/ssl-auto-renewal.mdx b/security/ssl-auto-renewal.mdx
@@ -0,0 +1,94 @@
+---
+title: SSL auto-renewal
+products: ['rails', 'deploy']
+---
+
+## Overview
+
+Cloud 66 automatically renews Let's Encrypt certificates (both [standard and wildcard](/:product/:version?/security/ssl)) before they expire. Most of the time you don't need to do anything — but when an auto-renewal misses, knowing the schedule, the manual force-renewal trick, and the common DNS-01 failure modes lets you fix it before your cert actually lapses.
+
+This page covers:
+
+- [When auto-renewal runs](#renewal-schedule)
+- [Forcing an immediate renewal attempt](#forcing-a-renewal)
+- [DNS-01 / Cloudflare-specific failures](#dns-01--cloudflare-troubleshooting)
+
+For setup of Let's Encrypt certificates see [Adding SSL certificates](/:product/:version?/security/ssl). For HTTP-01 challenge problems see [Troubleshooting SSL certificates](/:product/:version?/security/troubleshooting-ssl).
+
+## Renewal schedule
+
+Cloud 66's renewal scheduler runs **twice a week — Mondays and Thursdays at 14:00 UTC** — and attempts to renew any certificate whose expiry is **within 30 days**.
+
+What this means in practice:
+
+- The first renewal attempt happens 30 days before expiry, on the next Monday or Thursday at 14:00 UTC.
+- If that attempt fails (e.g. transient DNS issue, upstream Let's Encrypt error), the scheduler retries on the next scheduled run.
+- With twice-weekly runs and a 30-day window, you get up to **8 attempts** before the cert actually expires — but that only helps if the underlying problem (DNS, Cloudflare proxy, account scope) is fixed in between.
+
+<Callout type="info" title="Schedule windows are UTC">
+14:00 UTC is 10:00 EDT / 07:00 PDT / 15:00 CET. If you're monitoring renewals from your dashboard, expect new audit-log entries to land in those windows.
+</Callout>
+
+## Forcing a renewal
+
+If you've fixed an upstream issue (e.g. removed a Cloudflare proxy, updated a DNS provider credential) and don't want to wait until the next Mon/Thu run, you can trigger an immediate renewal attempt:
+
+<PerProduct includes={["rails"]}>
+1. Open your application in your [Cloud 66 Dashboard](https://app.cloud66.com/)
+2. Click *Web* → *SSL Certificate* in the left-hand nav
+3. Click the existing certificate to open its configuration
+4. Make a no-op change (e.g. toggle SSL termination off and back on, or re-save the same domain list)
+5. Click *Update*
+</PerProduct>
+
+<PerProduct includes={["deploy"]}>
+1. Open your application in your [Cloud 66 Dashboard](https://app.cloud66.com/)
+2. Click *Application* → *SSL Certificate* in the left-hand nav
+3. Click the existing certificate to open its configuration
+4. Make a no-op change (e.g. toggle SSL termination off and back on, or re-save the same domain list)
+5. Click *Update*
+</PerProduct>
+
+Updating the certificate configuration kicks off a fresh renewal attempt outside the scheduled window. Watch the timeline for the outcome.
+
+<Callout type="warning" title="Let's Encrypt rate limits still apply">
+Let's Encrypt enforces [rate limits](https://letsencrypt.org/docs/rate-limits/) per registered domain. Avoid repeated force-renewals on the same domain in a short window; you can be locked out of issuance for up to a week.
+</Callout>
+
+## DNS-01 / Cloudflare troubleshooting
+
+[Wildcard certificates](/:product/:version?/security/ssl#wildcard-certificates) use the DNS-01 challenge — Let's Encrypt asks Cloud 66 to add a TXT record to your domain via the [DNS provider](/:product/:version?/security/dns-providers) you registered. The most common failures aren't with Cloud 66 or Let's Encrypt; they're at the DNS provider side.
+
+### Cloudflare proxy is enabled on the domain
+
+If the domain whose TXT record is being verified is **proxied** (the orange cloud is on in Cloudflare's DNS panel), the TXT record will still resolve from public DNS, but some Cloudflare configurations can intercept or delay propagation. For DNS-01 specifically, the proxy setting doesn't directly block TXT lookups, but a misconfigured Cloudflare account can.
+
+If renewals are failing only on Cloudflare-managed domains, check:
+
+1. The Cloudflare API token you registered with Cloud 66 has both **Zone:Read** and **DNS:Edit** permissions on the relevant zone.
+2. The token's **Zone Resources** scope includes the specific zone — a token scoped to a different zone will fail silently with a permission error.
+3. The token has not expired.
+
+### CNAME flattening
+
+Cloudflare's [CNAME flattening](https://developers.cloudflare.com/dns/cname-flattening/) on the apex of your zone can interact poorly with DNS-01 if the challenge record is placed somewhere that resolves through a flattened CNAME. The fix is to keep the `_acme-challenge.<domain>` record on a non-flattened name (this is the default for sub-domains; only the zone apex flattens).
+
+### Account / zone scope mismatch
+
+If you have multiple Cloudflare accounts (e.g. one personal, one corporate), make sure the API token you registered with Cloud 66 belongs to the account that owns the zone for the domain on the certificate. A token from another account will not find the zone and the challenge add will fail.
+
+### Verifying the TXT record manually
+
+To check whether the challenge record was actually created during the last renewal attempt, query DNS directly from your local machine:
+
+```bash
+dig +short TXT _acme-challenge.<your-domain>
+```
+
+If the record is missing during a renewal window, the failure is on the DNS provider side. If the record is present but renewal still fails, it's a propagation timing issue (Let's Encrypt queried before the record was visible) and the next scheduled run will likely succeed.
+
+## Related
+
+- [Adding SSL certificates to apps](/:product/:version?/security/ssl)
+- [Troubleshooting SSL certificates](/:product/:version?/security/troubleshooting-ssl) — HTTP-01 challenge problems
+- [DNS providers](/:product/:version?/security/dns-providers) — registering Cloudflare and other providers
diff --git a/security/ssl.mdx b/security/ssl.mdx
@@ -50,7 +50,7 @@ Cloud 66 will now attempt to add a standard certificate based on your configurat
 **Cloudflare** users need to [add a Page Rule](/:product/:version?/security/troubleshooting-ssl#configuring-let-s-encrypt-with-cloudflare) to their Cloudflare configuration in order for the process described above to work.  If you run into any other problems, consult our [troubleshooting doc](/:product/:version?/security/troubleshooting-ssl).
 
 <Callout type="warning" title="Certificates require updates every 3 months">
-Let's Encrypt needs to be updated every 3 months, so you should keep this configuration in place to allow for automatic renewal. 
+Let's Encrypt needs to be updated every 3 months, so you should keep this configuration in place to allow for automatic renewal. For details on when auto-renewal runs and how to force a renewal manually, see [SSL auto-renewal](/:product/:version?/security/ssl-auto-renewal).
 </Callout>
 
 #### How standard certificates work
@@ -184,7 +184,7 @@ To set up your application:
 The challenge should now succeed. If it does not, read the rest of this guide. 
 
 <Callout type="warning" title="Let's Encrypt certs require updates every 3 months">
-Let's Encrypt needs to be updated every 3 months, so you should keep all configurations in place to allow for automatic renewal. 
+Let's Encrypt needs to be updated every 3 months, so you should keep all configurations in place to allow for automatic renewal. See [SSL auto-renewal](/:product/:version?/security/ssl-auto-renewal) for the renewal schedule and force-renewal procedure.
 </Callout>