Notes on how a static website can be deployed with cloudfare pages.

I’m building a hobby site to learn SEO. It’s built using Jekyll just like this site.

I originally hosted the site in my Arch Linux vps, but then decided to try deploying it via Cloudfare just to learn the process.

I’ve previously deployed static sites with Github Pages and Netlify, but never Cloudfare.

Also, this doesn’t use the “git push to deploy” thingy that these kind of services usually offer. I don’t like git for these low-end technical stuff. There’s no big risk of making a mistake and then fixing it with the help of git. I backup the code for this site to a usb drive with rsync. So I just want to deploy by moving the built site folder to wherever CF is asking me to move to.

So I googled Cloudfare CDN thinking that’s what I needed, but soon realised I need Cloudfare Pages. The CDN only hosts static assets (js, css, image, video, font files etc). To deploy a full site, you need CF Pages.

So once I signed up for it (free tier), I was taken to a Dashboard where I had to first create a ‘project’ (or ‘application’).

If you have a statically built site already… I mean a folder with files that can be considered a full static site, then you deploy it right away to your project and go live immediately in their *.pages.dev domain.

You have the option to drag and drop the folder, which I think would be a mess as the site grows with many files, or the option to push the files via CLI. I chose the CLI.

I had to install some wrangler via npm first:
npm -D wrangler@latest
(install node and npm via mise first)

And then create a project (if not already created above) with:
npx wrangler pages project create <name>

It’ll ask some details about your login stuff, which will all be saved in the project root directory’s node_modules/.cache/wrangler/ folder.

You’ll obviously get stuck, and the process might change in the future. So keep the documentation open:

And finally the part we need: The command to deploy the built _site folder to CF:

npx wrangler pages deploy _site

The site will be deployed to some random subdomain in the *.pages.dev url.

Now you need to do the DNS work to make it point it to your domain.

In the CF Dashboard, in your project’s page, there’s a section called “Custom domains”.

There you’ll be asked to either buy or add a domain you own.

In my case since the site already existed, CF retrieved its DNS records from its previous host and put it with itself. (Previously my site was in a vultr vps.)

It retrieved all these records: A, AAAA, CNAME, MX, TXT. And I had set up a newsletter for that site, so that email vendor’s verification records were pulled in too.

And even before this step, I had to change the nameservers of my domain from pointing to vultr to those of Cloudfare’s.

All was good. When I visited my website to verify, it worked.

Except, it worked the wrong way.

When I digged into it with drill example.com (in Arch, dig is drill), I saw that the site was still retrieved from my vultr’s ip address. The A record resolved to that ip.

What the hell?

To verify, I logged into my arch vps and stopped removed my site’s config from nginx.conf and restarted nginx. (there’s where the site was previously hosted.)

And the site was down!

Cloudfare cache my ass.

So then I learned about a very confusing concept called “Origin Servers”. Apparently caching services like Cloudfare still need to talk to the original source from where the assets/resources are coming from.

But that sounded wrong to me. So I talked to a “I know it all” buddy (his name is Claude) and he confirmed my suspicion. You don’t need to have an origin server!

So I tried removing the A dns record from the Cloudfare DNS page. I remember something bad happened, or it didn’t allow me to, or whatever.

So frustrated, I decided to redo the whole DNS setting up thing manually from scratch.

I even went one more step back and deleted the “custom domain” I had added for my CF project.

And when I re-added it back, this time it was like magic. In just a couple of clicks the CF automatically added the main A record. And I also added the CNAME record needed for the www subdomain to work.

Once done, the site was now accessible and it didn’t need my vultr vps origin server! And the drill command pointed to the correct ip now (that of CF).

But then all else was broken:

  • The MX record needed by my domain registrar to be able to forward emails coming to hi@example.com to my personal email address
  • The email newsletter vendor’s verification records (CNAME and MX). (I even got emails from them after a few days saying something is broken.)
  • The email registrar’s TXT records for DMARC and SPF records

I added these one by one manually, and then it all worked!

So now the workflow is simple:

  • remember that the domain’s full DNS is managed by CF
  • when the static site is built, deploy to CF with the npx wrangler pages deploy _site command

This is just the beginning of the relationship with Cloudfare. I’m yet to see what else will change.

I’ll update this post with more details.

Related: Deploying a static site in OpenBSD.

Updated: