← back

Building This Blog


TL;DR


Storyline

As recent interviews showed me, things I do as a hobby or in a homelab1 aren’t impactless — the problem is presenting them “the right way”. Unless I show something, it’s just my word.

I didn’t want to just create a GitHub account and dump my projects there. Instead, I want to show the story behind them: why I decided to build something, why I made certain decisions, and what impact those had. This blog (I hope) will let me do that.

After each post I’ll include a short note on whether AI was involved and, if so, to what extent — whether it just fixed some grammar, helped put things together, or wrote entire sections.

Why Astro

A devlog (or blog in general) is just a text. It doesn’t necessarily need a full frontend framework, a backend, or a database.2 What it needs is a fast, predictable way to turn an easy-to-write text format into HTML.

Astro does exactly that! By default it ships no JavaScript to the browser — pages are static HTML generated at build time. Vue is wired in as an integration for when something genuinely needs reactivity. Right now nothing does, but the option is there.

The other thing that sold it was content collections: a schema-validated layer on top of Markdown files. Define the shape of a post (title, date, description), and Astro enforces it at build time. No surprises at runtime, no missing frontmatter.

The alternative was something like Next.js, which would have been overkill, or a pure static site generator like Hugo, which felt like going in the wrong direction for a project that might eventually need some interactivity in the future.3

Why Cloudflare Pages

Every time I approach a new project, I go through the same mental checklist: cloud or on-prem, monolith or microservices, ETL or ELT. I already run a lot of services on my own infrastructure — I didn’t want to pile more onto it.

I just need fast static file hosting for a small project. Nothing complicated. On one hand, I already host websites on my bare-metal server — adding another one is a 2-minute job: a new directory, an nginx config, restart, done.

On the other hand, I want to minimise the responsibility of keeping everything running smoothly. A misconfigured framework on a shared server is a real risk4 — why carry that when I don’t have to? Let Cloudflare handle it; they’re better at it than I am.

And at the same time — unlimited sites, static requests, and bandwidth, without having to push everything to a public GitHub5 repo (all easter eggs stay with me and Claude).

Deployment

Initially, I planned to connect Cloudflare Pages directly to GitHub for automatic deployments triggered by a push to main. However, setting up that seamless connection turned out to be more of a hassle than expected.

Instead of fighting the UI, I fell back to a Node.js deploy script using the Cloudflare Wrangler CLI. It builds the site locally, handles Git commits, and pushes the dist directory straight to Cloudflare.

(Originally written as a bash script, rewritten in Node.js for Windows compatibility.)

Here is the deploy.mjs script I’m currently using to chain things together:

import { execSync } from "child_process";
import { argv } from "process";

const msg =
  argv.slice(2).join(" ") ||
  `deploy: ${new Date().toISOString().slice(0, 16).replace("T", " ")}`;

function run(cmd) {
  console.log(`\n▶ ${cmd}`);
  execSync(cmd, { stdio: "inherit" });
}

run("npm run build");
run("git add .");

const hasChanges =
  execSync("git diff --cached --name-only").toString().trim().length > 0;
if (hasChanges) {
  run(`git commit -m "${msg}"`);
  run("git push");
}

run("npx wrangler pages deploy dist --project-name=[REDACTED]");

The custom domain (blog.szabra.com) was one step in the Cloudflare Pages settings — add it as a custom domain, Cloudflare handles the DNS record and HTTPS certificate automatically.


Lessons learned

  1. Learning Astro was inspiring - gave me a great opportunity to use an elegant solution and experience its fantastic CLI.
  2. Connecting Cloudflare Pages to GitHub wasn’t an easy task - mitigated it by creating a deploy script for chaining things together - a proper CI/CD pipeline is on the list.
  3. Even at this early stage I caught myself wanting to over-engineer things.

AI Impact Disclaimer

  • DEVELOPMENT: Guided code generation
  • WRITING: Post scheme, grammar and rephrase sentences to sound more natural (I’m not a native speaker).

Footnotes

  1. Not really located at my home as the name suggests — just OVH bare metal and a few Mikrus VPSes.

  2. I’ve been down that road before — delivering one piece at a time is the smarter approach.

  3. Yes, I’d love to add more features over time — I just need a valid reason first, otherwise I’ll overengineer it.

  4. As someone new to Astro at the time, the odds of that weren’t exactly zero.

  5. Using GitHub free account.