# Astro on Cloudflare Workers

> The framework I'd pick for content sites that need server rendering. Static by default, server-rendered where a page needs it, and owned by Cloudflare, so Workers is its home.

- Verdict: Use when it fits
- Vendor: Astro (open source, MIT), part of Cloudflare since January 2026
- Layer: [Edge](https://cloudlesslabs.com/stack/layers/edge.md). Job: Server-rendered content sites
- Last reviewed: 20 October 2026, by Nicolas Dao (Cloudless Labs, Sydney)
- Web page: https://cloudlesslabs.com/stack/astro-on-workers/. The whole stack in one file: https://cloudlesslabs.com/stack/brief.md

For a content site that needs a little server rendering, I'd reach for Astro before Next.js. Pages are static unless they need to be dynamic, and it runs on Workers natively. Since Cloudflare bought the team behind it in January 2026, Workers is its home platform. It stays MIT-licensed, so you can still deploy it anywhere.

## Use it when

- Content sites (marketing, docs, blogs, catalogs) where most pages are static and a few must be rendered on request.
- A new site where you aren't tied to Next.js: Astro runs natively on Workers, with no translation layer.
- Fast pages by default: Astro ships no JavaScript unless a component needs it.

## Don't use it when

- A highly interactive app (a dashboard, an editor): a React SPA or Next.js fits better.
- Your team already knows Next.js well and the site needs per-request rendering: Next.js on Workers keeps them on familiar ground.

## Pricing

Free (MIT). You pay Workers pricing for the pages rendered on request; static pages are free on Cloudflare.

## Gotchas, with fixes

- **Gotcha:** Astro 6 changed how the Cloudflare adapter exposes bindings: `Astro.locals.runtime` is deprecated.
  **Fix:** Read bindings (KV, R2, secrets) through `env` instead, and check the adapter's upgrade notes when you move between major versions.

## Provisioning

Official Pulumi package · Official Terraform provider

Deployed as a Worker with its static assets: ordinary Cloudflare resources. Astro's Cloudflare adapter does the build.

## Instead, consider

- [Next.js on Cloudflare Workers (OpenNext)](https://cloudlesslabs.com/stack/nextjs-on-workers/index.md): The team knows Next.js, or the site is closer to an app than to content.
- [Cloudflare static hosting](https://cloudlesslabs.com/stack/cloudflare-static-hosting/index.md): Nothing needs rendering per request.
- [Netlify](https://cloudlesslabs.com/stack/netlify/index.md): A non-technical team that wants Astro with previews and rollback on one dashboard.

## Where it fits

- [A website, SPA or PWA](https://cloudlesslabs.com/stack/use-cases/website.md): pick 3. When some pages must be rendered on request: content sites, docs, catalogs.

## Sources

- [Astro: Cloudflare adapter](https://docs.astro.build/en/guides/integrations-guide/cloudflare/)
- [Astro is joining Cloudflare (coverage)](https://gigazine.net/gsc_news/en/20260119-cloudflare-acquires-astro/)

## Related

- [Edge](https://cloudlesslabs.com/stack/layers/edge.md): every tool in this layer, with its verdict
- [The whole stack in one file](https://cloudlesslabs.com/stack/brief.md): every use case and tool, for questions that span many
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)