The factory runs on real hardware.

From one box to a fabric

Yesod started life on a Lenovo P520c workstation on a home network. The next step is a Dell PowerEdge R740xd — and the interesting part is not the core count. The new server has three jobs:

1. Host the new Yesod — the control plane (dispatch, refinery, durable record) on dedicated, reserved capacity.
2. Run the runner pool — the isolated environments where coding agents execute bounded work.
3. Be a playground for agents to make their own tests — replaceable VMs where an agent can spin up a complete miniature factory, break it on purpose, and prove something.

The hardware, at a glance

Area	Planned configuration
chassis	Dell PowerEdge R740xd 24SFF, 2U, iDRAC9 Enterprise
compute	2× Intel Xeon Gold 6152 — 44 cores / 88 threads
memory	8× 32 GB DDR4-2666 ECC — 256 GB total
boot	2× Intel D3-S4510 240 GB SATA SSDs, mirrored
workload storage	2× NVMe on PCIe adapters; mirror recommended
network	2× 10GBASE-T plus 2× 1GbE
power	2× 1100 W redundant PSUs; 1500 VA / 1000 W UPS
placement	a secure table in a ventilated laundry-room alcove; rack deferred

Committed build cost so far: $2,496.48, plus a $320 NAS restructure tracked separately. A factory does not require a data center.

The most valuable resource is not CPU

The design record puts it plainly: what the server really provides is safe, realistic, disposable state.

Yesod’s hardest failures cross PostgreSQL, Dolt/Beads, Git refs, runner processes, worktrees, and telemetry all at once. A fast shared test database cannot reproduce those boundaries honestly, and many parallel tests against one shared environment create their own races. So instead of one enormous mutable development machine, the server becomes a pool of factory cells — each a miniature, isolated Yesod with its own databases, Git remote, filesystem, process namespace, and telemetry identity:

                 New PowerEdge / Proxmox L0
                            |
      +---------------------+------------------------+
      |                     |                        |
      v                     v                        v
observability VM       agent playground VMs      broker-created
SigNoz + ClickHouse    Docker inside each VM     sibling full VMs
                            |
                            +-- factory cell 001
                            +-- factory cell 002
                            +-- factory cell ...
                            +-- factory cell N

Every cell is created from one immutable manifest — candidate SHA, fixture digest, fault schedule, random seed, deterministic clock, resource budget, telemetry namespace — and is destroyed after use, retaining only the bounded evidence needed to reproduce a failure. The core principle:

Isolation comes before parallelism; durable gate ownership comes before agent patience.

Why: the lesson of a timed-out worker

During one recovery incident, five clean commits existed — but the coding worker spent the end of its lease running a 13-minute serial acceptance suite and timed out before its normal handoff. More CPU would not have fixed that; the problem was authority. With a durable external gate the sequence changes:

coding agent commits and publishes exact tip
  -> durable acceptance request owns the long tests
  -> agent exits without waiting for the full suite
  -> isolated cells test the immutable tip in parallel
  -> gate records terminal evidence independently of the agent lease
  -> refinery consumes only the exact tested candidate

The same cells can replay real incidents hundreds of times with faults injected at every external-effect boundary — the kind of testing that finds fence and recovery gaps before they page anyone.

Three tiers of isolation

Not every test deserves a whole VM. The common path stays fast; fidelity is available when the scenario demands it.

Tier	Isolation	Best use
schema cell	unique PostgreSQL schema plus isolated fixture IDs	fast unit and ordinary integration suites
service cell	dedicated PostgreSQL and Dolt processes plus a bare Git remote	transaction, lock, and crash-replay tests
full factory cell	dedicated VM/MicroVM with its own namespace, services, and network	production-shaped incident replay and deployment testing

Agents get root-equivalent Docker authority inside an assigned playground VM — never on the Proxmox host. Tests that need a complete VM go through a quota- and TTL-enforcing broker that owns leases and cleanup. Containers, VMs, and the existing MicroVM merge gate are tiers of one cell contract, not competing control planes.

The road there

Delivery is phased, each with an acceptance gate of its own: benchmark and reserve resources → a minimal service cell that provably leaves no orphans → the external acceptance farm (a green result bound to the exact candidate SHA, surviving the requesting agent’s death) → an incident-replay corpus → fault, property, and mutation testing → operator-grade telemetry where every failed gate links to its exact cell manifest and seed, no SSH required.

This page adapts the internal design record (ROADMAP/YESOD-NEW-SERVER.md, opened 2026-08-14 — an exploratory direction; the hardware is committed). Track it as an initiative on the roadmap.