Projects on Backend Engineering Strategy Tools

Image Tooling

Thu, 18 Jun 2026 00:00:00 +0000

Versioned, multi-arch Docker images for Kubernetes workflows — built with Dagger, published to Docker Hub, triggered by a version tag.

The motivation is in Shared Tooling Images: one image, consistent versions, three contexts — CI, local, colleagues.

Images

GitHub repo	Docker Hub	Contents
`image-tooling`	`best-tools/tooling-k8s`	kubectl, helm, kustomize, argocd CLI, k9s, jq, yq
`image-tooling`	`best-tools/tooling-k8s-aws`	`tooling-k8s` + AWS CLI
`image-tooling`	`best-tools/tooling-k8s-openstack`	`tooling-k8s` + OpenStack CLI
`image-buildx`	`best-tools/buildx`	CI builder — Docker buildx, AWS CLI, Dagger CLI
`image-pandoc`	`best-tools/pandoc`	PDF generation — pandoc + TeX Live

All images publish as multi-arch manifests: linux/amd64 + linux/arm64.

Quick start

Interactive shell with kubeconfig mounted:

docker run -it --rm \
 -v ~/.kube:/mnt/kube:ro \
 -v $(pwd):/work \
 -w /work \
 docker.io/best-tools/tooling-k8s:latest

The image entry point symlinks /mnt/kube → /root/.kube on startup, so kubectl picks it up immediately.

Shell alias for daily use:

alias k8s='docker run -it --rm \
 -v ~/.kube:/mnt/kube:ro \
 -v $(pwd):/work -w /work \
 docker.io/best-tools/tooling-k8s:latest'

k8s helm lint .
k8s kubectl get pods -n argocd

In CI (GitHub Actions):

- name: Lint chart
 run: docker run --rm -v ${{ github.workspace }}:/work -w /work docker.io/best-tools/tooling-k8s:latest helm lint .

Or reference the image directly as the job container — no install step needed.

Setup (contributors / maintainers)

Credentials are set once as GitHub org-level secrets and inherited by all image-* repos automatically.

Secret	Where to get it
`DOCKERHUB_TOKEN`	hub.docker.com → Account → Security → Access Tokens (Read, Write, Delete)
`DAGGER_CLOUD_TOKEN`	cloud.dagger.io → Organisation → Tokens

Path: github.com/Backend-Engineering-Strategy-Tools → Settings → Secrets and variables → Actions → New organisation secret.

Releasing

git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0

The GitHub Actions workflow triggers on v*.*.* tags, calls dagger call publish-multi-arch, and pushes both best-tools/<image>:v1.0.0 and best-tools/<image>:latest to Docker Hub. Pipeline trace at cloud.dagger.io.

This Site

Thu, 18 Jun 2026 00:00:00 +0000

This started as an effort to clean up and publish existing notes — things accumulated over years of work that were sitting in various raw forms and never properly written up. The act of publishing forces a level of clarity that private notes rarely get: you have to explain the context, fill the gaps, and decide what actually matters.

It doubles as deliberate practice in documentation. Getting into the habit of writing things up properly — not just as a record of what was done, but as something useful to come back to — is a skill that compounds. The site is both the output and the exercise.

Practically it also serves as a personal reference: a place to look things up that I have actually done and know the details of, rather than re-deriving them from scratch.

Stack: Hugo static site using the Stack theme v4 via Go modules. Deployed to GitHub Pages via GitHub Actions.

Repo: Backend-Engineering-Strategy-Tools/site

Why Hugo

Static is the right default for content that does not need dynamic rendering. Hugo is fast — full site builds in milliseconds — and its template model maps well to a Go-centric mindset. The theme ecosystem is good and the Stack theme in particular supports the layout and content model needed here without significant customisation.

Build Pipeline

The GHA workflow runs on push to main:

Fetch private assets — CV and cover letter PDFs are stored in a private release on a separate repo. The workflow fetches them via GitHub API using a scoped BEST_SITE_PAT secret and writes them into static/cv/ before the build.
Hugo build — hugo --minify via the official ghcr.io/gohugoio/hugo Docker image, producing public/.
Deploy — actions/deploy-pages pushes public/ to GitHub Pages.

