Going CMS-Free: A Secure, Affordable Static Site with Astro, GitHub, and Cloudflare Pages

When starting a blog, many people first think of a CMS such as WordPress. It lets you write from an admin screen and makes uploading images and publishing straightforward.

With the rise of generative AI, however, writing an entire blog manually through an admin screen can feel cumbersome for someone with a certain level of technical knowledge.

For a small technical blog maintained by one person, much of a CMS’s convenience may also go unused. Even then, its core and plugins still need updates, while the database and login screen still need protection.

An alternative is a static site built with Astro, stored on GitHub, and published by Cloudflare Pages. This is not an argument that a CMS is bad. It is simply what can happen when the required features are reconsidered and a smaller system turns out to be enough.

What remains without a CMS

Each part of this architecture has one role.

Astro              turns posts into static HTML
GitHub             keeps posts, source, and their history
Cloudflare Pages   builds and publishes the site
Akamai Cloud Object Storage     optionally stores article images

Posts are Markdown or MDX files. Astro converts them to HTML during the build, and Cloudflare Pages serves the result.

There is no need to run application code or query a database for every page view. After deployment, the site is mostly HTML, CSS, and images.

Why a static site can be safer

A CMS has an administration screen and a database, with an application running on the server. Those features are useful, but they also introduce more places to watch: login attempts, outdated plugins, and configuration mistakes.

A static site has no public editor and no API that visitors can use to rewrite a post. With fewer moving parts, there are fewer entry points to attack.

Of course, a static site is not automatically secure. Its major advantage is that there are fewer likely targets and the whole system is easier to understand.

Why I chose Akamai Cloud Object Storage

GitHub is convenient for managing posts, but as both the number of posts and images grows, operating everything in one repository becomes a little cumbersome.

I wanted to manage only the images separately, so I chose Akamai Cloud Object Storage for its low and predictable pricing.

Pricing models differ considerably between services. The table below estimates the monthly cost of storing 100 GB of images in a standard storage class and delivering 1 TB to the internet.

Service	Storage price and free or included allowance	Internet data transfer	Estimated monthly cost
Akamai Cloud Object Storage	250 GB included in the $5 monthly plan	Adds 1 TB to the transfer pool	About $5.00
Amazon S3 Standard	$0.023 / GB-month	First 100 GB free, then $0.09 / GB	About $83.30
Google Cloud Storage Standard	$0.020 / GiB-month; 5 GB free when eligible	100 GB free when eligible, then $0.12 / GiB	About $109.90
Azure Blob Storage Hot LRS	$0.0208 / GB-month	First 100 GB free, then $0.087 / GB	About $80.38
Cloudflare R2 Standard	$0.015 / GB-month; 10 GB free	Free	About $1.35

On price alone, Cloudflare R2 is very attractive for a small image workload. For this blog, however, I chose Akamai Cloud because the $5 plan comfortably contains both the storage and transfer I expect, making the bill easy to predict.

I previously hosted WordPress on a VPS. Moving the site to Cloudflare Pages removed that cost, so I can put the money toward Object Storage instead.

GitHub becomes the publishing interface

The Git workflow takes the place of a CMS publish button.

A post is written on a branch and pushed to GitHub. Cloudflare Pages creates a preview URL for that branch. After the rendered site has been reviewed, merging into main updates production.

This is admittedly a developer-oriented workflow, but for a one-person operation, learning the steps through git push is usually enough.

It also works well with vibe coding

We now live in a time when even non-engineers can ask AI to write code. However, when a site is left entirely to AI, it can end up as an unnecessarily elaborate SPA packed with a database. I also often see sites where database permissions are not configured correctly and internal data is exposed.

Without a technical foundation, it is easy to judge the result only by its appearance and visible features. It is worth asking whether the architecture is richer than necessary and whether a smaller design could do the job.

Removing unnecessary parts improves system security and helps create a system that can be maintained over the long term.

That said, even when a project starts small, future expansion sometimes needs to be considered. I still feel that making this judgment calls for an engineer’s eye for good design.