Plan Limits
Press.js Cloud enforces usage limits per workspace plan. Render, deploy, storage, collaboration, and audit capabilities are applied to the workspace that carries the plan.
Workspace creation is handled as workspace lifecycle. Every account starts with a personal workspace. New team workspaces start on a blank internal plan with zero render, storage, member, and audit capacity, then upgrade to Pro from Billing.
Plan comparison
Section titled “Plan comparison”| Limit | Free | Starter ($9/mo) | Pro ($29/mo) |
|---|---|---|---|
| Render timeout | 15s | 60s | 60s |
| Concurrent render jobs | 1 | 10 | 50 |
| External network access | — | ✓ | ✓ |
| Files per deploy commit | 50 | 200 | 500 |
| Bytes per deploy commit | 25 MB | 50 MB | 100 MB |
| Max render output size | 50 MB | 200 MB | 200 MB |
| Render jobs / month | 500 | ∞ | ∞ |
| Render time / month | 10 min | 150 min | 600 min |
| Deploy commits / month | 100 | ∞ | ∞ |
| Storage | 1 GB | 10 GB | 50 GB |
| Members per workspace | Owner only | Owner only | Up to 5 |
| Audit logs | — | — | ✓ |
Note on concurrent render jobs: The concurrency limits above are workspace-level limits — the maximum number of render jobs a workspace can run simultaneously. Actual concurrency may be lower depending on overall platform load. When the platform is under heavy load, render jobs join a shared public queue and queue wait times may increase. This ensures fair scheduling across all tenants.
Upload session limits
Section titled “Upload session limits”These limits apply when uploading artifacts through the API or CLI.
| Limit | Value |
|---|---|
| Max individual file size | 10 MB |
| Max session total bytes | 256 MB |
| Max files per session | 5,000 |
| Session TTL | 1 hour |
| Commit lock timeout | 5 minutes |
Render payload lifecycle
Section titled “Render payload lifecycle”Render job payloads (the JSON or binary data passed to a render job) are scoped to a single render job. They are available only while that job is rendering and are deleted immediately after the render succeeds or reaches a terminal failure.
What happens when you hit a limit
Section titled “What happens when you hit a limit”Hard limits (enforced synchronously)
Section titled “Hard limits (enforced synchronously)”These are enforced at request time and return an error immediately:
| Error code | Trigger |
|---|---|
upload_session_policy_limit_exceeded | Upload session exceeds file count or byte limit |
upload_blob_too_large | A single file exceeds the max blob size |
upload_session_too_large | Session exceeds max files or total bytes |
deploy_commit_policy_limit_exceeded | Deploy commit exceeds file count or byte limit |
storage_limit_exceeded | Workspace storage exceeds the plan limit |
workspace_pro_required | The workspace action requires Pro |
workspace_blank_plan_limit_exceeded | Blank workspace creation limit reached |
workspace_blank_plan_requires_pro | Blank workspace billing requires Pro |
workspace_member_limit_exceeded | Workspace member capacity reached |
Bill-period quotas (enforced atomically)
Section titled “Bill-period quotas (enforced atomically)”These are checked against accumulated usage in the current billing period:
| Error code | Trigger |
|---|---|
deploy_commit_quota_exceeded | Deploy commits exceed monthly allowance |
render_job_quota_exceeded | Render jobs exceed monthly allowance |
render_time_quota_exceeded | Render time exceeds monthly allowance |
Bill-period quotas are checked atomically at the database level — concurrent requests can’t race past the limit.
Per-request render timeout
Section titled “Per-request render timeout”When creating a render job, you can request a custom render timeout. The platform clamps it to the plan’s maxRenderTimeoutMs:
{ "deployId": "your-deploy-id", "deployVersionId": "your-version-id", "renderTimeoutMs": 30000}If the requested timeout exceeds the plan limit, the request succeeds but the timeout is silently clamped to the plan maximum.