Hosting a static site for free on Cloudflare: Workers or Pages?Hosting a static site for free on Cloudflare: Workers or Pages?Hosting a static site for free on Cloudflare: Workers or Pages?

Putting a front-end static site on Cloudflare without paying leaves two options: Pages, and Workers with Static Assets. This note assumes the free plans and compares the two on quotas, trade-offs, and what changes once server-side code, a database or a paid plan comes in, then ends with conditions that can be checked directly.

Limits and prices are as of November 2026 per the official docs.

The scenario

The build produces a folder (for example dist/) that holds only HTML, CSS, JavaScript and images, with no code that has to run on a server. The goal: deploy automatically on every Git push, use a custom domain, and pay nothing each month.

Both products can do this. They differ in how quotas are counted, how previews are set up, what the domain has to be, and how much room there is once the site grows.

What each one is

Cloudflare Pages

Pages (external link) is Cloudflare’s dedicated site hosting product. The usual setup is to connect a GitHub or GitLab repo in the dashboard, set a build command and an output folder, and from then on every push builds and deploys automatically (Git integration (external link)). Every deployment gets its own <hash>.<project>.pages.dev URL, and every branch gets a <branch>.<project>.pages.dev alias, with no extra setup; branch aliases are lowercased and non-alphanumeric characters become hyphens, so fix/api becomes fix-api (Preview deployments (external link)).

Without Git, Direct Upload (external link) works too: drag and drop up to 1,000 files in the dashboard, or upload up to 20,000 files with Wrangler¹, each file up to 25 MiB. For server-side code, Pages Functions go in a /functions folder, and the file names decide the routes; for example, /functions/fruits/apple.js serves /fruits/apple (Functions routing (external link)).

Workers with Static Assets

Workers runs code on Cloudflare’s edge. Static Assets (external link) lets static files be uploaded and deployed together with a Worker.

Git deploys are handled by Workers Builds (external link): connect the repo and set a build command; the deploy command defaults to npx wrangler deploy (Builds configuration (external link)), and every push to the production branch builds and deploys². Workers Builds connects to Artifacts, GitHub, GitLab and Cursor Origin repos, and does not support self-hosted GitHub or GitLab; other providers (such as Bitbucket) can use an external CI/CD service (such as GitHub Actions) that deploys with Wrangler (Workers Builds Git integration (external link)).

A purely static site on Workers needs only one config file:

{
  "name": "my-site",
  "compatibility_date": "2026-11-04",
  // No "main": no Worker code runs, static files answer every request
  "assets": {
    "directory": "./dist",
    // When a path is not found, return the nearest 404.html with status 404
    "not_found_handling": "404-page"
  }
}

not_found_handling accepts "single-page-application", "404-page" or "none", and the default is "none" (Wrangler configuration (external link)). Coming from Pages, the main change is how the output folder is declared. Pages detects the 404 and single-page application (SPA) behavior by itself, while Workers needs it spelled out (migration guide (external link)):

 {
   "name": "my-site",
   "compatibility_date": "2026-11-04",
-  "pages_build_output_dir": "./dist"
+  "assets": {
+    "directory": "./dist",
+    "not_found_handling": "404-page"
+  }
 }

The two deploy flows look roughly like this:

The _headers file has the same format on both: it has to end up at the root of the output folder (for example dist/); with a framework it usually goes in public/, which the build copies there. In the file, a path goes on the first line and the headers indented below it, with up to 100 rules at up to 2,000 characters per line. It applies only to static asset responses; responses generated by Pages Functions or Worker code need their headers set in that code (Workers headers (external link), Pages headers (external link)).

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