This keeps CV content separate from site code — the PDF repo can be updated independently without touching the site repo, and a site redeploy picks up the latest version.

Theme Customisation

Stack theme v4 is imported via go.mod. Hugo’s lookup order means local files in layouts/ or assets/ override the theme without forking it.

The main override is layouts/_default/single.html — the site uses layout: single on all content pages to get full-width rendering (no sidebar). All pages also set showReadingTime: false in front matter.

Domain

Currently served at backend-engineering-strategy-tools.github.io/site/. A redirect from best.mjnet.info is set up via an S3 static website bucket — no files in the bucket, just a redirect rule. DNS managed in Route53.

S3 bucket setup (bucket name must match domain):

aws s3api create-bucket \
 --bucket best.mjnet.info \
 --region eu-central-1 \
 --create-bucket-configuration LocationConstraint=eu-central-1

aws s3api put-public-access-block \
 --bucket best.mjnet.info \
 --public-access-block-configuration BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false

aws s3api put-bucket-website \
 --bucket best.mjnet.info \
 --website-configuration '{"IndexDocument":{"Suffix":"index.html"},"RoutingRules":[{"Redirect":{"Protocol":"https","HostName":"backend-engineering-strategy-tools.github.io","ReplaceKeyPrefixWith":"site/"}}]}'

Route53 ALIAS record pointing best.mjnet.info at the S3 website endpoint:

aws route53 change-resource-record-sets \
 --hosted-zone-id <ZONE_ID> \
 --change-batch '{
 "Changes": [{
 "Action": "CREATE",
 "ResourceRecordSet": {
 "Name": "best.mjnet.info",
 "Type": "A",
 "AliasTarget": {
 "HostedZoneId": "Z21DNDUVLTQW6Q",
 "DNSName": "s3-website.eu-central-1.amazonaws.com",
 "EvaluateTargetHealth": false
 }
 }
 }]
 }'

Z21DNDUVLTQW6Q is the fixed AWS hosted zone ID for S3 website endpoints in eu-central-1.

Content Model

Two sections with distinct purposes:

Section	Tone	What goes here
`homelab/`	Narrative, first-person	What actually happened — the sequence, dead ends, workarounds
`public-notes/`	Reference, factual	How things work — distilled, structured, without the personal journey

The separation keeps the narrative and reference writing from muddying each other. A reader looking for a quick reference does not want to read about what went wrong first; a reader following the homelab story wants the context.

projects/ and thinking/ round out the structure — projects are documented outcomes, thinking is longer-form analysis.

What’s Next

The current setup — Hugo on GitHub Pages — is the right foundation for a content-heavy site. A few things are planned or in progress:

Custom domain — best.mjnet.info redirect via S3 + Route53 (see Domain section above). Proper custom domain with HTTPS as a follow-up.
Better build pipeline — replacing the Makefile with a Dagger Go module for local/CI parity and pinned Hugo versions.
More content — the backlog of notes and projects is long. The site grows as things get cleaned up and published.

Longer term, the intent is to grow this into a more multi-faceted site — login-protected sections, dynamic content, interactive tooling. Hugo handles the static part well; the approach is to add separate paths alongside it for authentication and dynamic content rather than replacing the static foundation. The static site stays fast and low-cost, dynamic parts layer in where they are actually needed.

Gardener on Cleura

Tue, 16 Jun 2026 00:00:00 +0000

Getting hands-on with Gardener on Cleura — a European OpenStack cloud — ahead of using it professionally. The focus is on the networking and traffic ingress side: how does a Gardener shoot cluster on OpenStack expose services, what does the LoadBalancer path actually look like, and when does ingress apply versus when it does not.

The test application is a Minecraft server with Velocity proxy — useful precisely because it is raw TCP rather than HTTP, which forces the full LoadBalancer path rather than an ingress shortcut.

→ Gardener on Cleura — technical notes

Steps

1 — Shoot cluster

