The moment a hosting bill starts to matter usually arrives with growth. Add sites, add traffic, and bandwidth and build counts become the new variables. Cloudflare Pages puts the free boundary somewhere else. Sites, seats, requests and bandwidth are set aside, and the quota table watches build counts, project numbers and single file size instead.

Building and delivery on one network

Cloudflare describes Pages as a serverless platform where a team can build an application, collaborate on it, test it and ship it. The product page sums it up as a full stack application landing directly on the Cloudflare global network once the build is done. Delivery is handled by Cloudflare s own network, and the page says the service runs on the system that carries about twenty percent of internet traffic, with enterprise reliability, security and performance as defaults, HTTP/3, QUIC, image compression and SSL included out of the box. There are three ways in: connect a code hosting platform, push a finished build through Direct Upload, or send it from a local machine with the command line tool. Static sites and full stack applications share one deployment model, and Pages Functions runs the server side code.

Build settings come from presets

Once a code host is connected, every push triggers a build and a deployment. Cloudflare keeps a preset list for common frameworks, covering React, Gatsby, Next.js with static export, Nuxt, Qwik, Remix, Svelte, SvelteKit, Vue, Angular, Docusaurus, Hugo, Jekyll, Eleventy, VitePress and Zola, and each preset carries its own build command and output directory. Success is decided by the exit code. A non zero return marks the build as failed, a zero counts as success and the output is uploaded, and even a log written to standard error does not change that verdict. The root directory defaults to the repository root, and only a monorepo holding several projects needs it set by hand. The output directory is produced by the build command, and most frameworks land on the conventional public folder.

Without a code host, Direct Upload takes an already built bundle and pushes the whole thing up, which suits teams whose build runs on their own platform or a local machine. The command line path uploads one folder at a time with a ceiling of twenty thousand files, while dragging a zip or a folder into the dashboard allows one thousand. Both cap a single file at 25 MiB. A functions directory has to travel with the command line upload, and a standalone worker script is recognised either way.

What the quota table actually watches

The free boundary is spelled out line by line. Concurrency is the easy one to grasp: the free plan runs a single build at a time, Professional runs five and Business runs twenty. Concurrency counts per account, and any build running past twenty minutes is stopped. Monthly builds come to five hundred, five thousand and twenty thousand. Custom domains count per project at one hundred, two hundred and fifty, and five hundred. On file counts a free site holds twenty thousand files, higher plans reach a hundred thousand with an environment variable switched on in the project settings, and a single asset stops at 25 MiB. Preview deployments and collaborating users are both unlimited, projects per account stop at one hundred, and Cloudflare notes that this particular limit is not raised on request.

The request layer lives in two small files

Response headers and redirect rules for static assets are handled by two plain text files that are never published as assets themselves and are only read by the platform inside the output directory. The headers file allows a hundred rules, each line capped at two thousand characters counting spaces in the name and the value, and a request that matches several rules inherits the headers from all of them. The redirects file carries one declaration per line and order matters: when several declarations name the same source path, the one placed earlier wins, and static rules should sit ahead of dynamic ones. Its capacity is two thousand static plus one hundred dynamic redirects, twenty one hundred in total, with a single declaration capped at a thousand characters. When both files match one request, redirects run before headers.

Previews, rollback and deploy hooks

Opening a merge request against the repository produces a dedicated preview link for that change, and the content keeps updating as further commits land on the branch. Each new branch gets a randomly generated hash in front of the project subdomain, forming a new preview address, and the platform also builds an alias for the branch name that rolls forward with that branch. The production domain and any custom domain attached to the project stay untouched by preview deployments. To keep those temporary copies out of search results, Cloudflare marks every preview deployment as not to be indexed by default. Rollback targets any production deployment that built successfully, and after a rollback a newer version can still be selected, while preview deployments are never a rollback target. Domains split two ways: an apex domain needs the site moved onto Cloudflare with its nameservers changed so the platform can create the records, and a subdomain only needs a CNAME record at the existing DNS provider pointing at the project subdomain.

Deploy hooks move the trigger away from a commit. Each hook has its own unique address, a single HTTP POST starts a build, and setup asks only for a hook name and the branch to build. Cloudflare warns that anyone who calls the address can start a build, so a hook should be treated as a secret and deleted and recreated if misuse is suspected. That fits sites whose content lives in an external content management system and should refresh along with it, and it also slots into a custom continuous integration flow or a scheduled rebuild.

Cloudflare Pages splits frontend hosting into three parts. Builds happen inside presets, delivery lands on the company s own global network, and the quota sits on a public table. What makes it worth a look is how much the free plan leaves open. Sites, seats, requests and bandwidth are set aside, and the numbers that need planning are monthly builds, project count and single file size. For static sites and full stack applications where traffic swings and bandwidth cost is hard to estimate, that combination keeps the uncertainty of the bill very low.