Part 1: Why Build One?
Part 1 of the Forge series: turning an old dual Xeon workstation into a documented, rebuildable home platform for AI-assisted development, self-hosted Git, and automation
Forge is an old ASUS dual Xeon workstation — 32GB of RAM, two small SSDs, two 6TB drives — rebuilt into a documented, rebuildable home platform: Proxmox underneath, a ZFS mirror for the data that matters, a Docker host running twenty-odd services, self-hosted Git with CI, and publishing to the internet without a single open router port.
This series is the honest build log. It covers the decisions and their reasoning, but also the failures that shaped them: the local AI that was too slow to keep, the disk that filled to 97% while a metrics stack watched in silence, the DNS toggle that took every public service offline, and the services retired for having no job. Every post follows the same rule — goal, decisions, what broke, what it delivered.
Parts publish in build order. The roadmap below shows where the series has been and where it goes next.
Part 1 of the Forge series: turning an old dual Xeon workstation into a documented, rebuildable home platform for AI-assisted development, self-hosted Git, and automation
Part 2 of the Forge series: choosing Proxmox over the alternatives, installing it on a dual Xeon workstation board, and the sequencing mistakes worth avoiding
Part 3 of the Forge series: carving four old drives into two deliberate tiers — a ZFS mirror for the data that matters and SSD thin pools for the containers that move
Part 4 of the Forge series: choosing Docker-inside-LXC over a VM, the shared network decision that shaped everything after, and the day the root disk hit 97%
Part 5 of the Forge series: layering uptime checks and a full metrics stack over the platform — and the honest lesson that dashboards nobody looks at are not monitoring
Part 6 of the Forge series: what dual Xeon hardware really delivers for local LLM inference, the GPU upgrade that didn't add up, and the service review that retired every container without a job
Part 7 of the Forge series: why Forgejo over GitLab, the CI label mismatch that queues jobs forever, the push-mirror pattern that keeps GitHub useful, and the Redis that held zero keys
Part 8 of the Forge series: exposing a homelab without opening a single router port — the tunnel-plus-Caddy pattern, Cloudflare Access as the front door, and the DNS toggle that took everything offline
Part 9 of the Forge series: the /opt/platform layout, confessing drift in a gaps file, CI that validates the repo, Renovate proposing updates, and the allowlisted workflow that deploys a merged PR
Part 10 of the Forge series: a dedicated Debian VM for client staging sites, the scripts that pull live WordPress sites down safely, and the wildcard-certificate limit that changed the hostname plan
Part 11 of the Forge series: the storage tiers earn their keep — Navidrome as the low-risk first media service, Immich for photos only after the backup posture deserved them, and a 44GB import done safely
Part 12 of the Forge series: a self-hosted identity provider for the platform — OIDC for the Immich apps, a worker with no Docker socket, break-glass accounts, and a restore proof before trust
The operator layer — searchable container logs with Loki and Alloy, WUD watching registries for updates, quiet-hours work lanes for risky storage jobs, and the automated morning digest that turned platform care from a hobby into a routine.