Plans, Limits & Usage

Every organization is on a plan. The plan sets how much capacity the organization can use, the dashboard shows you where you stand, and the platform enforces limits only when you try to create or grow something — never by taking anything away.

Free organizations

The Free plan has no resource capacity. You can create an organization and manage its settings and members, but you cannot create projects, environments, apps, workers, databases or object-storage buckets in a Free organization. Resource-capacity overrides do not change this; the organization needs another plan.

Existing resources are preserved. You can maintain them, reduce their capacity and deploy new versions without increasing their reserved capacity. Their monthly transfer allowances are unchanged.

The destination organization’s plan applies. A Free personal organization does not restrict your permitted work in another organization on an eligible plan.

How limits work

Limits are capacity pools, tracked separately for each environment type — Development, Staging, and Production. Each pool covers six dimensions:

• CPU — the CPU reserved by your Web Applications and Background Workers, per instance, and by your Databases.
• Memory — the memory they reserve, per instance, and your Databases’ memory.
• Database storage — the storage size of your Databases.
• Object storage — capacity — the quota of your Capacity-tier Object Storage buckets.
• Object storage — HA — the quota of your High-availability-tier Object Storage buckets.
• Egress rate — the outbound network rate reserved by your apps, per instance.

What counts is what your resources declare, not what they happen to be doing right now. A Web Application scaled to three instances counts its CPU and memory limits three times; with autoscaling enabled, the maximum instance count is what’s counted, since the platform may scale you up to it. Apps that don’t set explicit CPU or memory limits count at the platform’s default size. Each Database counts 500m CPU (half a core) and 512 MiB of memory, and its storage size — 1 GB when created without one. A dimension shown as Unlimited has no cap on your plan. A PostgreSQL database with high availability turned on counts twice against CPU, memory, and database storage, since it runs two full copies.

Viewing your usage

Any organization member can view usage in the dashboard. The Usage tab appears at every level, each scoped to that object:

• Organization Settings → Usage — your current plan, and for each environment type a bar per dimension with current usage against the limit (the bar turns red when a pool is full). Environment types your plan doesn’t include show as Not available on your plan.
• Project → Settings → Usage — the same capacity pools, counted for that project only.
• Environment → Settings → Usage — the environment’s share of its type’s org-wide pool.
• Resource → Usage (apps, workers and databases) — the resource’s bandwidth this month against your organization’s allocation, plus its live CPU, memory and, for web apps, HTTP metrics.

There is no CLI command for usage; the dashboard is the place to check.

When you hit a limit

Limits are checked when you write: creating a resource or environment, scaling up, raising an app’s CPU or memory limits, or increasing a bucket quota. A change that would push a pool past its cap is rejected with a clear error naming the environment type, the dimension, the cap, and what the change would have made the total — for example, that a scale-up would exceed the production pool’s CPU. The dashboard shows the message inline; the CLI prints the same error. Over the API this is a 403 with code: "LIMIT_EXCEEDED", the dimension in limit (for example cpu_millicores), the cap in max and the would-be total in current.

Nothing partial happens: the rejected change simply doesn’t apply, and everything already running keeps running.

If your plan doesn’t include an environment type at all, creating an environment of that type is rejected with a message saying your plan provides no capacity for it.

Going over a limit never deletes anything

Enforcement is write-only. If your usage ends up above a limit — for instance, after a plan change — the platform never deletes, stops, or scales down anything you have. Existing resources keep running exactly as they are; you just can’t grow further in the affected pool until you free capacity or the limit changes.

To free capacity yourself: scale an app down, lower its CPU/memory limits, or delete resources you no longer need.

Changing your plan

Plans are managed by the platform team. The platform is invitation-only, so you already have a contact there — reach out to them to move to a different plan or discuss a limit. Per-organization adjustments to individual limits are possible on plans with resource capacity. Free organizations need another plan before they can add resources.

Paid services and outage adjustments

Capacity limits describe what you may provision; they are not an invoice or a price offer. Any paid arrangement must separately specify and agree the rates, metering, payment, and cancellation terms. Complimentary accounts do not automatically become paid accounts.

For qualifying outages affecting paid services, d2o applies prorated adjustments to the affected service charges without requiring a customer claim for an outage it identifies. Unpaid charges are reduced; amounts already paid become credits that can be refunded on request. Monthly minimums do not cancel an adjustment. Complimentary services receive no monetary adjustment.

The Outage Adjustments Policy explains eligibility, calculations, timing, and how to report a missed outage. The Terms of Service incorporate that policy and address lost revenue and other business losses. No minimum uptime percentage is promised unless expressly agreed in writing. An individually agreed written service agreement controls where it expressly conflicts, subject to applicable law.

Monthly transfer allocation

Separate from the egress rate above, your organization also has a monthly transfer allocation: a budget, in GB, for the actual public network traffic your Web Applications send and receive over the course of a calendar month. Egress rate caps how fast one instance may push data at any given moment (checked when you set it); the monthly transfer allocation caps how much data moves in total, metered hourly against real traffic rather than reserved capacity, so figures can lag by up to an hour.

What’s counted. Only public traffic counts: requests reaching your Web Applications from the internet, and the responses they send back. Traffic that never leaves the platform — an app talking to its attached database, for instance — is not counted, and Background Workers and Databases don’t take public traffic, so they never add to the total. The “Usage” tabs described above (Organization, Project, Environment, and Resource) each show a Bandwidth this month figure alongside your allocation.

Alerts. As usage climbs, your organization’s owner gets an email at 80%, 95%, and 100% (your installation’s defaults) of the monthly allocation — and of any project, environment or resource budget set for you — each threshold fires once per month. These are notifications only; nothing is affected yet.

Going over the allocation. If usage for an Organization, Project, Environment, or an individual Resource is still over its budget the next time the platform checks (about a minute later, to rule out a one-off blip), every Web Application and Background Worker covered by that budget is scaled to zero replicas, and every public Object Storage bucket covered by it is switched to private — until usage is back under budget. This is the one exception to “Going over a limit never deletes anything” above: because this dimension meters real traffic rather than declared capacity, exceeding it does stop resources. Blocked resources show it plainly, so it’s never mistaken for a crash: the dashboard shows an app or worker as Blocked and a public bucket as Private — blocked; the CLI appends “(blocked - over monthly transfer allocation)” to the status and shows the bucket as “private (blocked; public once unblocked)”. The owner gets an email when this happens, and another once everything is restored. Databases are never affected. See My app scaled to zero, or my bucket stopped serving publicly if this happens to you.

Getting back under budget. Usage resets to zero at the start of each calendar month, which lifts the block automatically. Whoever operates your platform installation can also raise or remove the allocation for your organization (or a specific project, environment, or resource) sooner — see Changing your plan.

API rate limits

Separately from plan limits, the API limits how many requests each client IP address can make. Normal dashboard and CLI use never comes close; a script can.

A request over the limit gets 429 Too Many Requests with a Retry-After header saying how many seconds to wait. Nothing else happens — no lockout — so a client that waits and slows down continues normally. A rate-limited response looks like this:

HTTP/1.1 429 Too Many Requests
retry-after: 1

rate limit exceeded

Next steps

• Organizations, Projects & Environments — environment types and where limits attach.
• Scaling & Autoscaling — instance counts and app CPU/memory limits.
• Managing Your Organization — the rest of Organization Settings.
• Troubleshooting & FAQ — what to do when a create or scale is rejected.