Limits & Quotas
Deployment Limits
Section titled “Deployment Limits”| Resource | Limit |
|---|---|
| Static asset bundle | No hard limit (R2) |
| API route bundle | 10 MB compressed |
| Build timeout | 10 minutes |
| Deployments retained | Last 10 per project |
Static assets are stored in Cloudflare R2 with no enforced size cap. API route bundles are deployed to Workers for Platforms and must stay within the compressed size limit.
API Route Runtime Limits
Section titled “API Route Runtime Limits”API routes run on Cloudflare Workers. The following per-request limits apply:
| Resource | Limit |
|---|---|
| CPU time per request | 30 seconds |
| Memory | 128 MB |
| Subrequests per request | 1,000 |
| Request body size | 100 MB |
These limits are inherited from the Cloudflare Workers platform. Requests that exceed CPU time or memory will be terminated.
KV Storage Limits
Section titled “KV Storage Limits”| Resource | Limit |
|---|---|
| Max value size | 128 KB |
| Max key size | 512 bytes |
| Consistency | Eventually consistent (~60s) |
KV is backed by Cloudflare KV. The platform enforces a 128 KB value size limit, which is lower than the raw Cloudflare KV limit. Writes propagate globally within approximately 60 seconds. For use cases that require strong consistency, consider using an external database.
Platform Limits
Section titled “Platform Limits”Included resources per plan (Free tier shown):
| Resource | Free Tier |
|---|---|
| D1 reads | 25 billion/month |
| D1 writes | 50 million/month |
| KV reads | 10 million/month |
| KV writes | 1 million/month |
| R2 storage | 10 GB free, then $0.015/GB |
These limits apply to internal platform operations (project metadata, deployment records, etc.) and SDK-level KV usage combined. Usage beyond the free tier is billed according to your plan.
CDN Cache Behavior
Section titled “CDN Cache Behavior”Static assets are served through Cloudflare’s CDN with the following cache rules:
| Content Type | Cache Duration |
|---|---|
| HTML files | no-cache, must-revalidate (allows caching with revalidation) |
Hashed assets (e.g., app-a1b2c3.js) | 1 year, immutable |
| Other static files | 24 hours |
HTML files are served with the no-cache, must-revalidate cache header, which allows browsers and CDN edges to store the response but requires revalidation before serving it. This ensures users always receive the latest version after a deployment while still benefiting from conditional requests (304 Not Modified). Hashed assets use content-based filenames, so they are safe to cache indefinitely. All other static files (images, fonts, etc.) are cached for 24 hours.
Scheduled Jobs
Section titled “Scheduled Jobs”Two daily cron jobs maintain the platform:
| Schedule | Job | Description |
|---|---|---|
30 0 * * * (00:30 UTC) | Analytics rollup | Aggregates raw analytics data into rollup tables |
0 3 * * * (03:00 UTC) | Deployment cleanup | Removes old deployments beyond the retention window |
Deployment Cleanup
Section titled “Deployment Cleanup”The cleanup cron removes old deployments with the following rules:
- Keeps the last 10 deployments per project.
- The active deployment is never deleted, even if it falls outside the retention window.
- Associated R2 assets and Worker scripts are cleaned up alongside the deployment record.
Deployment Lifecycle
Section titled “Deployment Lifecycle”Deployments progress through the following statuses:
queued —> building —> deploying —> active —> superseded —> cleaned —> purged
The cleaned status indicates the deployment record has been marked for removal. Once the associated R2 assets are fully deleted, the deployment transitions to purged.