> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Why am I seeing 'too many certificates already issued for coreweave.app'?

When cert-manager requests a certificate for a `.coreweave.app` hostname through the bundled `letsencrypt-prod` `ClusterIssuer`, the request can fail with an error like this:

```text theme={"system"}
429 rateLimited: too many certificates (50) already issued for coreweave.app
in the last 168h, retry after 2026-07-31 16:00:50 UTC
```

This happens because `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](https://letsencrypt.org/docs/rate-limits/), 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. The `retry 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.app` covers 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 bundled `ClusterIssuers` to `DNS01` challenges. For details, see the [release note](/changelog/release-notes/cks-cert-manager-dns01).
* **Use the staging issuer for development and CI.** The bundled `letsencrypt-staging` `ClusterIssuer` targets the [Let's Encrypt staging environment](https://letsencrypt.org/docs/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.app` bucket. Configure cert-manager with a [DNS01 solver](https://cert-manager.io/docs/configuration/acme/dns01/) for your DNS provider.

## Request a limit increase

Limit increases for `coreweave.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](/support/contact). 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](/products/networking/ingress-service/create-public-dns-name) and [cert-manager](/products/cks/clusters/coreweave-charts/cert-manager).

<Badge stroke shape="pill" color="blue" size="md">[Quotas & Rate Limits](/support/cks/tags/quotas-rate-limits)</Badge>
