Project Quotas

Each project has a quota limiting the total CPU and memory available to everything running inside it. Quotas stop a single project from consuming more than intended, and they are checked before anything is created — a deployment that would not fit is refused up front, so nothing is created, nothing is billed, and there is nothing half-deployed to clean up.

What quotas control

CPU is written in millicores — 1000m is one full core. Memory is written with a unit suffix: 512Mi and 2Gi are binary, 2G is decimal. They are not interchangeable and the console shows each figure in whichever unit expresses it exactly.

Reservations and ceilings are separate because a workload is guaranteed its reservation and allowed to burst above it, up to its ceiling. When you set a container's CPU you are choosing its reservation; its ceiling is set above that automatically so it has room to absorb a spike.

In practice the ceiling usually runs out first. That follows from ceilings being set above the reservations they belong to. A project can look half empty on reserved CPU and still refuse the next container, so when a deployment is refused, read which of the four is short before resizing.

The quota applies in each region separately

This is the part that surprises people most.

Your quota is not a total shared across regions. Each region your project runs in gets the full quota, and a deployment spanning three regions has to fit inside it three separate times.

So a project running in Falkenstein and Helsinki can be completely full in Falkenstein while Helsinki has almost everything free. When a deployment is refused the message names the region, because the fix is often to drop that region rather than to shrink the workload.

What counts towards it

Everything the project runs, not only the thing you are creating:

• containers — HTTP, worker and cron — multiplied by their replica count
• managed Memcached and Valkey, multiplied by their node count
• the proxy cache a container provisions when you switch it on
• scheduled jobs a datastore needs, such as a nightly Valkey backup
• the extra capacity a workload takes on when you attach a policy that inspects application traffic

A suspended cron job counts for nothing while it is suspended — it holds no capacity. That is also why resuming one is checked again: the capacity it released may have been taken meanwhile.

For Valkey the draw is per node, and the tier decides how many nodes an instance runs:

A sharded instance is therefore the largest single draw on a project's quota: even at its smallest configuration it runs six nodes per region. Check your headroom before deploying one alongside other workloads.

Checking your quota

In the console. Open the project. The Resource allowance panel shows a bar per limit, per region: the solid portion is what is reserved now, and the lighter portion is what would also be used if every autoscaled workload grew to its maximum at the same time.

With Terraform.

data "bahriya_project_quota" "app" {
  project = bahriya_project.app.id
}
 
output "cpu_ceiling" {
  value = data.bahriya_project_quota.app.regions[0].available.cpu_ceiling
}

The data source reports usage as well as the allowance. If you only need the allowance, the project resource carries it directly — bahriya_project.app.effectivequotarequestcpu and its three siblings, described in Deploy a Project with Terraform.

Over the API.

curl -H "Authorization: Bearer $BAHRIYA_TOKEN" \
  https://api.bahriya.cloud/console/v1/organisations/$ORG/projects/$PROJECT/quota

What happens when you hit a quota

Creating or resizing anything that would exceed the quota is refused, with a message naming the limit, the region and the shortfall:

This change needs 6600m of CPU ceiling in region falkenstein-1, but project "my-project" has only 6500m free of its 8000m ceiling. Raise a support ticket to request an increase.

Every limit that is short is listed, not just the first, so you can resize once rather than discovering memory is short after fixing CPU.

Your existing workloads keep running normally — a quota only prevents new allocations.

Your options, in the order most people want them:

1. Make the workload smaller. The message tells you how much is free. Anything at or below that figure is accepted.
2. Use fewer regions. A deployment has to fit in every region it runs in.
3. Remove something you no longer need. Terminated workloads stop counting once teardown finishes.
4. Ask for more. See below.

"It fits, but it will not scale"

Sometimes a deployment is accepted with a warning rather than refused:

This deployment fits, but project "my-project" does not have room for it to scale to its configured maximum in falkenstein-1. It will scale to 5 replicas instead.

The workload is running normally at its current size, but the maximum you configured for autoscaling cannot be reached — there is not enough room for that many copies. Nothing is broken; under heavy load it will scale up and then stop early.

The warning names the number it will actually reach so you do not have to work it out. Note that it is usually decided by the ceiling rather than the reservation, so dividing your reserved CPU by the per-replica figure gives the wrong answer.

If that maximum matters, lower it to something reachable, make each replica smaller, or ask for more headroom.

Asking for more

Quotas are set by the Bahriya team and are not self-service. Raise a support ticket from the console and include:

• the project
• the region, if only one is affected
• which limit is short, and the figures from the message
• roughly what you are trying to run

The figures in the refusal are exactly what we need, so quoting the message verbatim is enough.

Tips

• Check your headroom before creating new workloads, especially in projects with many services.
• If you are running close to the quota and expect to need more, request an increase before you need it — it avoids a refused deployment during a traffic spike.

Related

• Container resources and scaling
• Regions
• Platform limits