Platform Limits and Quotas on Vertra Cloud

Every limit on this page is enforced by the platform, not advisory. The full plan table — price, RAM, vCPU, projects and API requests — is on Plans and limits.

​

Resource Limits per Plan

Memory and vCPU come from the plan; database connections are capped at 100 per database on every plan. There is no project count cap on any plan — the real limit is the plan’s RAM: creating an app or database is refused with MEMORY_LIMIT_EXCEEDED once the plan’s RAM runs out.

​

Bandwidth Limits

Each resource’s network bandwidth is proportional to the memory allocated to it. Resources exceeding 10 GB of RAM receive bandwidth scaled at approximately 50 Mbit per 256 MB.

​

Upload Limits

​

Custom Domain Limits

Rules and per-plan numbers are in Plans and limits.

​

Storage Limits

​

Blob Storage Limits

Quota and plan gates are the same as in Plans and limits. Limits in use are reported by usage and limits, so clients don’t hardcode them.

​

Template Limits

Creating a private template needs a plan that can create custom Docker images. A template that runs an image uses one image slot per distinct image in use, never per application; a code template uses none. Only the workspace owner deploys templates. See Template errors and Plans and limits.

​

API Request Limits

These two layers only apply to requests authenticated with an API key — dashboard sessions don’t count against them. The minute window returns x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset headers; the day window returns x-quota-limit, x-quota-remaining and x-quota-reset. The daily quota resets at midnight in the America/Fortaleza (Brasília) timezone. Over either limit: 429 RATE_LIMIT_EXCEEDED (minute) or 429 DAILY_QUOTA_EXCEEDED (day), both with details: { scope, limit, used, retry_after }. See API Reference Introduction for the full three-layer model, including the fixed per-route limits (lifecycle, database reset, subdomain changes, SQL console).

​

Deploy Rate Limits

Creating an application, uploading a ZIP, deploying from GitHub (manual or push), reinstalling dependencies and changing the build command all count against one hourly budget per account. Starting, stopping and a plain restart do not count; a restart with reinstall_dependencies or force_build does. A GitHub push beyond the limit is dropped and logged in the activity history. Over the limit: 429 DEPLOY_RATE_LIMITED, with details.limit, details.window_seconds (3600) and details.retry_after. Manual rollbacks to an earlier release have a separate hourly budget per account, with the same ceiling as the table above. A rollback does not spend deploy slots, and a deploy does not spend the rollback budget. Over the limit: 429 DEPLOY_RATE_LIMITED, with details.limit, details.window_seconds and details.retry_after. See Roll Back Application to a Release.

​

Auto-Restart

Auto-restart is on by default for every application, on every plan, and is subject to crash loop detection. If a container crashes 5 times in 10 minutes, auto-restart is disabled for 24 hours. There is a 1-hour cooldown between restarts, and the container must be online for at least 60 seconds to count as stable.

​

What happens to an account without an active plan?

An account without an active plan can’t create applications or databases or publish a site; those requests are refused with PLAN_REQUIRED (403). Projects that remain offline for more than 30 days on such an account are automatically deleted, with a snapshot taken first. Notifications are sent at days 7, 23 and 27.

​

Features per Plan

Every plan includes Vertra Shield, auto-restart with crash loop detection, TLS on every database, 10 GB of storage per application, API keys with scopes, the CLI, the SDKs, the MCP server, the VS Code extension and Vertra Flow. What changes from plan to plan is resources, limits and the features in the table below.