Provision a Gardener shoot cluster on Cleura. Cleura wraps Gardener behind their own REST API — gardenctl and the Gardener Terraform provider require the garden cluster kubeconfig, which Cleura does not expose. Cluster lifecycle goes through their REST API instead.

→ Provisioning via Cleura REST API
→ Cleura docs issue #533 — IaC and gardenctl access

2 — Minecraft via standard LoadBalancer

Deploy itzg/minecraft-server as a StatefulSet with a plain LoadBalancer service for TCP 25565 — the direct Octavia path, no Gateway involved. Gets the server running quickly and confirms TCP exposure works on Cleura independently.

Internet
 |
TCP 25565
 |
Octavia LB (direct LoadBalancer service)
 |
Minecraft Pod (itzg/minecraft-server)
 |
PVC (Cinder)

Manifests: stateful_set.yaml · service.yaml

Apply directly from this repo:

kubectl apply -k "https://github.com/Backend-Engineering-Strategy-Tools/site//static/scripts/mc?ref=main"

Check the rollout and grab the external IP:

kubectl get all -l app=mc-example

kubectl get svc mc-example \
 -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}'

2.5 — Migrate to Helm chart

Swap the raw manifests for the itzg/minecraft-server-charts Helm chart — actively maintained, covers server type, persistence, RCON, backups, and extra ports (BlueMap, Dynmap). The raw YAML stays useful as a reference for the underlying shape.

Manifests: values.yaml

helm repo add minecraft-server-charts https://itzg.github.io/minecraft-server-charts/
helm upgrade --install mc minecraft-server-charts/minecraft \
 -f https://backend-engineering-strategy-tools.github.io/site/scripts/mc-helm/values.yaml

Check the rollout and grab the external IP:

kubectl get all -l app.kubernetes.io/instance=mc

kubectl get svc mc-example -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}'

3 — Envoy Gateway

Deploy Envoy Gateway into the shoot cluster — the CNCF implementation of the Kubernetes Gateway API. The NGINX Ingress Controller is deprecated; Gateway API is the forward path with a standardised spec for both HTTP and TCP.

Envoy Gateway exposes a single LoadBalancer service via Octavia. Everything routes through it.

4 — HTTPRoute, certificates, and BlueMap

Deploy BlueMap — a Minecraft mod that renders the world as a live 3D web map served over HTTP. Route it through the Gateway with a HTTPRoute and wire cert-manager to provision a Let’s Encrypt certificate.

A real HTTP service with a real use, not a throwaway test page. Validates the full HTTP + TLS path before touching the game server.

5 — Migrate to TCPRoute

Migrate the TCP service to a TCPRoute through Envoy Gateway. TCPRoute is in the Gateway API experimental channel — this step validates that a single Gateway handles both HTTP and raw TCP.

Internet
 |
Octavia LB (one Gateway LoadBalancer)
 |
Envoy Gateway
 |
+------------------------------+------------------------------+
| |
HTTPRoute → BlueMap TCPRoute → Minecraft

6 — Velocity (if needed)

Add Velocity as a TCP proxy in front of the Minecraft server if multi-server routing becomes relevant — lobby, modded, survival as separate backends. Skip if a single server is enough.

→ Minecraft project

7 — Plugin pipeline

A colleague is building a Minecraft plugin. The goal is a Dagger pipeline with GitHub Actions — the same build running locally and in CI, covering the JVM toolchain and packaging steps.

8 — AI

Something with NPC behaviour, a bot, or plugin-side automation. Low priority, high fun.

IaC gap

Cleura does not expose the garden cluster kubeconfig. That one limitation closes off the entire Gardener tooling ecosystem: gardenctl requires it, the Gardener Terraform provider requires it, and any Crossplane provider built on the Gardener API would require it too. There is no HCL path here.

What remains is Cleura’s own REST API — which is fine for interactive use but falls short the moment you want to drive cluster lifecycle from a pipeline. A bash script wrapping curl and jq works, and that is what cleura-shoot.sh does, but it is a workaround rather than a solution. No state, no plan, no diff — just imperative API calls.

