> For the complete documentation index, see [llms.txt](https://docs.cloudeka.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cloudeka.ai/guidance-for-enterprise/service-limit/quota-and-limits.md).

# Quota And Limits

Every tenant namespace has two things allocated at setup, visible as CRDs:

* [CloudekaResourceQuota](/guidance-for-enterprise/service-limit/crds/cloudeka-resource-quota.md) (`rquota`) — how much of each product you're allowed to use.
* [CloudekaPrice](/guidance-for-enterprise/service-limit/crds/cloudeka-price.md) (`price`) — what each product costs per hour (and per month, where applicable).

Both are set up for you when your namespace is created and are **view-only** — if you need a limit raised or a price changed, contact the platform team; don't hand-edit these CRs.

## What's limited

<table><thead><tr><th width="252.16668701171875">Product</th><th width="198">Quota field</th><th>Unit</th></tr></thead><tbody><tr><td>CPU</td><td><code>cpu</code></td><td>cores (e.g. <code>"4"</code>)</td></tr><tr><td>RAM</td><td><code>ram</code></td><td>bytes (e.g. <code>"16Gi"</code>)</td></tr><tr><td>Storage</td><td><code>storage.&#x3C;class></code></td><td>per storage class, bytes (e.g. <code>storage-nvme-c1: "100Gi"</code>)</td></tr><tr><td>GPU</td><td><code>gpu.&#x3C;model></code></td><td>per GPU model, count (e.g. <code>NVIDIA-H100-80GB-HBM3: 1</code>)</td></tr><tr><td>Floating IP</td><td><code>floatingIP</code></td><td>count</td></tr><tr><td>NVAIE (NVIDIA AI Enterprise)</td><td><code>nvaie</code></td><td>count</td></tr><tr><td>Other</td><td><code>others.&#x3C;key></code></td><td>count</td></tr><tr><td><strong>Prepaid balance</strong></td><td><code>quotaBalance</code></td><td>currency units</td></tr></tbody></table>

Check your allocation and **live consumption** side by side:

```bash
kubectl get rquota -n <your-namespace> -o yaml
```

* `spec.*` — what you're allocated.
* `status.usages.*` — what you're currently consuming, recomputed from your running workloads. This updates whenever a Pod, PVC, or Floating IP is created, changes state, or is deleted.

## Billing type × charge type

Your [`CloudekaTenant`](/guidance-for-enterprise/service-limit/crds/cloudeka-tenant.md) object (`tenant`) carries two settings that change how limits are enforced:

<table data-header-hidden><thead><tr><th width="158.99993896484375"></th><th width="200"></th><th></th></tr></thead><tbody><tr><td><code>billingType</code></td><td><code>chargeType</code></td><td>Meaning</td></tr><tr><td><code>prepaid</code></td><td><code>hourly</code></td><td>You have a balance; usage draws it down hour by hour. Can go into further use only while balance allows.</td></tr><tr><td><code>prepaid</code></td><td><code>hourly_quota_fixed</code></td><td>Both your quota <strong>and</strong> balance are checked.</td></tr><tr><td><code>prepaid</code></td><td><code>fixed</code></td><td>Only quota is checked (no balance draw-down).</td></tr><tr><td><code>postpaid</code></td><td><code>hourly</code></td><td>Usage accrues as debt against your balance (billed after the fact).</td></tr><tr><td><code>postpaid</code></td><td><code>fixed</code></td><td>Only quota is checked.</td></tr></tbody></table>

```bash
kubectl get tenant -n <your-namespace>
# shows: Project, Organization, Billing, Charging, Balance, Updated At
```

If you're not sure which combination applies to you, `kubectl get tenant` shows it directly under the `Billing`/`Charging` columns.

## The 48-hour rule

Before admitting any Pod, PVC, or LoadBalancer Service, the platform doesn't just check "can you afford this resource right now" — it checks **whether your balance can cover this resource plus everything else you're already running, for the next 48 hours**:

```
(cost of everything you're running, per hour) × 48  ≤  your balance
```

This means:

* You can be rejected even if the *new* resource alone looks affordable, if your existing workloads plus the new one would exhaust your balance within 48 hours.
* Topping up your balance (see [Billing & Balance](/guidance-for-enterprise/service-limit/billing-and-balance.md)) or reducing running workloads both restore headroom.
* This is a **look-ahead check**, not the actual charge — the real charge for each hour is computed separately when that hour ends (see billing doc). A rejection here means "you don't have enough runway," not "you were overcharged."

## What happens when a limit is hit

The webhook that intercepts your `kubectl apply`/`create` rejects the request outright — the object is **never created**. You'll see the rejection message directly in your terminal or CI output.

Common causes:

* Requesting more CPU/RAM/storage/GPU than your remaining quota.
* Insufficient balance for the 48-hour look-ahead.
* Requesting a storage class or GPU model you have no quota entry for.

See [Workload Rules](/guidance-for-enterprise/service-limit/workload-rules.md) for the exact checks per resource type, and [Troubleshooting](/guidance-for-enterprise/service-limit/troubleshooting.md) for the full error-message reference.

## Requesting a quota or price change

Quota and price are seeded once at namespace creation and only change when the platform team updates them on your behalf. They push the change to your `CloudekaResourceQuota`/`CloudekaPrice` objects, which then syncs back into billing.

Reach out to your platform contact with the new limits you need; don't `kubectl edit` these objects yourself — an edit that isn't also applied on the platform side will not take effect and may be reverted.