Cloudflare Pages Limits: Projects, Builds, and Published Versions Are Different

Cloudflare Pages Limits: Projects, Builds, and Published Versions Are Different

Cloudflare Pages documentation describes several different limits, and confusing them can produce inaccurate claims about scale. The Pages limits documentation, dated September 5, 2026, says Pages has a limit of 100 projects per account. It separately describes hosted build allowances, concurrency, custom-domain counts, and preview published versions. A number attached to one dimension should not be applied to another.

For example, build quotas count hosted build activity according to the plan and documentation; they are not automatically a per-site allowance. A project count is a different constraint. If a design uses one Pages project for each of 100 sites, it would consume the nominal 100-project allowance before considering existing, staging, or other projects. Published quotas do not reveal an individual account’s available capacity or account-specific creation restrictions.

Direct Upload is also distinct. Cloudflare’s documentation says it lets a user upload prebuilt assets to Pages and deploy them. That can avoid running the local build through Pages’ hosted Git build pipeline, but it still uses Pages projects and creates published versions. The reviewed documentation does not expressly promise that Direct Upload published versions are excluded from every monthly publication counter or rate limit. Therefore it would be inaccurate to advertise “unlimited deploys” or a precise quota exemption without current written clarification.

The same source notes that Direct Upload projects cannot later switch to Git integration without creating a new project. This is a design choice with operational consequences, not merely a different button for the same workflow. Project count, build events, publication activity, custom domains, and account eligibility should each be checked against current documentation and the selected plan.

Cloudflare’s terms also require content and its transfer to comply with applicable laws and prohibit using services to circumvent service-specific limits. Splitting accounts or disguising ownership to evade caps would conflict with this anti-circumvention requirement. The terms are not provider approval for a particular legal or gambling-related content model.

For a real design, list the number of projects, expected hosted builds, upload/publication frequency, domains per project, and existing account usage. Ask Cloudflare for written clarification where the documentation leaves Direct Upload accounting unresolved. This article summarizes dated source material; it does not assert current account capacity or authorize a publication.

Capacity planning should include a margin rather than treating the published ceiling as an entitlement. New-project restrictions, existing projects, plan-level build concurrency, and changes to documentation can affect timing. The Pages limits documentation describes a first-48-hours restriction for new accounts; whether it affects a specific account depends on that account’s circumstances. Avoid promising a launch schedule based only on a headline quota.

Cloudflare’s terms also distinguish lawful content obligations from technical capacity. Passing an upload or build does not mean the provider has approved the content or its legal basis. Likewise, compliance with a content policy would not expand a project quota. Keep technical feasibility, contractual compliance, and regulatory authorization as three separate review tracks.

Official source links: Cloudflare Pages limits; Direct Upload documentation; Cloudflare terms.

Latest Posts