Astro + Cloudflare Pages: Skip the Cloud Build

Astro and Cloudflare Pages are a natural pair. Astro builds static HTML by default, and Cloudflare serves static assets from 300+ edge locations with zero configuration. But the default deployment workflow, pushing to GitHub and waiting for Cloudflare to clone and rebuild in the cloud, often adds unnecessary time to every deploy.

I opt to skip that entirely. Here’s how.

The problem with cloud builds

Cloudflare Pages can connect to your GitHub repo and run npm run build on every push. It works, but depending on your framework, content, and more, it can build slow. Every deploy means:

1. Cloudflare clones the repo
2. Installs dependencies from scratch (or restores a cache)
3. Runs the full Astro build
4. Deploys the output

For a site like mine, the Astro build itself takes about two seconds. The cloud build overhead adds minutes on top of that. If you’re iterating quickly or fixing a typo, that wait adds up.

Local build + Wrangler deploy

Wrangler is Cloudflare’s CLI tool, and it can deploy a pre-built static directory directly to Pages without the GitHub integration. The workflow looks like this:

Astro builds a static site to dist/ and Wrangler uploads it. The deploy finishes as fast as your upload, because there’s no clone step, dependency install, or redundant build. You’re uploading the exact output you just verified locally.

The first time you run it, Wrangler will prompt you to select (or create) a Pages project. After that, it remembers. You can also pass --project-name to be explicit:

Why this matters for Astro specifically

Astro’s build output is simple: static HTML, CSS, and whatever client-side JS you’ve opted into. There’s no server runtime to configure, no edge functions to bundle (unless you’re using SSR). The dist/ directory is the entire site.

This makes local deploys reliable. What you see in astro preview is exactly what gets deployed, so there are no environment differences, build cache surprises, or “works locally but fails in CI” sessions.

Astro also builds fast. Content collections, component rendering, and image optimization all happen in a couple of seconds for a site of this size. There’s no reason to offload that to a slower cloud environment if you can avoid it.

When cloud builds still make sense

If your build takes 30 seconds locally and you’re fine waiting a few minutes for the cloud version, the convenience is worth it.

But if you’re a solo developer or a small team, and you want the fastest possible feedback loop, building locally and deploying with Wrangler is the move. You keep full control over the build, and deploys drop from minutes to seconds.

The setup

Astro’s Cloudflare adapter handles the integration:

This configures Astro to output in the format Cloudflare expects. For a fully static site, the output is just HTML files in dist/. For hybrid or SSR routes, the adapter generates the Workers script automatically.

From there, you just need Wrangler installed:

Add a deploy script to package.json if you want it one command:

Now npm run deploy builds and ships in one shot.

Code to production in seconds

Astro builds fast. Wrangler deploys fast. Skipping the cloud build removes the slowest part of the pipeline entirely. For a site like Arclight, this means going from code change to production in under ten seconds.