When I first launched my site, I used the simplest path available.
I hosted it through Hostinger on a low cost multi year plan that was a great deal at the time. I paid about $95 for four years of hosting, and for where I was technically, it made perfect sense. Hostinger gave me an in browser site builder, and I used their tools to put the whole thing together without having to think too much about the underlying structure.
At that stage, getting the site online mattered more than doing it the “right” way.
Why I decided to move away from the old setup
Over time, the limitations of that setup became more obvious.
The site worked, but it was inconsistent. Colors, formatting, and layout choices were not as clean or unified as I wanted them to be. A browser based builder is convenient, but it also puts you inside someone else’s system and way of working. I could make things look acceptable, but it always felt a little constrained and harder to control cleanly.
The pricing also stopped making sense.
The original hosting deal was good, but renewing it would have increased the cost significantly. On top of that, Hostinger was charging more than Cloudflare for domain related services. Once I compared the long term cost and the level of control I actually had, it became pretty clear that I should move the site elsewhere.
Why Jekyll, GitHub Pages, and Cloudflare made sense
By that point, I had just finished Linux+ and was already doing a lot of cleanup and general hygiene on my computer and workflows. I had also gotten much more comfortable working directly with systems instead of relying on simplified interfaces for everything.
That made the timing right for a rebuild.
Instead of staying inside a browser site builder, I decided to move the site to a static workflow using Jekyll and GitHub Pages, and to migrate the domain over to Cloudflare. That gave me a cheaper setup, more control, and a much better learning experience.
It also aligned better with the way I now prefer to work. I would rather manage files, templates, and structure directly than be trapped behind a proprietary visual editor.
What improved with the rebuild
The rebuilt site is not some masterpiece of HTML and CSS, and I do not need to pretend otherwise.
But it is cleaner than the old version. The layout is more consistent, the styling is easier to maintain, and the overall structure makes more sense. Just as importantly, I understand it better because I built it in a more hands on way.
That matters.
A static site workflow gives me direct control over posts, layouts, assets, and styling without depending on a third party builder to decide how everything should fit together. It is easier to version, easier to back up, easier to migrate again later if needed, and easier to maintain in a predictable way.
That kind of ownership is valuable even for a relatively simple personal site.
Why this project mattered beyond the website itself
One of the reasons I wanted to do this was that my technical skills are much stronger now than when I first built the site.
The original site reflected where I was at the time. This rebuild reflects where I am now. It gave me a chance to revisit an older project with better judgment, better system knowledge, and more confidence working in a real file based environment.
It also pushed me into adjacent areas of computing that are not strictly cybersecurity, but still matter.
Web design, static site generation, DNS, hosting decisions, file organization, version control, and deployment workflows are not the center of my career, but they sit close enough to security that understanding them is useful. In security, context matters. The more you understand how systems are built, hosted, and maintained, the easier it is to reason about how they fail, how they are exposed, and how they should be protected.
That broader computing context is worth building.
Why I prefer this setup now
What I like most about the current setup is that it is simple, consistent, and mine.
I am not locked into a browser builder. I am not paying inflated renewal costs just to keep a basic site online. I have control over the files, the structure, and the deployment model. If I want to change something, I can go make the change directly instead of fighting a visual editor.
That alone makes the rebuild worthwhile.
It is also just a better fit for how I think now. I prefer systems that are understandable, portable, and not full of unnecessary abstraction. Jekyll and GitHub Pages are not glamorous, but they are practical and transparent.
Final thoughts
Rebuilding the site with Jekyll was a good move technically, financially, and professionally.
It lowered long term cost, improved consistency, and gave me more control over my own platform. More importantly, it reflected a broader shift in how I approach computing now. I am more comfortable working directly with the underlying system, and I would rather build something maintainable than depend on a tool that hides too much from me.
The result is a cleaner site, a better workflow, and a project that taught me a lot more than the old setup ever could.