The old state of affairs #
Static HTML with SHTML #
A long time in the past, my website was completely written by hand. Very old school, but it worked and overall it was simple. I used some shtml to pull in the header, footer, and sidebar for my pages, and could change the look and feel with ease. I probably had this setup for years, and had subsections dedicated to applications that I supported. Overall, this was one of the easiest websites to build and maintain. Uploading was either ftps or rsync over ssh. The latter handled deletion of files better, but the correct ftp agent could handle that as well.
Wordpress #
Times changed, and at some point I moved from my static website to Wordpress. In retrospect, I was never truly happy with Wordpress. It is not that Wordpress is bad, it is just that there is too much overhead, and for a blog is it really necessary? That and there is also the hassle of finding hosting. Hosting is all over the board, from cheap to super expensive. And, at the end of the day performance could take a hit no matter how much you did or did not pay. Tie in that there are so many security vulnerabilities that have come out, it is just not worth the time if you do not need to connect to a db for business reasons.
All this being said, if you are not technical, then Wordpress is the way to go. It is dead simple for people to use and to implement. I could talk about this ad nauseam, but not trying to focus on this here.
Static Site Generators #
Now, I have played off and on with different static site generators for years. At one point I moved my website off of Wordpress and then back. But, overall, once I moved to a static site generator, I have kept my site that way.
The primary reason for this, is that other than the building portion, the entire application can be hosted anywhere. There are no dependencies, it just works. This is almost like going full circle back to static HTML, but there are a few key differences. Primarily, building and changing the flow and layout is much simpler. There are plugins that can be used for grouping and changing the look and feel can be done across the entire site quickly.
One example would be pagination. This is a key feature that is provided by a Static Site Generator (SSG). Doing that by hand would be tedious to say the least. That alone is worth the extra work. You can also have them tie into other discussion systems, add tracking to pages, add adsense across the entire website. The sky is the limit, and each SSG has its own library of different features that are available. And, you don’t have to use any of them if you don’t want to.
As of now, I have landed on Hugo. Hugo is written in Go, but you don’t need to know Go to run Hugo. All you have to understand is how to read configuration files and abysmal documentation. And, to be fair, the documentation is not horrible, it is just that it leaves a few gaps.
Moving off of S3 #
I have been running Codex.org on S3 for a good long while. Back so far, that you had to have the exact name as the website for your folder or you could not host it. Guess it has been a long time. S3 is not bad, but I have been moving away from services that do not have a defined spending limit. To be fair, the most that I have ever paid for hosting and DNS has been $3 a month. Might have sneaked up to $4 at some point when I had multiple domains.
Hosting a static site on S3 has gotten dead simple. They even manage certificate rotation for you. The big trick to hosting a website on S3 is that you have to have your DNS hosted with them for it to really work properly. This is because by default, apex records are supposed to point to IP addresses. If your site is running on S3, then that is actually a number of servers that you could be hitting. In AWS you go into the console and point the apex record to the S3 service for that domain. It is cheap and it works.
So, why move? I wanted a service that had built in versioning, easy to manage, and above all, I wanted the cost to be right. As of now, with Cloudflare that is free. Yes, if you want to add additional functionality it costs, but as this blog is mainly for my own purposes, I was not too concerned.
At this point, I am using S3 with Cloudfront. I have not configured it in years, and just do not care to keep it. Also, the chance of a DDOS and bill shock always are in the back of my mind. If I could set a hard limit, that would be different, but with the state of cloud right now it is pay what you use, and there is no way to set a limit. I don’t need some $15K bill out of the blue because the wrong domain was DDOSed.
I had also spent a bunch of time updating the rules in cloudfront as well. Now that I think about it, it was a good bit of work at the time to get it setup. Just that it has been a few year. And, I am too lazy to go and configure a WAF for it, nor do I want to consider what the cost of that would be.
Setting up Cloudflare Pages #
I did not realize it before I moved over, but man, does Cloudflare have such a wide amount of features right out the door. My goal was to move because of cost and wanting to not have to spend as much time getting the configuration done. Also, I am looking at creating some additional sites for some side projects. What a better place to start than with a domain that I have been needing to address for years.
My thought was to look at different hosting providers, and maybe roll my own on a Droplet with Digital Ocean. But, I wanted analytics, something that Cloudfront seriously lacks. It may have gotten better, but the last time I looked, it was appalling. So, when I started doing some querying, I read about Cloudflare pages.
Looking back now, I cannot find the same documentation that I found originally when looking at Cloudflare. However, I have found a ton of documentation on how to configure and setup multiple SSGs and deploy the code to Cloudflare Pages. I have used Cloudflare in the past, and I think that was probably one of the primary reasons that I decided to give it a try. They also charge less for DNS and that was another item I was looking at. Merging my DNS under a single umbrella.
The hardest part about getting my website up and working on Pages, was nothing to do with Cloudflare and more to do with DNS. With AWS Route53, the location of the NS servers is not where you might expect it to be. As such, while I was updating the records I had on the hosted zone, I did not update the actual NS records. This means that it ended up taking an additional two days to get the site switched over.
But, overall, setting up the site and getting everything running was super simple. For ease of not setting up any automation, and not wanting to grant access to my Git repo, I just uploaded a folder. Also, I have moved to Codeberg. They only have integrations with Github and Gitlab. The upload was simple and easy.
Final Thoughts #
What amazed me the most was the amount of data that Cloudflare has available for you to use right out of the gate. Is it a full breakdown? no, but is it enough yes. Is it more than AWS, yes, by a long margin. The most amazing part is how much traffic appears to be coming from bots. That or AI agents scraping.
Overall, setup was easy, deployment was easy, and making updates is a snap. As of now, I don’t know of any reason that I would go back to AWS for a simple static site.