Deployment Limits
Forge builds and runs your apps on your own servers, so deploying often costs you nothing extra. The limits below are set far above normal use. They exist to catch mistakes, such as a webhook or script that deploys in a loop, not to meter how often you ship.
Limits By Plan
Section titled “Limits By Plan”| Plan | Deployments per billing period | Deployments in any rolling hour |
|---|---|---|
| Starter | 3,000 | 60 |
| Pro | 20,000 | 120 |
| Business | 60,000 | 300 |
| Agency | Unlimited | 600 |
| Enterprise | Unlimited | 1,200 |
Deployments, rollbacks and environment promotions all count. Pushes that trigger deploys from GitHub count the same as deploys you start from the dashboard or API. Forge’s own database verification deploys do not count.
A GitHub push is judged as a whole: if your workspace is under its hourly limit when the push arrives, every service that push deploys is queued, even if that takes you past the limit. The next push is then refused until older deployments fall out of the hour. The hourly limit never deploys a repository with many services only partly.
When A Limit Is Reached
Section titled “When A Limit Is Reached”- Billing period allowance. New deployments are refused with
402until the next billing period or until you upgrade. - Hourly guard. New deployments are refused with
429and a code ofDEPLOYMENT_RATE_LIMITED. The limit is a rolling hour, so you can deploy again as soon as older deployments fall out of it, usually within minutes. If you hit it without meaning to, check your GitHub webhooks, CI jobs and scripts for a loop. - Per server. Each server can have at most 10 deployments queued or running at once. Wait for some to finish before queueing more.
Apps that are already running are never stopped by these limits. GitHub pushes that are refused are skipped, not queued for later; push again or deploy from the dashboard once you are back under the limit.