/assets/*
  Cache-Control: public, max-age=31536000, immutable

Replace /assets/* in the example with the folder where the framework actually writes hashed file names.

Free plan comparison table

Sources for the numbers: Pages limits (external link), Pages custom domains (external link), Pages Functions pricing (external link), Workers limits (external link), Workers Builds limits (external link), Worker Previews (external link), Workers custom domains (external link) and Workers pricing (external link). Feature support comes from the migration guide’s matrix (external link).

Trade-offs and room to grow

Everything below assumes the free plans; the quota numbers are in the comparison table above.

Pages

• Advantages: preview URLs for branches and for every deployment are created automatically, with no config to write; a folder can be dragged into the dashboard and go live; when the site lives on a subdomain (such as www.example.com), the domain’s DNS can stay with another provider and point to Pages with a CNAME, while an apex domain (such as example.com) still has to be added as a Cloudflare zone with its nameservers moved to Cloudflare (Pages custom domains (external link))³; in the migration guide’s matrix (external link), external domains are the only feature that Pages supports and Workers does not, and four more (Early Hints, Branch Deploy Controls, file-based routing, Pages Plugins) are only partially supported on Workers; 404 and SPA behavior are detected automatically; dashboard users are unlimited (Pages limits (external link)).
• Disadvantages: the build allowance is counted per build, so every push counts once however short the build is; Git integration (external link) supports only GitHub and GitLab, not self-hosted instances, and other providers use Direct Upload from CI; projects created with Git integration and with Direct Upload cannot be switched to the other later (Direct Upload (external link), Git integration (external link)), though a Git-integrated project can pause automatic deployments with branch control and deploy directly with Wrangler instead (Git integration (external link)); preview URLs are public by default; “Enable access policy” limits them to members of the Cloudflare account by default, and Access policies can add other people. It covers previews only; the *.pages.dev production URL and custom domains need separate, manual Access setup per the docs’ Known issues⁴; the official docs recommend Workers for new projects (external link), and Cloudflare has said on its blog (external link) that future investment, optimizations and new features go to Workers.
• As needs grow: for an API or form handling, add Pages Functions under /functions. Their requests count toward the Workers Free daily quota and are billed the same way as Workers (Pages Functions pricing (external link)). For a database, bindings such as D1 and KV are available, but a Durable Object cannot be created inside a Pages project; it has to be deployed as a separate Worker and bound in (Pages Functions bindings (external link)). Cron Triggers, Queue consumers, Workers Logs and Logpush are not supported (migration guide (external link)). Beyond 20,000 files, the site has to move to a Pro, Business or Enterprise plan and set PAGES_WRANGLER_MAJOR_VERSION=4 in the project to get 100,000 files per site; those plans also allow more builds, 5,000 a month on Pro and 20,000 on Business (Pages limits (external link)). The Pages limits page does not say that Workers Paid raises this limit. When these features are needed, Cloudflare provides a guide for moving from Pages to Workers (external link).

{
  "version": 1,
  "include": ["/api/*"],
  "exclude": []
}

Workers with Static Assets

• Advantages: the build allowance is counted in minutes, so a site with short builds can build many times; the config lives in wrangler.jsonc and is versioned with the code; server-side code, Cron Triggers or queues can be added to the same project later without changing platforms; turning on “Protect this Worker behind Access” on the Worker’s Access tab with the scope set to “All traffic” protects every URL of the Worker from one setting, including routes, custom domains, workers.dev and preview URLs⁵; it is the approach Cloudflare recommends for new projects (external link).
• Disadvantages: a custom domain must be a Cloudflare zone (the docs require “An active Cloudflare zone”), which means the domain’s nameservers have to be managed by Cloudflare, for subdomains too (Workers custom domains (external link), migration guide (external link)); branch previews need Worker Previews set up, and preview URLs are public by default⁶; the workers.dev route and Version URLs are public when enabled (see the note below); a request with a Range header gets the full file with 200 OK instead of 206 Partial Content, which can break uses such as video playback in Safari, and the documented workaround is run_worker_first with env.ASSETS.fetch() (Static Assets billing and limitations (external link)).
• As needs grow: for an API or form handling, add main to the config and write Worker code. Requests still look for a static file first and run the code only when nothing matches. Requests that run code count toward the 100,000 per day, each request gets at most 10 ms of CPU time, and going over the daily quota returns Error 1027, with the quota reset at midnight UTC; each route can be set to bypass the Worker when over the quota (fail open) or show the 1027 error page (fail closed) (Workers limits (external link)). Databases and other services work on the free plan: D1 (external link) allows 5 million rows read and 100,000 rows written per day, with 5 GB in total, and once the daily read or write limit is reached, queries fail until the reset at 00:00 UTC; Durable Objects (external link) are limited to the SQLite backend, with 100,000 requests and 13,000 GB-s per day, 5 million rows read and 100,000 rows written per day, and 5 GB in total, and operations past a limit fail; Queues (external link) allow 10,000 operations per day. With more than 20,000 files, or more than 100,000 requests a day that run code, moving to Workers Paid (at least USD 5 per month per account) raises the file limit to 100,000 per version and removes the daily request limit (Workers pricing (external link), Workers limits (external link)).

Side by side as the site grows

Feature support comes from the migration guide (external link) and Pages Functions bindings (external link), the per-plan Pages limits from Pages limits (external link), Workers prices and log pricing from Workers pricing (external link) and Workers limits (external link), and queue prices from Queues pricing (external link).

How to choose

Pages is worth considering when:

• The site lives on a subdomain (such as www.example.com) whose DNS is not on Cloudflare, and moving the nameservers is not planned. An apex domain needs a Cloudflare zone on Pages too.
• Every branch and every deployment needs a preview URL, without writing a config file.
• The goal is to drag a folder into the dashboard and go live, with no more than 1,000 files.
• A Pages project is already running and uses nothing that only Workers has, such as Cron Triggers, Queue consumers or Workers Logs.

Workers with Static Assets is worth considering when:

• It is a new project and the domain is already on Cloudflare.
• Pushes would trigger more than 500 builds a month: Workers Builds counts minutes, so at 2 minutes per build, 3,000 minutes is about 1,500 builds.
• Cron Triggers, Queue consumers or Durable Objects are planned, or Workers Logs is needed for debugging.
• Cloudflare Access has to protect every URL of the site (including the production URL and custom domains), not only preview URLs: on Workers, turning on Access at the Worker level with “All traffic” protects the whole Worker however it is reached (Cloudflare Access on Workers (external link)); the Zero Trust free plan (external link) allows up to 50 users. Pages can do it too, but the production URL needs the generated Access application edited, and custom domains need their own Access application (Known issues (external link)).

Worth watching on both:

• The file count is close to 20,000: the free limit is the same on both, but going beyond it takes different plans: Pages needs a Pro or higher plan, and Workers needs Workers Paid (Pages limits (external link), Workers limits (external link)).
• Requests that run server-side code would exceed 100,000 per day: Pages Functions and Workers share the same quota, so switching platforms adds nothing (Pages Functions pricing (external link)).
• Choosing Workers for a site with video that has to play in Safari: Workers static assets do not return 206 Partial Content, so those paths need run_worker_first and Worker code to handle Range requests; those requests run the Worker, and on the free plan they get a 429 once the daily quota is exceeded (Static Assets billing and limitations (external link)).

Wrap-up

• A new static site on a domain that is on Cloudflare: use Workers with Static Assets. Static asset requests are just as free, code, Cron Triggers or a database can be added later without changing platforms, and it is the direction Cloudflare recommends.
• A site on a subdomain whose DNS is not on Cloudflare and will not move, or only zero-setup branch previews and drag-and-drop uploads needed: use Pages.
• Already on Pages with static files only: it can stay there, and move to Workers with the migration guide once Cron Triggers, Queue consumers or Workers Logs are needed.