Part 2 of the series: Building a Self-Hosted AI Development Platform
•
5 min read

Building a Self-Hosted AI Development Platform — Part 2: Installing Proxmox on Old Dual Xeon Hardware

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 2: Installing Proxmox on Old Dual Xeon Hardware

In Part 1 I made the case for Forge: an old ASUS dual Xeon workstation, rebuilt as a documented platform for AI-assisted development, self-hosted Git, automation, and storage. This post covers the first real step. A hypervisor goes onto the bare metal, and the important decisions come before a single container exists.

Fair warning: the Proxmox installer is genuinely easy, and it finishes in about fifteen minutes. The interesting part is everything around the installer. Why Proxmox and not the alternatives? How were the disks divided before anything ran on them? And which sequence lessons only became clear when services stacked up?

The Start Point

A reminder of the hardware on the bench:

  • ASUS dual Xeon workstation/server board
  • 32GB of RAM
  • 2 x Samsung 256GB SSDs
  • 2 x 6TB hard drives

Nothing exotic, nothing new, and — as Part 1 explained — nothing that can run fast local LLM inference. But two CPUs of cores and a sensible amount of RAM is a good base for the real job. That job is a couple of dozen services, a CI runner, and later a full web development VM, all at the same time.

Why Proxmox?

The first decision was not which hypervisor. It was whether to use one at all. The lightweight route is Debian plus Docker directly on the metal: one OS, no virtualization layer, less to learn. I rejected it for one reason that paid off months later. This machine will one day need real VMs, not only containers. A dedicated web development VM was always on the roadmap, and it exists now. Bare-metal Docker gives no path to that. A hypervisor gives both.

Proxmox VE won, and the margin was wide. It is free and open source. It treats LXC containers and full KVM virtual machines as first-class citizens. ZFS support is part of the installer, not an addition. And — critical for the “rebuildable platform” goal — it has scheduled backup jobs from the start. Snapshot a container, back it up on a timer, and restore it in minutes.

ESXi got a short look and a fast rejection. The free tier’s future is doubtful since the Broadcom acquisition. Hardware support for old boards is a lottery, and it has no ZFS. A personal platform that depends on a license whim is a bad bet.

TrueNAS Scale is a good product, built as a NAS that also runs applications. This build needed the opposite emphasis: a virtualization platform where storage serves the services.

The honest version of the decision: Proxmox is boring, well documented, and does everything this project needs without payment. Boring is a feature in the foundation layer.

The Installer

The mechanics are quick to summarize. Download the Proxmox VE ISO, write it to a USB stick, and boot the target machine from the stick.

Old hardware shows itself in the firmware. A board of this age predates UEFI-boot-from-NVMe assumptions, so expect a detour through the BIOS. Set the boot mode, make the USB stick a boot device, and — while you are there — make sure that the virtualization extensions (Intel VT-x and VT-d) are on. Boards frequently ship with them off, and Proxmox without hardware virtualization is a sad thing.

The installer asks three questions that matter:

  1. Target disk. The first 256GB SSD got the Proxmox OS. The second SSD and the two 6TB drives stayed untouched, and the next section says why.
  2. Network. A static IP on the LAN. A hypervisor that changes address when the router restarts is a hypervisor you lose.
  3. Hostname and credentials. This machine became forge. The name spread through the whole project. The storage pool is forge-hdd, and the CI runner is forge-runner-01.

Fifteen minutes later, the machine restarts into a console screen with one URL. From that point, everything happens in the web UI on port 8006, from another machine.

A Deliberate Refusal to Partition Everything

Here is the first decision I defend in any review. The installer touched only the OS disk. It is tempting to configure all the storage while the installer is open. Pull the big drives into a pool, allocate everything, feel productive. I did not, and the restraint was the point.

The disk plan already existed on paper:

Device Purpose
SSD 1 Proxmox OS
SSD 2 Fast storage for the Docker LXC and databases
2 x 6TB HDD ZFS mirror (forge-hdd) for backups, media, photos, documents

But a plan sketched before the platform exists is still untested. The ZFS mirror and the SSD container storage arrived as separate, deliberate steps: after the hypervisor was stable, and before any service landed. Each layer got its own test, and each layer got its own documentation as it went in.

The general lesson sits in my build notes with a weary tone: configure storage before you install many services. Every service that lands before the layout is final is a service you migrate later. I got this mostly right. The one media service that landed before the HDD mount was ready still cost an evening of bind-mount repairs.

First Housekeeping in the Web UI

A stock Proxmox install needs about twenty minutes of housekeeping before it holds anything you care about:

  • Repositories. Without a paid subscription, the enterprise package repository fails on every update. Switch to the community (no-subscription) repository — the web UI can do it without a configuration file. Then run updates, because installer ISOs are always behind.
  • The subscription dialog. Proxmox shows a “no valid subscription” dialog at login. It is harmless. Treat it as the price of free software and click past it. Do not chase patch scripts that remove it and then break on every upgrade.
  • Backups before experiments. Another early lesson from the build log: configure backups before serious experiments, not after. Once the backup storage existed, a scheduled Proxmox job backed up the whole Docker container. Every risky change since then came with the quiet confidence of a person who can restore yesterday in minutes.

Two commands cover the repository switch, and both run in the Proxmox shell:

# Disable the enterprise repo that fails without a subscription
sed -i 's/^deb/# deb/' /etc/apt/sources.list.d/pve-enterprise.list

# Add the community repo, then update
echo "deb http://download.proxmox.com/debian/pve $(. /etc/os-release && echo "$VERSION_CODENAME") pve-no-subscription" \
  > /etc/apt/sources.list.d/pve-no-subscription.list
apt update && apt full-upgrade

One small real-world note from those first days: the Proxmox mobile UI is limited. It is useful for a glance at container status. It is miserable for real administration. Do the setup from a proper machine.

What This Stage Delivered

At the end of this phase, the platform was almost aggressively unimpressive. One machine, one hypervisor, an empty web UI, and three untouched drives. No dashboard, no Git server, no AI anything.

But the shape of everything after was set. Proxmox meant LXC containers for the Docker layer, and full VMs when the web work arrived later. The untouched disks meant the storage got designed, not accumulated. The backup-first habit meant the experiments that followed never put the platform itself at risk. None of it was interesting to look at, and that was the intent.

Next in the Series

With the hypervisor stable, the next job is the one the installer skipped: the disks. Part 3 covers the storage layout — the forge-hdd ZFS mirror from the two 6TB drives, SSD-backed fast storage for containers and databases, and the rules that decide which data lands on which tier.

Next: Part 3 — Storage Layout with a ZFS Mirror and SSD Tiers

Back to all posts