I discovered that there is a better free host for my blog. My AWS EC2 free tier is close to expiring, hence I had to make a practical decision, keep hosting my WordPress blog in the cloud and risk new charges on my card, or I could rethink the entire setup. Since this is a personal technical blog, I did not want to keep paying for a server that mostly serves articles, images, and static page.

So I moved my WordPress environment from AWS to a hardware server hosted at home. But I don’t want public connections in any capacity coming to my home network. I had to make a change.

The idea was simple: WordPress would no longer be my public production website. Instead, it became my private development and writing environment. I use it to write, edit, preview, and manage my blog posts. After publishing or updating an article, I use a WordPress plugin called Staatic to convert the entire site into static files. Those static files are then copied into my GitHub repository once a day and pushed to GitHub Pages, where the public version of the blog is hosted for free.

This gave me a simple CI/CD-style workflow. In normal software development or DevOps, CI/CD means changes are built, tested, and delivered automatically or semi-automatically. In my case, the “change” is a new article or an edited blog post. The “build” step is Staatic converting WordPress into static HTML, CSS, JavaScript, and image files. The “delivery” step is pushing those files to GitHub, where GitHub Pages publishes the updated site.

The biggest benefit is cost control. I no longer need a cloud-hosted WordPress server running all the time just to serve blog posts. My home server is used for development, while GitHub Pages handles the public hosting.

There is also a security benefit. A normal public WordPress site exposes the login page, admin area, PHP processing, database connection, plugins, and themes to the internet. With this setup, visitors only see the static version of the site. The public website does not need WordPress, PHP, or MySQL to run.

This setup also helped me implement real infrastructure and DevOps decisions in a practical way. It touches local hosting, static site generation, GitHub version control, deployment, cost optimization, and environment separation. WordPress is my content management system, Staatic is my build tool, GitHub is my version control platform, and GitHub Pages is my deployment target.

It is not perfect. Features that depend on live WordPress, such as native comments, dynamic search, contact forms, or user login, may not work the same way after static conversion. But for a technical blog, this trade-off is acceptable.

In the future, I can improve the process by automating the daily copy and push process. For now, it is simple, free, and reliable enough for my needs.

This project reminded me that good engineering is not always about using the most expensive platform, it about doing the most efficient process that efficiently meets the need!