After experimenting with some other sites, I’ve shifted the hosting for my website from AWS S3 to CloudFlare Pages.

As described in my original architecture post, this site is generated using the Hugo static site generated, which allows for cheap and efficient hosting. Previously, this hosting was done on AWS; the site was pushed to S3, and hosting was performed by AWS CloudFront. I had almost no problems with this approach; amusingly, there were multiple large-scale events over the past 8 years where large parts of Amazon and/or AWS pages were down, but my website would still be up.

However, when I launched the site for Flame Point Brewing a few weeks ago, I decided to host it on CloudFlare Pages instead of AWS. This was initially done as an experiment to get familiar with CloudFlare’s product suite. An additional benefit is that my hosting needs matched CloudFlare’s free tier (although AWS was only costing me about $18/year). However, the main benefit was a simplified CI/CD process as a result of moving to an opinionated PaaS.

As noted before, the build and deploy of this site is performed using GitLab pipelines. When I push updates to the GitLab repo, GitLab fires up a CI runner using the Docker image that I specify; this image uses Hugo to build the static content, pushes the static content to S3, then instructs CloudFront to invalidate their caches.

The result is that my build pipeline explicitly specifies the following:

  • a docker build environment, including the version of Hugo that I want to use;
  • credentials to talk to AWS;
  • the pipeline commands to build and publish the website;
  • AWS infrastructure to manage certs and domains.

Aside from updating the docker image, most of these were one-and-done efforts. I could hypothetically update the docker image to fetch a preconfigured and/or specified version of Hugo, at which point I wouldn’t need to update this image anymore… because at that point I would have finished building a Hugo PaaS for CloudFront.

So, I decided to use an existing PaaS. As noted on the Hugo site, there are a number of providers which support integration with Hugo. Among these is AWS Amplify, which launched a few years after I built this site. CloudFlare Pages provides an opinionated PaaS for Hugo, whereas Amplify allows sufficient expression of the pipeline in order to support Hugo. I don’t need the flexibility, so I opted for CloudFlare pages and moved all of my hosting (registration, DNS, email, etc) for this domain over to CloudFlare.