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

# Quotas and Limits

> How CNAP manages resource limits, provisioning speed, and API usage

CNAP uses three types of limits to protect your account, keep costs predictable, and ensure fair access for all users. For a full comparison of what each plan includes, see [plans and pricing](/pricing).

| Limit type             | What it controls                           | Example                              |
| ---------------------- | ------------------------------------------ | ------------------------------------ |
| **Resource quotas**    | How many resources you can own at once     | Max 3 machines per workspace         |
| **Concurrency limits** | How many operations can run simultaneously | Max 3 machines launching per cluster |
| **Rate limits**        | How many API calls per time window         | Cloud provider API calls per minute  |

## Resource quotas

Resource quotas cap the total number of resources you can have at any time. When you reach the limit, new creation requests are rejected until you delete an existing resource or increase your limit.

Quotas are enforced **per user**, not per workspace. If you're a member of multiple workspaces, your usage across all of them counts toward a single limit. This means creating a new workspace doesn't give you additional resources.

### Current limits

| Metric           | Free | Pro   |
| ---------------- | ---- | ----- |
| Managed clusters | 1    | 3     |
| Compute machines | 1    | 3     |
| CPU cores        | 2    | 8     |
| Memory           | 4 GB | 16 GB |

### Check your quotas

Use the API to see your current usage and limits:

```bash theme={null}
curl -H "Authorization: Bearer $CNAP_TOKEN" \
  https://api.cnap.tech/v1/quotas
```

```json theme={null}
[
  {
    "metric": "kaas/clusters",
    "type": "allocation",
    "displayName": "Managed clusters",
    "unit": "count",
    "limit": 1,
    "usage": 0,
    "remaining": 1
  },
  {
    "metric": "compute/machines",
    "type": "allocation",
    "displayName": "Compute machines",
    "unit": "count",
    "limit": 1,
    "usage": 0,
    "remaining": 1
  }
]
```

To check a specific metric:

```bash theme={null}
curl -H "Authorization: Bearer $CNAP_TOKEN" \
  https://api.cnap.tech/v1/quotas/kaas%2Fclusters
```

To include concurrency quotas (which are per-cluster), pass a `cluster_id`:

```bash theme={null}
curl -H "Authorization: Bearer $CNAP_TOKEN" \
  "https://api.cnap.tech/v1/quotas?cluster_id=YOUR_CLUSTER_ID"
```

<Info>
  Metric names contain a forward slash (for example, `compute/machines`). URL-encode the slash as `%2F` when using the single-metric endpoint.
</Info>

## Concurrency limits

Concurrency limits cap how many operations of the same type can be in progress at the same time. Unlike resource quotas (which count what you *own*), concurrency limits count what's currently *launching*.

### Machine provisioning

CNAP limits the number of machines that can be provisioning simultaneously for a single cluster. If a cluster already has machines launching, additional requests are queued and retried automatically with exponential backoff.

| Plan | Max concurrent provisions per cluster |
| ---- | ------------------------------------- |
| Free | 1                                     |
| Pro  | 3                                     |

This prevents scenarios where repeated provisioning failures (for example, a misconfigured cloud key or a region capacity issue) create a storm of requests that consume resources without producing healthy machines. Once a machine finishes launching and becomes ready, its slot opens up for the next machine in the queue.

<Note>
  Concurrency limits apply to both CNAP-managed and BYOM machines. They protect your cluster infrastructure regardless of who pays for the compute.
</Note>

### Failure backoff

If machine provisioning fails repeatedly for a cluster (for example, the provider is experiencing capacity issues), CNAP automatically backs off with increasing wait times between retries. This avoids hammering a provider that's already struggling and reduces unnecessary costs.

The backoff follows an exponential pattern: 30 seconds, then 1 minute, 2 minutes, up to a maximum of 5 minutes between retries. Backoff resets when provisioning succeeds or the instance type offering changes (for example, after a plan upgrade).

## Rate limits

CNAP rate-limits cloud provider API calls to stay within provider quotas. This is handled transparently — you don't need to configure anything. If you notice machines taking slightly longer to provision during high demand, this is the rate limiter spacing requests to avoid provider throttling.

## Bring your own cloud key (BYOM)

Machines provisioned with your own cloud provider API key ([BYOM](/compute/overview#bring-your-own-key-byom)) are **not subject to resource quotas** (machine count, CPU, memory). You pay the provider directly, so CNAP does not limit the total number of machines.

Concurrency limits and rate limits **still apply** to BYOM machines. These protect your cluster and cloud provider account from provisioning storms regardless of billing arrangement.

## Increasing your limits

There are three ways to increase your resource limits:

* **Upgrade to Pro** — higher limits for all metrics. See [plans and pricing](/billing/tiers).
* **Bring your own key** — bypass resource quotas entirely by using your own cloud provider API key.
* **Enterprise overrides** — custom per-workspace or per-user limits set by the CNAP team. Contact us if you need limits beyond what Pro offers.

<Info>
  Enterprise customers can request custom quota overrides that take precedence over plan defaults. Overrides can be scoped to a specific workspace or user. Reach out to your account team or email [support@cnap.tech](mailto:support@cnap.tech).
</Info>