All posts
Technical deep-dives from building the minicloud platform — GitOps, Kubernetes, AI, and bare-metal engineering.
A layer-by-layer comparison between minicloud — a 5-node k3s cluster assembled from CNCF components — and OpenShift Container Platform (OCP) self-hosted. Same problems, different approaches: immutable nodes, control plane management, security posture, upgrades, and what each model teaches you.
HA on a self-managed k3s cluster is not one setting — it is six independent layers, each with a concrete trade-off. This post walks through every layer on minicloud, what was validated by a live chaos game day, and how the same concerns map to EKS, GKE, and AKS.
A deep dive into self-hosting Jitsi Meet as a full Microsoft Teams replacement — architecture, WebRTC internals, Kubernetes deployment, Authentik SSO, and solving the SFR 5G DS-Lite CGNAT problem with a direct IPv6 media path. Everything you need to understand and build it yourself.
k3s replaces etcd with Kine/SQLite — one file on one machine. This post explains exactly what that means for backups, HA, and recovery on a bare-metal cluster, and contrasts it with how EKS, GKE, and AKS manage the same problem invisibly.
A concrete look at upgrading Kubernetes — comparing EKS, GKE, and AKS one-click upgrades against the system-upgrade-controller Plans and GitHub Actions automation I built for my 5-node bare-metal k3s cluster. Every decision documented, every gotcha included.
On a managed Kubernetes provider, security patching is largely invisible. On a self-managed k3s cluster, you own every layer: OS kernel patches, k3s binary CVEs, container base images, Helm chart versions, and CIS posture drift. This post documents the full patching stack on minicloud — what runs automatically, what requires a PR, and how each layer compares to EKS, GKE, and AKS.
A concrete comparison of running a k3s control plane on a ThinkPad versus EKS/GKE/AKS — grounded in a real bare-metal cluster, not theory. What you own, what breaks, and what you learn.
La quantization ne sert pas qu'à réduire la RAM. Derrière cette technique, il y a trois objectifs concrets : démocratiser l'accès, accélérer l'inférence, et permettre le déploiement privé. Et entre le modèle sorti du labo et celui qui tourne sur ton cluster, il s'est passé beaucoup de choses.
Un 7B en FP32 c'est 28 Go de RAM. Sur mon cluster ThinkPad, impossible. La quantization m'a permis de descendre à 4.7 Go sans perdre la qualité qui compte. Voici comment ça fonctionne.