.coreweave.app hostname through the bundled letsencrypt-prod ClusterIssuer, the request can fail with an error like this:
coreweave.app is a single Let’s Encrypt registered domain shared by every CoreWeave customer. Let’s Encrypt allows 50 new certificates per registered domain every 168 hours, counted globally across all accounts. Every [HOSTNAME].[ORG-ID]-[CLUSTER-NAME].coreweave.app certificate on the platform draws from the same 50-certificate bucket, so another organization’s issuance consumes your headroom.
Because the bucket is shared, you can’t see the remaining quota. Your cluster shows only its own certificates and its own errors. A 429 that names the whole coreweave.app domain doesn’t mean your workloads caused it.
How the limit works
The limit is a token bucket, not a sliding window. Capacity refills at 1 certificate every 202 minutes, or about 7 per day. Theretry after timestamp in a 429 error is when one slot frees up, not when the bucket resets.
Renewals are exempt. Let’s Encrypt treats an order for the exact same set of identifiers as a renewal, and renewals don’t count against the registered-domain limit. A stable hostname therefore consumes one certificate from the shared bucket, once. Hostnames that change on every deployment, such as model-a1b2.myorg-mycluster.coreweave.app with a random suffix per rollout, are new identifier sets each time and consume a certificate on every deployment.
A separate limit applies to repeated requests for the same hostname. Let’s Encrypt issues at most 5 certificates per exact set of identifiers every 7 days, refilling 1 per 34 hours, and offers no overrides for it. Repeatedly retrying a failed request for a single hostname hits this limit rather than the shared one.
Stay under the limit
To keep your certificate issuance from exhausting the shared bucket, use the following practices:- Issue one wildcard certificate per cluster. A certificate for
*.[ORG-ID]-[CLUSTER-NAME].coreweave.appcovers every hostname in the cluster and consumes one certificate from the shared bucket, then none after that because renewals are exempt. Wildcard certificates require version 1.18.0 or later of the CoreWeave cert-manager chart, which switched the bundledClusterIssuerstoDNS01challenges. For details, see the release note. - Use the staging issuer for development and CI. The bundled
letsencrypt-stagingClusterIssuertargets the Let’s Encrypt staging environment, which has separate, much higher limits. Staging certificates aren’t trusted by browsers, so use them for automated tests and development namespaces, not for endpoints that people visit. - Keep hostnames stable across redeploys. Reuse the same hostname and TLS Secret so reissuance counts as an exempt renewal instead of a new certificate.
- Bring your own domain for high-volume issuance. Certificates for a domain you control draw from that domain’s own Let’s Encrypt quota, not the shared
coreweave.appbucket. Configure cert-manager with a DNS01 solver for your DNS provider.
Request a limit increase
Limit increases forcoreweave.app apply to the domain as a whole, so requests to Let’s Encrypt go through CoreWeave rather than individual customers. If the preceding patterns don’t fit your workload, contact support. Let’s Encrypt processes adjustment requests in weeks, not days, so plan around the current limit rather than waiting for an increase.
For the TLS issuance workflow itself, see Create a public DNS name and cert-manager.
Quotas & Rate Limits