Blog init: Hello, world!
First post — what this blog runs on, two things that bit me while setting it up, and what I plan to write about.
TL;DR
1
2
$ echo "hello, world"
hello, world
Obligatory. So: I finally set up a place to write things down. It runs on Jekyll 4.4.1 with the Chirpy theme, the whole toolchain lives in a container, and it deploys itself when I push. Two things bit me on the way, both worth writing down.
Why bother with a blog at all
I keep notes anyway. They pile up in scratch files, in private repos, in messages to myself. The problem with that is not storage — it is that a note you wrote for yourself is missing exactly the part you will need in a year: why you chose this over that, and what went wrong the first time.
Writing for someone else forces you to keep that part. That is the whole motivation. If it also saves someone an evening of debugging, better still.
The setup
Jekyll needs a Ruby that the system Ruby on macOS is not, and I did not want a version manager, a shell hook and a native-extension toolchain permanently installed for one hobby project. So the entire build environment is a Dockerfile: Ruby, Bundler and every gem live in an image, and nothing touches the laptop.
The rule I apply everywhere: if a tool exists only to build one project, it belongs to that project, not to the machine. Fixing a broken toolchain then means deleting an image instead of unpicking years of package manager history.
A Makefile wraps the container so the daily loop is short:
1
2
3
4
make new TITLE="Taming Proxmox backups" CATEGORIES="Homelab, Proxmox"
make serve # http://localhost:4000, drafts and livereload
make check # production build + link check, same as CI
git push
Scaffolding is a script rather than a snippet I paste from the last post — front matter is exactly the kind of thing that rots when it is copied. git push hands over to GitLab CI, which builds with JEKYLL_ENV=production, runs html-proofer over the output and ships it to Cloudflare with wrangler. A broken internal link fails the pipeline instead of greeting a reader.
Worth knowing if you set this up today: Cloudflare’s dashboard now steers static uploads towards Workers, so following a Pages tutorial while the UI hands you a Worker is a good way to spend an evening confused. Both work. For a site with no edge code — no bindings, nothing to run per request — Pages is the simpler of the two, and wrangler pages is fully supported:
1
wrangler pages deploy _site --project-name srepowered-blog --branch main
The build also happens in CI rather than through Cloudflare’s own Git integration. Cloudflare would install its own Ruby; building from the committed Gemfile.lock in a pinned image means production runs the same gem versions I wrote the post against.
Two things that bit me
Neither of these failed loudly, which is what made them interesting.
The dev server is not the production site. Chirpy loads Bootstrap from a CDN in development only; for production it expects Bootstrap to be compiled into the theme CSS. I had customised the theme’s stylesheet and dropped that part, so the local preview looked perfect while the production build shipped a site with no grid at all — and a square logo, because the avatar is round thanks to a Bootstrap utility class. Nothing errored. There is now a separate command that serves the production build locally, and it is the only honest way to check a CSS change.
A future-dated post silently disappears. I stamped a post a few minutes ahead of the clock and Jekyll dropped it from the build — no warning, no error, nothing in the log. I only noticed because the link checker reported fewer files than I expected. Now the scaffold script stamps the real clock and I do not hand-edit dates.
There is a pattern in both: the failure produced plausible output rather than an error. Those are the ones that reach production.
What I plan to write about
My curiosity is wide and not especially disciplined, so this will not be a single-topic blog. Roughly, the things I actually run and break:
- Homelab — Proxmox, storage, backups, and the long tail of keeping a rack in a flat quiet and cheap
- Linux — the parts I end up reading source or man pages for
- Kubernetes — clusters, GitOps, and the operational reality behind the diagrams
- Networking and edge — Traefik, HAProxy, reverse proxies, TLS, and the proxy-behind-a-proxy problems that follow
- LLMs — running models locally, wiring them into infrastructure tooling, and where they genuinely help versus where they just look impressive
- Self-hosted services — the ones worth the maintenance, and the ones I removed again
- Automation and observability — Ansible, Terraform, metrics, and figuring out what actually broke
Real configs, real versions, and the failure modes. The failure modes are usually the useful part.
Static site, container toolchain, git as the publish button. Everything here exists so the interesting part is the writing.