Plans, limits and what happens at a ceiling

Deploy Bridge plans differ by ceilings rather than by unlocking separate deployment features. The server enforces six dimensions: connected servers, projects, domains, deployments within the current period, agent-fix attempts within that period and team members. A resource-creating request reserves allowance and performs its database write inside the same transaction, preventing concurrent requests from both consuming the last available unit. When a ceiling is reached, the attempted action receives a structured limit response naming current use, maximum allowance and the next plan that raises that specific limit. Existing running applications are not stopped by that refusal.

The exact plan ceilings

Free permits 1 server, 2 projects, 1 domain, 10 deployments per month, 5 agent fixes per month and 1 member. Starter permits 3 servers, 10 projects, 5 domains, 100 deployments, 50 agent fixes and 3 members. Pro permits 10 servers, 40 projects, 25 domains, 500 deployments, 250 agent fixes and 10 members. Scale permits 50 servers, 200 projects, 100 domains, 2,000 deployments, 1,000 agent fixes and 50 members. The catalogue prices these at US$0, US$19, US$49 and US$149 per month respectively, while the live paid amount is supplied by the configured billing provider.

Persistent resources are counted directly

Server, project and domain usage is the number of records owned by the team. Deleting one reduces the corresponding count and remains possible even when a downgrade has made surplus resources read-only. Member usage combines accepted team members with pending, unexpired invitations, because an invitation reserves a seat before acceptance. Accepting an invitation converts that held seat rather than consuming a second one. These dimensions do not reset monthly. A team at the maximum cannot add another corresponding resource until one is removed, the plan changes or an authorised support override grants a higher effective tier.

Deployments use a billing window

Only application deployments count against the deployment allowance. Server provisioning is implemented as a tracked run but is excluded from this meter. Paid plans use the billing period supplied with the subscription. A free team has no paid billing period, so its monthly window is anchored to the date the team was created and advances by calendar month, clamping dates that do not exist in shorter months. Usage counts deployment records created since the current window began. A failed or cancelled application deployment still exists as a deployment record and is therefore included.

Agent proposals can be held or spent

Applied, approved and failed agent actions consume the period allowance. A proposal awaiting approval holds an attempt so another concurrent run cannot use the same remaining unit. Rejecting or abandoning the proposal releases that held attempt. The ceiling is checked before diagnosis to avoid a model call when no attempt remains, then reserved again atomically as the action is recorded. Agent limits are distinct from the runner's safety bounds of two attempts per step and six interventions per deployment. A plan can have remaining monthly allowance while one run has already reached its per-run bound.

Ceilings refuse the next action

Creating a server, project or domain at its ceiling is refused. Starting an application deployment is refused at the deployment ceiling. An exhausted agent allowance does not erase the deployment or fabricate a remediation; the runner records that the agent stopped and the failed step remains failed. Team invitation and acceptance paths also account for the member ceiling. The response uses payment-required semantics for a quota-consuming request, but it also identifies the limit in structured data so the console can present the relevant current and higher allowance. No existing resource is deleted to make room automatically.

Downgrades preserve but constrain resources

A downgrade does not delete servers, projects or domains. For each resource type, the oldest records up to the new plan ceiling remain writable and later surplus records become read-only. Deployments targeting a read-only project or server are refused before a run starts. Editing and checking surplus resources is also restricted where the relevant route enforces read-only state, while deletion remains available so the team can return below the ceiling. The set is derived from creation order rather than permanently marked. Upgrading again, or deleting another resource, restores access without a repair job or data reconstruction.

Use the limit named by the refusal

A team may be below one ceiling and blocked by another. More project capacity does not imply more domains, seats or period deployments, so the response identifies the exact dimension that prevented the operation. The suggested upgrade is the least higher tier whose catalogue raises that dimension; at Scale, the response instead states that it is the largest plan. Operational planning should also distinguish resettable deployment and agent use from persistent inventory. Deleting a deployment record is not exposed as a quota-management procedure, while removing an unused server, project or domain directly changes persistent usage.