Options if this needs to graduate beyond a script:

Crossplane provider-http — can wrap the REST API declaratively, but has no native polling or deletion hooks, so the reconciliation story is awkward
Custom Terraform provider — full plan/apply semantics, but requires writing a Go provider from scratch
Pulumi dynamic provider — similar effort, Python or TypeScript

A feature request for gardenctl access or a native IaC provider has been filed with Cleura (→ cleura/docs#533). Until something changes there, the bash script is as good as it gets.

Status

Step	Status
1 — Shoot cluster on Cleura	done
2 — Minecraft via LoadBalancer (itzg)	planned
2.5 — Migrate to Helm chart	planned
3 — Envoy Gateway	planned
4 — HTTPRoute + cert-manager + BlueMap	planned
5 — Migrate to TCPRoute	planned
6 — Velocity	planned
7 — Plugin pipeline (Dagger)	planned
8 — AI	planned

Building this out — notes will expand as each step lands.

Procedural Mesh — Blender Python & AI-Assisted Geometry

Tue, 02 Jun 2026 00:00:00 +0000

Using Python scripts inside Blender to generate, manipulate, and export geometry — rather than modelling by hand. The config block is the model. Changing a dimension means editing a constant and re-running, not touching a mesh.

Two related but distinct approaches:

Parametric generation — the script builds geometry from scratch. Holes, plates, text engravings, export to STL, automated renders. The shape lives entirely in code.
Mesh manipulation — an existing STL is imported and cut up. Different problem: no parametric handle, working with whatever the downloaded mesh gives you.

Both involve AI in the loop — either iterating on the Python with Claude, or using AI to determine cut planes on existing geometry.

Stages

Step		Status
0	Manual Blender modelling — Packat & Klart badge and scout emblem casting master; learning the tool before scripting	Done
1	Approach documented — Python scripted geometry, config-block iteration pattern	Done
2	Rack Support Brace — first implementation; flat plate, boolean hole grid, engraved text, automated renders	Done
3	Headless render — Blender 5.1.2 + Dagger pipeline; STL → multi-angle PNGs without opening Blender; smoke-tested and running in CI	Done
4	Scout Buckle — complex geometry; compound curves, functional tongue mechanism, tolerances that matter	In progress
5	CI/CD pipeline — STL or script change → GitHub Actions → Dagger → PNG artifacts; procedural-mesh-pipeline	Done
6	AI feedback loop — describe correction → updated script → re-run, without opening Blender	Planned
7	Dragon Split — mesh manipulation; cut an existing articulated dragon STL into printable segments with connectors	Not started

Notes

The rack brace (step 2) was easier than expected — straightforward geometry, minimal iteration. That is why the pipeline steps did not get built yet: the manual workflow was fast enough that the overhead of automating it was not justified for one part.

The scout buckle (step 4) is the harder test. Compound curves and functional constraints mean the script has needed partial rebuilds rather than config-block edits. That is the case that justified building the render pipeline properly.

Steps 3 and 5 ended up built together rather than sequentially. The pipeline lives in a separate repo — procedural-mesh-pipeline — Dagger + GitHub Actions, Blender 5.1.2 headless, Cycles CPU. Renders run natively on the CI runner (amd64); locally the pipeline is used for smoke-testing the image only. Blender has no official ARM64 Linux binary so local renders under emulation are impractical.

The dragon split (step 7) is a different class of problem — remixing rather than generating. Worth keeping in the same project because the tooling overlaps (Blender Python, STL export) even if the approach does not.

Kubernetes Across the Stack

Mon, 16 Mar 2026 00:00:00 +0000

A documented comparison of running Kubernetes across every major hosting model — cloud managed, self-managed on cloud, private cloud, and bare metal at home. The goal is a honest, practical reference for each environment: what it costs you in time and money, where the rough edges are, and how the networking story differs between them.

The thread running through all of it is Talos Linux — an immutable, API-driven OS built specifically for Kubernetes. No SSH, no shell, no config drift. The same OS everywhere means the operational model stays consistent regardless of what is running underneath.

Environment	Approach
OpenStack — Cleura	Talos & Terraform	draft exists
OpenStack — Cleura	Talos, with Omni	maybe ?
OpenStack — ElastX	Talos & Terraform	draft exists
OpenStack — ElastX	Talos, with Omni	maybe ?
Homelab — bare metal	Talos + Pixieboot + Omni	draft exists
Homelab — bare metal	Talos + Pixieboot without Omni	maybe ?
Homelab — OpenStack	OpenStack on bare metal, Talos running on top	(stretch)
Homelab — OpenStack	Talos on bare metal, OpenStack inside cluster	(stretch)
AWS	Talos on EC2	(stretch)
Azure	Talos on VMs	(stretch)
GCP	Talos on Compute Engine	(stretch)

Stretch goals

AWS, Azure, GCP — same Talos approach, different underlying infrastructure. Interesting eventually, but not the priority.

Omni

Omni is Sidero’s managed control plane for Talos clusters — worth documenting both with and without it. Without Omni gives you the full picture of what Talos management looks like manually; with Omni shows what the managed layer buys you.

Homelab provisioning

Nodes provisioned via Pixieboot — no USB sticks, no manual installations. A node powers on, boots from the network, and registers. The goal is a fully reproducible cluster from scratch with minimal human steps.

Scope

Cluster provisioning and bootstrap for each environment
Networking — CNI choices, ingress, cross-cluster connectivity
Storage — what you get managed vs what you have to bring yourself
Operational differences — upgrades, node management, observability
Cost and trade-off summary across environments

Making it usable

Getting a cluster running is the easy part. Making it usable is where environments diverge. Each environment needs an answer for ingress, DNS, and storage — and the answer varies significantly depending on what the underlying platform provides.

On managed cloud you can lean on load balancers and block storage from the provider. On OpenStack you have those options if the provider exposes them. On bare metal at home you are on your own — MetalLB or similar for load balancer IPs, a local DNS solution, and either local storage or something like Rook/Ceph. Same Kubernetes, very different operational story underneath.

Notes exist in various states — pulling them together, testing, and documenting properly is the work.

Minecraft Server

Mon, 16 Mar 2026 00:00:00 +0000

Building and running a Minecraft server with the kids — hosted in the homelab on bare metal rather than paying for a managed service. Part infrastructure project, part excuse to learn together.

The longer-term goal is a proper setup: automated backups, world persistence across restarts, maybe some automation around starting and stopping the server on demand.

Notes and repo to follow.

More to come.

Touchscreen HUD Build

Mon, 16 Mar 2026 00:00:00 +0000

A small batch of fanless Atom-based machines with touchscreens — picked up as a hardware experiment, now being packaged up to hand out to colleagues at nerd night.

The goal: a fully reproducible setup. Boot from a Debian preseed image, drivers configured, sensible defaults in place, and a demo running out of the box. Each machine goes out with a link back to the repo so anyone who wants to dig in or rebuild from scratch can do so.

Repos

touchdemo — demo application running on the devices (work in progress)
debian-preseed-demo — automated Debian install via preseed (in progress)

Still to figure out

Power adapter specs and sourcing
Preseed configuration — touch input, display drivers, auto-login
First-boot experience and documentation

Projects on Backend Engineering Strategy Tools

Image Tooling

Images

Quick start

Setup (contributors / maintainers)

Releasing

Links

This Site

Why Hugo

Build Pipeline

Theme Customisation

Domain

Content Model

What’s Next

Gardener on Cleura

Steps

1 — Shoot cluster

2 — Minecraft via standard LoadBalancer

2.5 — Migrate to Helm chart

3 — Envoy Gateway

4 — HTTPRoute, certificates, and BlueMap

5 — Migrate to TCPRoute

6 — Velocity (if needed)

7 — Plugin pipeline

8 — AI

IaC gap

Status

Procedural Mesh — Blender Python & AI-Assisted Geometry

Stages

Notes

Kubernetes Across the Stack

Minecraft Server

Touchscreen HUD Build