OPERATING

Quotas and resource limits

Cap what a project may consume in CPU, memory and disk, so one workload cannot starve the rest.

A quota is a ceiling on what something may consume — RAM, CPU, disk, monthly network, or a count of applications, databases, instances and domains. Quotas exist so one project cannot starve every other project on the same machine.

Quotas are not the same thing as your license seats. A license counts servers and decides which features exist; a quota decides how much of a server a given project may take. They are enforced by different code and answer to different people.

Three levels

A request to create something is checked against every level that sets a ceiling for it. All must pass:

Project: What this project may consume: RAM, CPU, disk, and counts of applications, databases, instances and domains.
User: The project owner’s total budget across all their projects. Stops someone routing around a project cap by opening a second project.
Server: The machine’s own capacity. By default the sum of reservations may reach 90% of its detected RAM and CPU, leaving ten percent for the host and the platform itself.

A ceiling that is not set means unlimited at that level. Global defaults fill in for a project or user with no explicit quota row of their own, so an administrator can set the house policy once instead of per project.

When a quota is checked

At admission — the moment you create an application, a database, a Linux instance, a domain, or scale up replicas. Not while things run. The refusal names the level and shows the numbers:

TEXT

Memory quota exceeded for this project: 14.0 GiB reserved + 2.0 GiB new > 15.0 GiB quota.

Two consequences of checking at admission rather than at runtime:

Lowering a quota below current usage does not kill anything. Running workloads keep running; you simply cannot add more until usage falls back under the new ceiling.
The memory and CPU counted are what containers reserve, not what they happen to be using at this instant. That is the number that matters for placement — a container that reserved 4 GiB will take 4 GiB the moment it needs them.

Raising an existing application’s memory limit is not treated as adding an application. An application sitting exactly at its count ceiling can still have its RAM raised — refusing that would be blocking growth the request never asked for.

The monthly network ceiling

Egress is capped per month, and it behaves differently from the others on purpose. Docker has no simple native egress limit, so DockBoard gates at admission: once the month’s transfer is over budget, new workload is refused on that scope.

Your running applications keep serving traffic. Only growth is blocked — a new deployment, a new application — until next month or a raised quota. Overshooting the ceiling does not take your site down, and it is not meant to.

Seeing where you stand

Every project shows its effective quota next to its reserved usage — the quota that actually applies after defaults are resolved, not just the row someone typed. quotas:view reads it and is part of the developer role; quotas:manage edits it and stays with project administrators or a custom role that was explicitly granted it.

Disk usage is reported by the file manager in bytes, against the same ceiling admission enforces.

Set the server capacity factor deliberately if you host anything else on the machine. The default leaves ten percent free — enough for the platform, not enough for a database you installed by hand alongside it.

Adding servers

One quota behaves the opposite way from the rest: how many servers a non-administrator may add. Unconfigured means zero, not unlimited — adding machines stays an administrator action until an administrator grants someone an allowance.

The inversion is the safe default. Everything else defaults to unlimited because a missing ceiling should not block work; a server, on the other hand, costs a license seat and joins your infrastructure, so it should not appear because a default was absent.