Yangworks has run on Cloudflare Workers Static Assets since 9 June 2026 — roughly two months at the time of writing. It is one site: a trilingual handbook, a publication with four sections, a landing page, and a set of legal pages. 75 files, 1.1 MB, rebuilt from scratch on every deploy.

That is the whole basis of this review, and it is a narrow one. There is no Worker script here, no server-side rendering, no bindings, no database, no authentication, and no traffic worth calling traffic. Everything below is either something this site actually does, or a documented fact from Cloudflare that is labelled as such.

Getting it running took four lines of configuration

The entire platform-specific surface of this project is one file:

{
  "name": "yangworks",
  "compatibility_date": "2025-01-01",
  "assets": {
    "directory": "./public",
    "not_found_handling": "404-page"
  }
}

There is no Worker script and no main entry. assets.directory points at whatever the build produced; not_found_handling decides what happens on a miss. Cloudflare requires that second setting to be explicit — the documentation says the behaviour is manual to prevent accidental misconfiguration.

The build side stayed equally plain. package.json declares zero dependencies and zero devDependencies; npm run build is a Node script that empties public/ and regenerates it, and it completes in about 0.2 seconds locally. Workers Static Assets did not push any tooling into the project, which is the main thing I wanted from it.

The deployment chain is a push

The GitHub repository is connected to Workers Builds with main as the production branch, npm run build as the build command, and npx wrangler deploy as the deploy command. A merge to main rebuilds and publishes.

Author judgment: this is genuinely convenient and genuinely sharp. There is no staging gate between a merge and production, so branch protection and local verification stop being hygiene and start being the release process. On a solo project that is a fair trade; I would not describe it as safe by default.

Routing behaved as documented, including the parts that surprise people

Every route family below was requested against the live site on 7 August 2026:

/                              200
/handbook/                     200
/en/handbook/                  200
/ja/handbook/niche             200
/about                         200
/en/handbook/niche.html        307  ->  /en/handbook/niche
/en                            307  ->  /en/
/no-such-page                  404  (custom page)
/en/handbook/does-not-exist    404  (custom page)

Two things are worth pulling out. First, the .html redirect is a 307, not a 301 — that is the documented behaviour of the default html_handling mode, auto-trailing-slash, in which files are served without a trailing slash and folder indexes with one. If you are putting URLs into canonicals, sitemaps, or hreflang clusters, use the form that returns 200 rather than the form that redirects to it.

Second, the 404 is a real 404. Both an unknown root path and an unknown path inside a language subtree returned status 404 with the generated error page, rather than a styled page served as 200. That distinction is invisible in a browser and is exactly the kind of thing a static host can get wrong.

The three language subtrees needed no routing configuration at all. /handbook/, /en/handbook/, and /ja/handbook/ are just directories in the artifact.

The default response headers are opinionated

Without a _headers file, this is what the platform sends:

cache-control: public, max-age=0, must-revalidate
etag: W/"f91fb91a8cf2447d94f9b1c62ec62354"
content-encoding: br
alt-svc: h3=":443"; ma=86400

ETags and Brotli negotiation are automatic; HTTP/2 and HTTP/3 are on. But max-age=0, must-revalidate means browsers revalidate every asset on every navigation, including fingerprint-free files like styles.css. Cloudflare's edge cache absorbs most of that — cf-cache-status showed HIT on repeat requests — but the browser round-trip still happens.

Author judgment: this is a sensible default for a platform that cannot know whether your filenames are content-hashed, and a bad default for a site whose assets are stable. Cloudflare supports _headers natively in Workers Static Assets, so fixing it is a file, not a migration. I have not fixed it here yet, which is a fair criticism of this deployment rather than of the platform.

Pricing and limits

