This post is part of a series: Blog Setup.
While setting up the blog I had to make a number of choices that affect the short and long term health of the blog. Deciding where and how to host the code and the static site, what tooling to add, how to structure the repository, etc.
Git Forge
Spoiler: I went with Github.
I considered many options for where to host the source code for the blog. Github is an obvious frontrunner, partially becaause I am already active on Github, but also the network effect. While I don’t promote my blog, I also like the idea that I’m not just shouting into the void with my posts, and discoverability is best where the people are.
Github hit one billion repositories on June 11, 2025, the first public forge to do so, highlighting the sheer amount of attention and usage on the platform. Most of my coding activity is still on Github (although I mirror many of my repositories to codeberg.org), so anyone stopping by my profile is more likely to find my blog.
One of my concerns while setting up the blog was the ability to quickly and easily move to a new Git host. If I want to move the blog to Gitlab or my own self hosted git forge, I don’t to have to labor to get back up and running. I plan to only dip my toes into a given platform; I will take advantage of some of the features, but will prefer external or embedded solutions for most things (sidenote: I need to find a way to keep issues out of Github.)
And so Github it is, for now.
CI/CD
I spent time planning the structure of the git repository for the blog to make it portable. I have seen a number of blogs switch platforms over the years, and the posts they write at the end of a migration have inspired some of the choices made for this blog.
For example, while this project is hosted on Github and I am using Github Actions to do things like lint the content and publish new pages, I also recreated the functionality in Concourse CI pipelines so I am not tied to a specific git platform. I could move the blog’s repository to any other remote, like Gitlab or Codeberg without breaking my CI/CD. At some point I will probably try writing the pipelines in Dagger to make them truly portable.
I also considered Woodpecker CI, which is a fork of Drone, Crow CI which felt a bit too simplistic, and Komodo. I may still integrate Komodo for GitOps like deploying on specific conditions in a PR.
Hosting
Note
I moved this blog from Netlify to Cloudflare Pages on 2026-08-02. For a simple static site like this, a Netlify deployment ended up being overkill, and had the potential to run up billing, limiting my ability to publish the site and taking it offline completely until the next billing cycle.
Netlify’s service was very easy to get started with, and I like the service. It offers a lot more than Cloudflare Pages, and this blog simply doesn’t need those “extras.” It made sense to switch to Cloudflare Pages, where I get unlimited deployments and free, simple hosting.
As of 01/24/2026, this blog is hosted on Netlify, a platform I have been looking for a reason to try. I disabled Netlify’s automated rebuilds on merges to main so I could write a deployment pipeline of my own, mainly for the experience, but also to ensure I don’t break the site when I’m trying new things. I hit Netlify’s free tier limit in 2 days because of all the pipeline failures…I mean “tests” that I ran…but the team was generous enough to refresh my credits when I reached out for support. +1 to Netlify!
Because the site is just static HTML/JS/CSS, I leave the option open to move the site’s hosting to basically anywhere. I build a production Docker image, so I could deploy a container somewhere and route the techobyte.cc domain to it, or simply copy the static files to any host that can serve files via a web server. This ensures I won’t get “stuck” with a specific host, or with a specific deployment method. I have heard of many bloggers who run their blogs off a Raspberry Pi they have in their house, and there’s really nothing stopping me from doing the same!
I also evaluated Fly, but decided they were more geared at full blown application deployments, Azure Containers, a Hetzner VPS I would have to maintain, DigitalOcean Droplets, and of course hosting it myself on a machine in my home, behind a reverse proxy.
Theme
This was a tough one… Hugo has a lot of themes. Most of them look good, some of them look great, but I had a few requirements in mind:
- Optimized for text-based posts. Most of my posts will be text-heavy, so optimizing layout for reading was an important factor.
- Simplicity, I didn’t want to use a highly customizable theme that would require a lot of configuration and tweaks.
- I am aware of my tendency to find yaks to shave, and want to focus on writing.
- Limiting myself to themes that are opinionated and rigid narrowed the selection pretty significantly.
- As generic as possible. Themes like Blowfish are amazing, but you have to go all-in to really take advantage.
- I am building this blog for the long term. The ability to switch themes/site generators is highly appealing.
- The more customization I need to do to the blog, the more I am building the site around the theme rather than the content.
- Content is front and center, no landing pages or superflous sections.
- Support RSS (this is officially supported by Hugo, but some themes handle revealing the functionality to readers better than others).
I decided to start with PaperMod as my theme. While it is kind of opinionated and has some theme-specific configurations, they seem easy enough to “rip out” if I ever want to change it later. It has a light and dark mode, and center-aligns the content for distraction-free reading. RSS setup was easy, and the icon is very obvious on pages that support it.