Plans & Quotas
Every workspace is governed by a plan that defines its quotas (how much of each resource it may use) and capability gates (which features it can access). Limits are applied per workspace, so one workspace's usage never affects another.
Everything on this page is gated by MIABI_PLAN_ENFORCEMENT, which defaults to true. Set it
false and nothing here binds: every quota check passes and every capability gate is open, whatever
plan a workspace is on.
The plan catalog
A platform admin manages plans under Admin → Plans. A fresh install is seeded with two:
| Plan | What it is |
|---|---|
| Pro | The default. Every workspace with no plan assigned lands on it. |
| Unlimited | A system plan: no limits, pinned to Miabi's own system workspace. It carries a system badge in the console and cannot be renamed, deleted, made the default, or assigned to a workspace — it grants unlimited resources and every capability, and the platform manages its one assignment itself. |
Community allows three plans in total, so you have one slot to add a plan of your own — a smaller starter tier, say, or a bespoke one for a particular team. The system plan counts toward that total like any other. An Enterprise licence raises or lifts the limit.
Adding a fourth without a licence is refused with PLAN_LIMIT_REACHED; the New plan button is
disabled once you are at the cap, and the admin page shows how many of your slots are used.
Quotas
A quota is an upper bound on a countable resource. Typical quotas include:
| Quota | Limits the number of… |
|---|---|
| Applications | Apps deployed in the workspace. |
| Databases | Provisioned database instances. |
| Domains | Custom domains attached. |
| Members | Users invited to the workspace. |
| Volumes & storage | Persistent volumes and total disk used. |
| API tokens | Active workspace-scoped tokens. |
Quotas are checked at creation time. If creating a resource would exceed a quota, Miabi rejects the request with a clear error rather than silently degrading service.
Because the check happens at creation, you never end up with a half-provisioned resource. Free up capacity (delete an unused app or database) or raise the workspace's plan, then retry.
Capability gates
Beyond raw counts, a plan can gate features. Examples include custom TLS certificates, privileged host mounts, shell access into containers, shared (NFS/CIFS) storage, connecting DNS providers, custom container labels, and GPU access (with a separate GPUs quota counting the units a workspace's running apps may hold). Advanced security capabilities such as multiple SSO providers, SAML 2.0, and SCIM provisioning are gated to higher editions. See Community vs Enterprise for the full breakdown.
When a feature is gated off, the corresponding controls are disabled in the console and the API returns a structured error explaining which capability is required. A platform admin can also override a capability for a single workspace.
Viewing usage
Open Settings → Plan & usage to see current consumption against each quota. Usage bars highlight resources approaching their limit so you can act before a creation request is rejected.
Plan your workspace layout early. Splitting workloads across multiple workspaces under an organization can keep each workspace comfortably within its quotas.
When a limit is hit
- Miabi rejects the creating request at the API boundary.
- The console surfaces the reason (which quota or capability).
- You resolve it by freeing capacity or upgrading the plan, then retry.