All of this is from Cloudflare's own documentation, checked 7 August 2026, not from a bill:

  • Cloudflare states that Requests to static assets are free and unlimited, and that storing assets carries no additional cost.
  • The Workers Free plan allows 100,000 requests per day. Workers Paid starts at $5 per month with 10 million requests included.
  • Static asset limits are 20,000 files per Worker version on Free and 100,000 on Paid, with a maximum individual file size of 25 MiB.
  • One trap: if you enable run_worker_first, matching requests always invoke the Worker, and once free-tier limits are exceeded those requests receive a 429 rather than falling back to serving the asset.

At 75 files this project is three orders of magnitude below the file-count ceiling, so the limits are theoretical here. This review reports no cost figure, because a site with no meaningful traffic produces no meaningful bill.

What's good

  • The configuration is small and it is in the repository. Four asset settings replace a dashboard's worth of inferred behaviour, and a reviewer can see the 404 policy in a diff.
  • It imposes nothing on the build. Any process that produces a directory works. Zero dependencies stayed zero.
  • Static assets are free and unlimited per Cloudflare's pricing page, with no egress charge — the cost model for a content site is close to trivial.
  • Sensible transport defaults. Brotli, ETags, HTTP/2 and HTTP/3 required no configuration.
  • Correct status codes. Real 404s, documented 307 normalization, no surprises between the documentation and the wire.
  • Room to grow without moving. Adding a Worker script later is a config key, not a replatform — which is the difference from a pure static host.

What's not

  • The caching default needs correcting for most sites. max-age=0, must-revalidate on every asset is conservative to a fault.
  • 307, not 301. Legacy .html URLs are normalized with a temporary redirect. It works, but if you want a permanent signal you have to arrange it yourself.
  • Push-to-production has no built-in gate. Preview URLs and non-production branch builds exist, but they are settings you must turn on, not a default workflow.
  • Documented feature gaps versus Pages are real. Cloudflare's own migration guide lists domains on off-Cloudflare nameservers as unsupported, per-environment bindings as unavailable, Custom Branch Aliases as coming soon, and Early Hints as a workaround.
  • Nothing warns you about what you forgot. www.yangworks.dev currently has no DNS record at all, because nothing in the platform prompts you to add a second hostname. That is my omission, but it illustrates the point: the deployment is checked into Git, the edge around it is not.

Who it suits

Developers and small teams shipping a static or mostly-static site from Git who want the hosting contract in version control rather than in a settings panel — documentation, publications, marketing sites, docs-plus-app combinations. It suits you especially well if you expect the project to eventually need a scheduled job, a queue, an API route, or an authenticated path, because you can add those without changing platform. If you are already inside Cloudflare for DNS, it is the path of least resistance.

Who it doesn't

Anyone whose nameservers are not on Cloudflare, since custom domains in that configuration are documented as unsupported. Teams that depend on per-environment bindings, Pages Plugins, file-based routing for functions/, or Custom Branch Aliases will find those either missing or a workaround. Organizations that need a mandatory review-and-promote pipeline should expect to build it around Workers Builds rather than receive it. And if you have a Cloudflare Pages project that works, none of this is a reason to move — Cloudflare has said Pages will continue to be supported, even while stating that new investment goes to Workers.

Alternatives, one sentence each

Author judgment, from documentation rather than side-by-side testing: Cloudflare Pages is the closest option and the honest default if you are already on it — the differences are set out in the Pages versus Workers comparison. Netlify and Vercel lead on build-pipeline ergonomics and preview workflow, at the cost of a metered build-minutes and bandwidth model. GitHub Pages remains the simplest thing that works when a project needs nothing but files. An object store behind a CDN is cheaper at scale and hands you the routing, redirect, and 404 behaviour as your own problem.

What this review does not cover

No Worker script, no SSR, no bindings, no Durable Objects, no Cron Triggers, no queues. No load testing and no traffic at a scale that would reveal anything. No preview-branch workflow, no rollbacks, no Cloudflare Access, and no multi-developer or multi-project team usage. No measured latency, uptime, or cost, and no controlled comparison against another host. Two months on one small static site is enough to review setup, routing, defaults, and deployment ergonomics — and it is not enough to review reliability.

The build and deployment contract behind this setup is documented in the deploy guide, and how the site got here is in the migration field note.