Cloudflare Pages
Cloudflare Pages is the service that takes a website's built files and publishes them to Cloudflare's global network, running the deploy automatically each time the code changes.
Cloudflare Pages is the piece of Cloudflare that takes a website’s finished files and publishes them to the network so visitors can reach them. When I make a change to a site, that change goes through a deploy: the code is built into final pages, and Pages pushes those pages out to every the edge location at once.
It is aimed specifically at static sites, sites built as files ahead of time rather than generated on the fly for each visitor. That fits how I build, because a static site is fast, has nothing running that can be broken into, and is simple to reason about.
Where a page needs to do more than serve a file, such as handle a form, that work is handled separately by Cloudflare Workers, which run alongside the pages Cloudflare Pages serves.
Why it matters to you
Publishing a website used to mean either a manual file upload or an admin panel that any visitor’s browser could also reach, which is exactly the kind of thing that gets guessed into or exploited. Cloudflare Pages removes both. There is no login screen for the public site itself to attack, because there is no server-side application running behind it, just files.
It also means every change is tracked and reversible, because the deploy history is kept. If a change ever looks wrong once it is live, going back to the previous version is quick rather than a rebuild from scratch.
How I set it up
The site’s code lives in a GitHub repository, tracked with version control, so every change has a record. That repository is connected to Cloudflare Pages, so whenever I push a change, Pages builds the site and publishes the result automatically. I do not log in and manually deploy files, and there is no separate hosting account to manage outside the one that already holds the domain and DNS.
For a change I want to check before it goes live to real visitors, I use a preview deployment, a temporary version of the site built from the same change, reachable only by a link I can share, before it becomes the live site.
What it looks like in practice
For the business owner, this is invisible in the best way. A change gets made, and a few minutes later it is live, without a file transfer, a password to a hosting panel, or a call to a developer to “push it live.” Behind that simplicity is a deploy pipeline that builds the same way every time and a full history of every version that has ever been published, so nothing about the process depends on anyone remembering the right steps.
Questions I get about this
- Is Cloudflare Pages the same as my domain or my email?
- No. It only handles the site's files, the pages themselves. Your domain's DNS and any mail routing are managed separately in the same Cloudflare account, but they are different pieces working together, not one thing.
- Do I need to click anything to publish a change?
- No. Once the setup is in place, a change I make gets built and published automatically. There is no manual "upload" step and no admin panel where a wrong click could take the site offline.
- What happens to the old version of the site when a new one is published?
- It is kept. Every deploy is recorded, so if a new version ever caused a problem, the previous working one is still there and can be brought back quickly.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.