A blog is a blog is a blog. At least that’s what I used to think.

In reality, it isn’t quite that simple. Some people just blog and don’t care about the machinery behind it. Others see the technology powering their site as an important part of the experience. I clearly belong to the second group.

After years of more or less radio silence, I started writing regularly again last year. At the time I moved to Micro.blog and genuinely enjoyed it. But the longer I used it, the more time I found myself spending behind the scenes. I built plugins, tweaked workflows and started thinking about the platform almost as much as the writing itself.

Like every platform, Micro.blog has its limitations. Over time, I realized that I was spending more and more energy working around them and optimizing things I could not even clearly define anymore.

Almost out of nowhere, I moved everything to Bear Blog, which probably takes the exact opposite approach. Bear Blog focuses on the one thing a blog should do, just write and hit publish. No endless configuration options, almost no customization and very little temptation to tinker.

I thought that would finally free me from thinking about the technology behind my blog. For a while, it actually did. I deliberately stopped caring about the machinery and focused entirely on writing again (with some exceptions).

But eventually those intentional limitations started to bother me more and more. At the same time, I noticed some people around me started building their own CMS, while others discovered new kids on the block and migrated away from Bear Blog altogether.

What I really wanted

The question, however, was not whether I should move to yet another blogging platform. I certainly didn’t want to migrate to a third platform within twelve months. And I definitely didn’t want to build a CMS myself or return to a monster like WordPress or Kirby. I know what building and maintaining software means, and I have no desire to create another piece of legacy software that I will eventually have to maintain in my already rare spare time.

What I wanted was ownership. Not ownership in the “self-host everything” sense, but ownership of the things that actually matter … my content, my images and the design around them.

Once I looked at it that way, the problem suddenly became much simpler. I wasn’t looking for a better blogging platform. I was looking for a setup where my content remained completely independent from the platform itself. A setup where I could replace every component whenever I wanted without having to migrate my content yet again.

The solution

Five years ago my blog was powered by Yellow, a small flat-file CMS built around markdown files. All content lived in a Git repository, and together with Yellow (as a rendering-engine), was uploaded to a traditional web host. Looking back, this already solved many of the problems I found myself thinking about again.

For a moment I was tempted to simply bring that setup back to life. But before doing that, I decided to look around how people achieve this nowadays.

After evaluating a couple of options, I settled on a combination of Eleventy and Github. All content, configuration and build logic live in a Git repository. Whenever I publish a change, GitHub starts a build workflow. During that process, Eleventy generates the final static website, and a few additional automation tasks are executed, such as image conversion and optimization.

The generated files are currently hosted on Cloudflare Pages (which has a generous free tier), but that is really just an implementation detail. The same output could just as easily be deployed to GitHub Pages, Netlify, Hetzner or virtually any other web host.

The beauty is that every component is just configured and in itself replaceable. If GitHub disappeared tomorrow, I could move the repository elsewhere. If Eleventy stopped being maintained, I could switch to another static site generator. If Cloudflare changed direction, I could deploy the generated files somewhere else within minutes.

The content remains mine, independent of the tools used to publish it. That is the difference between owning a platform and owning your content.

Around this core setup, I added a few bits of automation. Images are converted to WebP during the build process. New articles are automatically published to Mastodon and Bluesky (depending on the configuration). Webmentions are sent out, and the Internet Archive and IndexNow are notified about updates.

The result is a workflow that feels surprisingly lightweight. And I don’t pay anything to run it, not a single cent. But more importantly, I don’t depend on any single vendor to keep it running.

There was just one problem left

While editing Markdown files directly in GitHub works, it is not exactly a pleasant writing experience. I wanted something that felt closer to a traditional CMS. I looked at probably all existing wrappers, but all seemed way to complex for my basic publishing workflow.

So I built a small admin interface on top of the repository, basically the smallest possible layer between me and the repository.

I ended up with more or less a purpose-built Markdown editor that sits directly on top of the Git repository. It reads posts, pages and media files from GitHub and allows me to edit everything through a browser. Every change is automatically committed to a drafts branch. Nothing is tied to a specific device and nothing can accidentally get trapped in a browser tab. I can start writing on my Mac, and finish an article on my iPhone.

Once I’m happy with the result, I just hit a button in the editor to start the merge into main, and the entire publishing pipeline described above kicks off automatically.

Bottom line

The content remains mine. The workflow remains mine. I can change virtually every aspect of the setup within minutes, everything is fully automated and still, every component can be replaced whenever necessary. Yet from a day-to-day perspective, all I have to do is write and hit publish. Which, ironically, is exactly what I was looking for when I moved to Bear Blog in the first place.

This article already spent more time in the machine room than most people probably care for. If you are interested in the even nerdier details, the complete source code and a detailed walkthrough of the architecture can be found on GitHub.