Cloudflare Workers Static Assets is here. What it means for Pages, and for you.

Cloudflare announced Workers Static Assets in early April 2025. The headline: you can now deploy a static site to Cloudflare Workers — no Pages project, no separate flow, just wrangler deploy. The longer story is more interesting and slightly less reassuring if you have existing Pages projects.

This piece is for engineers shipping on Cloudflare today. I migrated three projects during the beta — a static Astro blog, a Next.js app, and a small SaaS dashboard. Here is what changed, what still works, and what the path forward actually looks like.

What landed

Workers Static Assets adds a new field to wrangler.toml (or wrangler.jsonc):

{
  "name": "my-site",
  "assets": { "directory": "./dist" },
  "compatibility_date": "2025-04-01"
}

Then wrangler deploy ships the contents of ./dist as static assets bound to your Worker. The Worker itself can be empty (pure static site) or have logic (dynamic routes alongside static files). Both work from the same project, the same deploy.

If you do not need dynamic code, you do not need a main entrypoint at all. The platform recognises an assets-only project and just serves the files.

Why it matters

Cloudflare has been running Pages and Workers as two adjacent products since 2021. They share infrastructure but had different DX, different CLI workflows (wrangler pages deploy vs wrangler deploy), different settings dashboards, and just enough conceptual overlap to confuse anyone who hadn’t already learned the distinction.

Static Assets collapses the distinction. From the platform’s perspective, everything is now a Worker. Pages becomes a special case: a Worker without server-side code, accessed through the older deploy flow. The Workers SDK gets all the new features first (Containers, AI bindings, more flexible KV/D1 integration); Pages catches up later or doesn’t catch up at all.

Officially, Pages is not deprecated. Cloudflare has been careful with that messaging. Unofficially, Workers is now the recommended path for new projects, and the migration guide for existing Pages projects is published as part of the announcement.

What this does NOT change

Most existing Pages projects keep working. The *.pages.dev URLs, the custom domains, the deployments-on-git-push integration — all of it continues. You can ignore Static Assets for now and your Pages site will keep running.

For light static deployments (a portfolio, a docs site), there is no urgency. The differences between Pages and Workers Static Assets are mostly under the hood. Your users will not notice.

What this DOES change

For more involved projects, the calculus is different. Three concrete shifts:

1. Storage and compute live together cleanly. Previously, hooking a Pages site up to a D1 database or a KV namespace required Pages Functions (a separate JavaScript runtime within Pages) or a separate Worker that the Pages site called out to. With Static Assets, the Worker IS the project. Bindings go in the same wrangler.jsonc. The mental model is one.

2. Headers and routing are simpler. Workers Static Assets honours a _headers file the same way Pages does, but you also have full Worker-level control over response headers programmatically. The combination is more flexible than either Pages alone or a custom Worker alone.

3. The deploy command is wrangler deploy. This is small but real. Every CI pipeline that runs wrangler pages deploy needs updating eventually. The old command will keep working for now, but project-level config moves to wrangler.jsonc with the assets binding.

What the community is saying

The r/CloudFlare threads in April 2025 are quietly enthusiastic. Notable patterns:

• “Thanks, Cloudflare! My Serverless Hosting Experience” — a heavy positive thread reflecting the platform’s reputation among indie devs and small teams.
• Users with mature Pages projects are mostly staying on Pages until they have a specific reason to move. Static Assets is a “for new projects” win more than a “migrate everything tomorrow” move.
• The biggest pain point being reported is around framework integrations — Next.js, SvelteKit, Remix — where each framework needs an adapter (or OpenNext-style shim) that knows about the new deploy target. As of April 2025, the adapters mostly exist but each has rough edges.

The threads are notably less anxious than the equivalent Vercel platform-shift discussions. Cloudflare has a community that broadly trusts the engineering direction, which buys some patience during transitions.

The migration math, project by project

Static Astro / Hugo / Eleventy site, no dynamic logic: Migration is a 5-minute job. Swap wrangler.toml to use assets.directory, change wrangler pages deploy to wrangler deploy in your CI config, delete the old Pages project after you confirm the new Worker works. Worth doing because future Cloudflare features will land on Workers first.

Next.js app with server features (ISR, middleware, server actions): Migration is harder. OpenNext is the standard adapter; the path works but you will hit edge cases on incremental static regeneration and image optimisation. If the project is happy on Pages today, defer the migration until you have a feature reason to do it.

SvelteKit / Remix / SolidStart / Astro SSR: Adapter support is mostly there; check the framework’s own docs for the current state. Most teams I know are moving these by Q3 2025.

Pages Functions-heavy project: Migration is the biggest lift. Pages Functions need converting to Worker handlers, which is mechanical but tedious. The wrangler pages functions build command is the documented bridge. Plan a half-day.

What I would actually do

For a new project today, start on Workers with Static Assets from day one. The unified mental model is cleaner and you get every future platform feature first.

For an existing Pages project that works, stay on Pages until a concrete reason emerges. Reasons that count: you want to add a D1 database, you want Workers AI bindings, you want to consolidate to a single deploy pipeline. Reasons that don’t count: “the docs page now leads with Workers.” Pages will keep working through 2025 and almost certainly through 2026 in any reasonable scenario.

For our own TopInsight deployment, we will likely migrate in the next month — partly to validate the new flow, partly because we want first-class access to whatever Cloudflare ships next.

The bigger pattern

This is the third time Cloudflare has consolidated overlapping products into a single platform. Workers + KV merged with Workers Sites years ago. Pages + Functions merged into one. Now Pages and Workers themselves merge. The pattern suggests where the next consolidation will be: probably Containers folding more cleanly into the Workers runtime, and the AI Gateway becoming a first-class Worker binding.

The strategic move from Cloudflare is consistent — narrow the surface area so that anything you deploy lives in one Worker, with bindings for whatever extra capabilities you need. The competition with Vercel and AWS Lambda is shaped by exactly this: one platform vs. a constellation of services. As an engineer choosing where to deploy, you are increasingly buying into the platform philosophy more than the individual products.

For now: Static Assets is real, it is good, and it does not require you to change anything you already have working. New projects start there; old projects move when there is a reason to move.