The blog I keep building instead of writing: The irony of a blog maintained mostly by tinkering with its own infrastructure.

Background and self-reflection #

I started "this" site nearly ten years ago in order to contribute to my professional brand. However, instead of writing posts - the majority of the time spent on it has been "building" and refactoring it! Of course, it's not that I couldn't get a simple static site to work - instead I just seemed to enjoy the continuous tinkering, streamlining, refactoring, smoothing, minimalization, etc...

There's a certain irony to a blog whose most active area of development is its own infrastructure. A blog is a machine for publishing words, yet I keep tuning the machine and ignoring the words. It's not a matter of procrastination - I've indulged in my fair share of that, trust me. Instead, I believe the main factors are my curiosity in exploring various tools and their potential limits, combined with some perfectionism and a taste for minimalism (less is more!).

There's also a relation to my profession as a DevOps engineer. Building, migrating, and tuning infrastructure isn't a distraction from my work, it is the work. So tinkering feels like home - competently and continuously improving the mechanics that integrate the content.

Tools & platforms that shaped the journey #

Hugo (2017-2018) - This popular SSG (static site generator) doesn't require much introduction. I remember starting off with it via a recommendation from a friend, since its framework provided a convenient entry for something I wasn't sure would evolve into a blog, portfolio, or personal site. I hosted it on some basic VPS provider.

Nothing happened in between - the blog sat idle until my neglected VPS took it offline. Fittingly, that's on-theme for this post.
Jekyll (from 2021-03) - Jekyll is also an SSG, but simpler and blog-oriented - suiting the developing shape of my site. Furthermore both its homepage and documentation strongly encourage deploying to GitHub Pages (driving us to the following platform...).
GitHub Pages (2021-03) - Another super common solution, providing an almost full end-to-end publishing experience - hosting and serving, plus building when you stick with its native SSG (Jekyll). Bring any other SSG and you'll need to pre-render the HTML yourself.
Codeberg Pages (from 2021-12) - This is the equivalent of GitHub Pages, just on Codeberg (a non-profit, community-led alternative). I made my migration to Codeberg due to GitHub's shady behavior after Microsoft's acquisition, and in parallel to my de-Googling (etc.) escapades and adoption of FLOSS alternatives.
Pandoc (from 2022-03) - An extremely versatile document conversion utility. For a plain-text, source-trackable kind of person, Markdown is a natural go-to, and Pandoc is what turns it into HTML (or PDFs, in other cases). This is "when" I started developing my own SSG script which wraps Pandoc and converts content Markdown files into HTML templates and then git pushes them to a pages repository (for publishing).

Later on (from 2025-01) I trimmed this flow to use a single repository for my site, with the rendered HTML for publishing directed to its pages branch.
prose.sh (from 2026-08) - A minimalistic ssh/scp driven (webmaster authentication/publishing, respectively) blogging platform. Its clean simplicity comes with a few trade-offs (more details below), but I've already worked around the main ones and am quite satisfied.

Limitations of prose.sh #

Due to prose.sh's minimalistic nature, when migrating I encountered several incompatibilities. Some allowed adaptations and workarounds - while others required compromise, as I dropped some non-critical features. These incompatibilities fall into two groups - let's explore them both:

Non-blog-post pages #

Since prose.sh is strictly a blogging service, content can only live as posts or on the landing page (blog index) - there's no mechanism for additional standalone pages (such as a separate About page or Contact page).

Pages candidate #

One candidate solution worth mentioning was pico.sh's pages service (intended for deploying static pages). However, it was ruled out for several reasons:

The pages would be published separately (as standalone objects, logically), requiring some DNS acrobatics to relate with the new site.

Any CSS rules/overrides would need to be duplicated (and adapted) in order to keep a coherent design.

As the pages service is separate, it would also require an additional directory and deployment pipeline to manage.

Draft-based workaround #

The workaround I settled on was publishing these static pages as pseudo-draft blog posts (still via prose.sh) and then listing them under the landing page's navigation bar:

The way prose.sh drafts work is that they are uploaded and reachable directly by their URL slug (check out your address bar for this post), but unlisted in the blog's index page/list.
I then included their relative URL in the navigation bar via prose.sh's _readme.md file, which is used for basic customization of the blog's index/landing page:
```
1nav:
2  - about: about
3  - contact: contact
4  - links: links
```
Finally, in order for the actual page to appear less bloggy (is that a word?) I added a custom CSS override to hide their date/timestamp from these pseudo-posts' pages:
```
1body.about #publish-at,
2body.contact #publish-at,
3body.links #publish-at {
4  display: none;
5}
```

Inline HTML & JS in static Markdown #

For some, this would be a deal-breaker, but for me - the indie-web nature actually appeals. When prose.sh receives Markdown, it strips out any inline HTML (which, of course, also includes JavaScript <script> tags) before rendering. The items below were affected:

Dark/light toggle via a short JavaScript. The browser's native prefers-color-scheme CSS covers this almost as well — minus the toggle.
GoatCounter analytics - is privacy-respecting and made to be integrated with one <script> line. A paid alternative exists via a pico+ subscription, but I don't have the traffic to justify it.

Automatically opening links in a new tab, for links outside my domain - this relies on the <a> element including a target="_blank" attribute. Although I liked this behavior, I was quite happy dropping it, since now my source files are cleaner with native Markdown links instead of the noisier HTML ones.
Fetching 3rd party resources such as FontAwesome icons via a <link> stylesheet. This wasn't required for the new site's design, so it was fine to drop.
To verify a link on my Mastodon profile, the page must link to it with an element containing a rel=me attribute (see specification). This minor inconvenience only impacts my Mastodon profile, not this site.

Conclusion #

Yes, I gave up on a handful of bells and whistles when adopting prose.sh, but perhaps that made more "space" for the important part - the content body.

There's still plenty to tinker with here, sure. But for the first time in a long while, this blog's most active area of development isn't its own infrastructure - it's the words. Stripping out my SSG didn't just simplify the stack, it removed most of the machine I kept tuning instead of writing.

I won't dare make any big commitments yet, but the fact that my blog has gone through another phase of its evolution and that I've published a new post, is something positive. And though I enjoyed both, if I'm honest, the tinkering was the real treat.

This post touched the subject of UX from the reader's perspective, but the writer's UX is where the post truly lands.

#prose.sh #blog #blogging #meta #minimalist #ux #workarounds #ssg #devops

last updated: 2026-09-10