A Few Words Upfront

Hey everyone, I’m A-Bear. In my previous “About Me” post, I touched on the inspiration behind starting this blog. As an IT pro who spends his days wrangling servers in data centers and the cloud, building a little corner of my own on the web meant that choosing the right tech stack was a fun challenge.

This post will serve as a quick, high-level overview of the final tech stack I landed on for this site. As for the nitty-gritty details of the setup, the CI/CD pipeline, and how I use AI to help with my writing, I’ll save those for a future deep-dive article.

Core Framework: Hugo

This time around, I made the call to move on from WordPress, which I was familiar with, and decided to embrace a Static Site Generator (SSG).

Why a Static Site?

For a technical blog focused on content sharing, a dynamic CMS like WordPress, while powerful, comes with the extra maintenance overhead and potential security risks of its underlying database, PHP runtime, and so on. Honestly, after a long day at work, I just want to focus on writing. I really don’t have the energy to worry about plugin updates, database backups, or fending off random attacks.

In contrast, the SSG model is much simpler:

  1. Local Authoring: We write articles in Markdown format.
  2. Local Build: You run a single command (like hugo), and the SSG converts all your Markdown files and templates into pure HTML, CSS, and JavaScript files.
  3. Deployment: You just upload these static files to any web server or object storage service.

The benefits of this approach are very practical: blazing-fast speed, excellent security (since there’s no backend code to attack), and extremely low hosting costs.

Why Hugo?

Among the many SSGs out there (like Jekyll, Next.js, and Gatsby), I ultimately settled on Hugo. The main reason is pretty simple: it’s written in Go, which makes its build speed incredibly fast. Once you have a lot of posts, the difference in build time is something you can really feel. Plus, its installation and usage are very straightforward. It’s a single binary, so you don’t have to deal with a mess of dependencies. For folks like us who are used to living in the terminal, writing directly in Markdown and using Git for version control makes the whole workflow feel smooth and solid.

Development and Note-Taking Tools

My daily workflow revolves around the following tools, each with its specific role:

  • Knowledge Management and Idea Incubation: Heptabase
    • This is my personal “digital brain.” All my initial ideas, research, and content outlines are visually organized on whiteboards here.
  • AI-Assisted Collaboration: Google Gemini Pro
    • When I need to brainstorm, find different angles for a topic, or polish a conversational draft into a more coherent piece, it serves as a pretty reliable sparring partner.
  • Editing and Code: Visual Studio Code (VS Code)
    • Once the overall structure of an article is set, I export the content to Markdown and do the final polishing and formatting in VS Code.
  • Version Control: Git / GitHub
    • All articles and site configurations are managed with Git and stored on GitHub. This is more than just a backup; it’s the starting point for my entire automation pipeline.
  • Advanced Automation: Self-hosted n8n
    • This is an open-source workflow automation tool, similar to Zapier. I use it to connect various personal automation flows, like monitoring my site’s status. This part is more of a nice-to-have; everything works perfectly fine without it.

Deployment and Hosting Platform: GitHub + Cloudflare Pages

This part of the setup is the key to how the whole thing runs at almost zero cost.

I host the blog’s source code (including all the Markdown articles) in a private repository on GitHub. Then, I connect it directly to the Cloudflare Pages service.

The beauty of this combination is that it creates a fully automated CI/CD (Continuous Integration/Continuous Deployment) pipeline:

  1. When I finish editing an article locally, I push the changes to GitHub using the git push command.
  2. Cloudflare Pages automatically detects that there’s a new commit in the repository.
  3. It then automatically pulls the latest code and runs the hugo command to build the site.
  4. Finally, it seamlessly deploys the finished static site files to Cloudflare’s global CDN network.

From the git push to the site being live with the updates, the entire process is fully automated. I don’t have to log into any server or perform any manual steps. The best part is that Cloudflare Pages not only offers a generous free tier (which is more than enough for a personal blog) but also throws in world-class CDN acceleration and basic DDoS protection for free.

Conclusion

So, to sum it up, the tech stack for this blog is a simple trio: Hugo + GitHub + Cloudflare Pages.

This setup provides an efficient, secure, and nearly zero-cost solution. More importantly, it automates all the tedious maintenance work, allowing me to get back to what matters: focusing on thinking and sharing through my writing. After all, tools are meant to serve a purpose, not the other way around, right?

I hope this brief overview can be a helpful reference for others looking to start their own technical blog.

I’ll see you next time for the hands-on deep-dive into the architecture