cloudflare with astro

Cloudflare with Astro

Most of an Astro site is files, and files are what a CDN is for. Cloudflare serves them from wherever the visitor is, and the interesting part of the setup is the small list of things that are not files: the redirects a migration leaves behind, the headers, and any route that has to do work when it is asked rather than when it is built.

Connect Cloudflare See the setup

Cloudflare at a glance

What I do: An Astro site served from Cloudflare's edge, with redirects, headers, caching and the one or two routes that genuinely need to run on a request handled deliberately.
Typical setup: Adds 2–4 days
How it is bought: Part of a migration scope, or a Continuous development request once the site is yours
Category: Hosting

Setup

How I set up Cloudflare

An Astro site is mostly files, which is why it suits a CDN so well: there is no server to keep warm and no runtime to pay for between visits. Cloudflare serves the build from the edge, and the whole of the setup worth talking about is the short list of things that are not files.

Redirects are first, because a migration produces hundreds of them and they belong to the host rather than to the site. They are generated from one source alongside the build, in specific-before-wildcard order, and then every rule is requested rather than a sample of them. A wildcard above a specific rule is the quiet failure here: the rule still exists and nothing will ever reach it.

Then the exceptions. Any route that genuinely has to run when it is asked becomes a Worker, which is worth deciding before the build rather than discovering at deploy, because Workers do not carry the entire Node API and a route that runs locally can fail for the want of one module. And if the site publishes on a schedule, something has to trigger the rebuild: on a static host that is either automated deliberately or it is a person remembering.

How the handoff works

01
Build

Pages rendered before anyone asks
02
Rules

Redirects and headers generated with them

Key handoff
03
Upload

Assets pushed to the edge
04
Serve

Delivered from near the visitor
05
Verify

Every redirect requested, not sampled

Why this is the key handoff

Built once, served everywhere. The build produces files and a redirect list. Cloudflare serves the first from the edge and applies the second before anything else is looked up, which is why a migration's redirects belong in the host rather than in the site.

Included

What gets connected

The built site served as static assets from the edge
Redirects from the migration, in the host's own format
Security and caching headers set per path
Routes that must run per request, where any exist
A custom domain, with the apex and www agreeing

Before you add it

What to watch out for

01

Redirect order is not alphabetical, and it matters

A wildcard placed above a specific rule makes that rule unreachable, and nothing warns you: the specific address quietly lands wherever the wildcard points. After a migration this is the failure that sends the six most valuable old URLs to the home page. The list is generated in a deliberate order and then requested, not read.
02

Not everything an Astro site can do survives on a static host

Anything wanting a server at request time needs a Worker, and Workers do not offer the whole Node API. A route that works locally can fail on deploy for the want of one module, so which routes need a request is a decision made before the build, not discovered after it.
03

Scheduled work is the thing people forget

A static site publishes what it was built with, so a post dated tomorrow appears when something rebuilds. On a host without a scheduler, that something is a person. Worth deciding up front whether a daily rebuild is automated or somebody's job.

More tools

Keep exploring

All integrations Astro development Continuous development

Next step

Let me plan your next step.

Send your site

I can scope a migration. Send a brief and I will reply by email with next steps.