Limits & Quotas

Primcloud's default resource caps are anti-spam ceilings, not commercial ones. The defaults are the same for every account, and every legitimate customer runs comfortably inside them. If you hit one for a real reason, contact support and we'll lift it on your account. Caps exist to keep runaway automation from taking a bite out of the platform, not to gate you into a higher tier.

Resource caps#

These defaults are the same for every account, and the raise-on-request path (below) is what makes them effectively unlimited for any real use case.

Rollback history: each environment can roll back to its most recent successful builds: 3 on Standard, 10 on Pro and Team. A successful build is a release that ran a build of its own, such as a push, a manual deploy, or a redeploy. A release that reuses a kept build without rebuilding (a rollback, a secrets change, a compute change) is kept with it, and so are the release that's live and the build it runs. Failed and canceled deployments older than the oldest kept build fall outside the window too. Anything outside that window can't be rolled back to or redeployed. Your plan sets the count, and it applies to every environment you own.

Deployment history: deployments older than 90 days are removed from your history, but each environment always keeps its newest 25 deployments, whatever their age. The live release, its build and everything inside the rollback window are never removed, and a deployment whose build minutes aren't invoiced yet stays until they are.

Build minutes#

Build minutes are the minutes your app spends inside the build phase of a deployment. Each plan includes a monthly allotment: 300 minutes on Standard, 1,000 on Pro, and 3,000 on Team. Anything beyond the allotment bills as a per-minute overage at your plan's rate on your next invoice. There's no hard cutoff, so a big deploy near the end of the month won't halt mid-build. Primcloud tracks the minutes you've used and can email you as you approach the allotment (see the usage alerts in Plans).

If a single build runs longer than your plan's maximum, it's stopped and marked Build Failed. That limit is a safety valve for runaway builds, not a monthly quota. Push a smaller change, split the work across builds, or ask us to raise the ceiling on your account. A release process still running past your plan's maximum is stopped, and the deployment is marked Release Failed. A task run still going past your plan's maximum is stopped.

Log retention#

Application and access logs retain for 7 days on Standard and 30 days on Pro and Team. Build and release logs are attached to their deployment rather than that window, and are kept for one year, or until their deployment leaves your history: deployments older than 90 days go, though each environment keeps its newest 25. See Logs for how retention interacts with the different log categories.

Rate limits#

Anti-abuse throttles on specific auth and billing routes. If you hit one, the dashboard tells you exactly how long to wait. You're not locked out permanently.

The invoice payment limit runs per invoice: having two Open invoices means you can pay each one independently within its own window.

Raising a cap#

If a resource cap in the first table is standing between you and a legitimate use case, contact support with:

• Which cap you're hitting (from the Resource caps table above).
• Your current cap on that resource (defaults are above; if you've had it raised before, the current value is on your account).
• What you need it raised to: pick a realistic number, not "unlimited," so we can size the lift.

Cap lifts are handled by support and don't require a plan change. They're rare because the defaults are already high; when they do come up, we handle them promptly and the new ceiling sticks on your account.