Quotas and limits

Objective

Read this before planning capacity. A quota here is not a soft advisory number picked to look generous — the sum of every quota on the platform is asserted to fit inside what the hardware actually sells, and a change that would oversell the box fails before anything is touched.

an internal service (setQuota), an internal service, the infrastructure repository.

What a new account gets

Quota	Value	Set by
vCPU (`cores`)	4	`POST /v1/onboard`
Memory (`ram`)	8192 MiB (8 GiB)	`POST /v1/onboard`
Volume count	the block-storage service deployment default	Not set
Volume storage (GiB)	the block-storage service deployment default	Not set

Four vCPU and 8 GiB is two cd-standard-2-4, or one cd-standard-4-16 minus the memory for it — enough to prove the platform works, not enough to run something in production without asking.

Read your own, live:

cloud quota show
cloud limits show --absolute

[!warning]

Storage is not quota’d for customer accounts. The onboarding path sets the compute service’s cores and ram only — the Quota type carries no volumes or gib fields at all, because the block-storage service had no published hostname when it was written. It has one now (volume.shelfcs.com), so this is a gap that can close.

Until it does, a new project takes whatever the block-storage service’s deployment default is, which is a number nobody chose for it. Do not read “no quota” as “unlimited storage”: the pool is 1400 GiB total and shared with every instance root disk.

Raising a quota

There is no self-service quota API and no quota-increase form. Ask, and a person changes it. PUT on the compute service’s the quota API is the call, and only an operator can make it.

the compute service’s the quota API is itself the legacy quota API — it is what the vendor SDK’s quotasets package speaks and what the platform uses today. the cloud platform’s unified limits API (registered limits plus project limits, shared across the compute service, the block-storage service and the networking service) replaces it eventually. That migration has not happened, and when it does, the call above changes.

The ceiling that cannot be oversold

Every internal tenant is declared with all four numbers:

- {name: platform-team, cores: 20, ram_mib: 40960, volumes: 10, gib: 900}
- {name: data-team,     cores: 2,  ram_mib: 4096,  volumes: 8,  gib: 300}
- {name: back-team,     cores: 1,  ram_mib: 3072,  volumes: 4,  gib: 100}
- {name: front-team,    cores: 1,  ram_mib: 3072,  volumes: 4,  gib: 100}

The first task of the play that stamps them out is called “The ceilings must fit inside the offer”. It sums every tenant’s cores, ram_mib and gib and asserts the total fits inside what the catalog says the box sells. Adding a tenant, or raising an existing one, past that line fails the assert before a single resource is created.

The fix is never to raise the ceiling. It is to shrink another allocation, or to free capacity.

What the box sells

Resource	Capacity	Rule
vCPU	24	12 physical threads, CPU overcommitted at most 2×
Memory	51200 MiB (50 GiB)	Never overcommitted. 12 GiB stays with the host for the OS and the control plane
Storage	1400 GiB	Thin-provisioned, but the sum sold is capped so the pool cannot fill silently
Guest addresses	254 (`10.100.0.0/24`)	Well above what 24 vCPU can run

Memory is the real limit. CPU can be oversubscribed and is; memory cannot be, so 50 GiB is a hard ceiling on everything running at once.

What has no limit at all

Named so that their absence is deliberate, and so nobody plans around a control that does not exist:


API request rate	No rate limiting. None is configured at the ingress, and none on the authentication endpoint
Volume IOPS and throughput	Advertised, not enforced. 48 IOPS and 11 MB/s are published per volume; no the block-storage service QoS applies them. One busy volume can take the pool
Egress bandwidth	Unmetered, unbilled, unthrottled
Snapshots	No count limit, no size limit, no expiry
Instances per account	Bounded only by the vCPU and memory quota
Key pairs, tags, security groups	Deployment defaults, not chosen

The first two are defects rather than features. Both are named on the Volume types and Service endpoints pages, and neither should be relied on staying absent.

When you hit one

Symptom	Cause
`InstanceLimitExceeded` on `RunInstances`	vCPU or memory quota
`VolumeLimitExceeded` on `CreateVolume`	the block-storage service quota
`InsufficientVolumeCapacity`	The pool is full, not your quota — nothing you can change
`InsufficientInstanceCapacity`	The box has no room for that shape right now

The last two are capacity, not policy. A quota increase will not fix them, and we would rather return them than oversell and let two customers discover the same memory at once.

Go further

Account API — where the quota is set
Instance types — capacity and overcommit rules
Volume types — the storage pool
Accounts and tenancy