Infrastructure journal / September 2026

Twice the Stack.
One Node
Off the Grid.

Two independent server clusters. A broader AI fleet. And one real worker in remote Nevada, on a solar-and-battery power system. Here’s what we built—and what the instruments actually show.

Real monitoring capture: five hosts across locations—not five solar-powered Nevada machines. Click to inspect.
01 / More capacity. A different frontier.

Repeat the stack.
Rethink the edge.

Growth isn’t always a bigger box. Sometimes it’s another well-defined system—and the discipline to keep its boundaries clear.

Our original on-premise build centered on a three-node Proxmox cluster. The September infrastructure update documents two independent three-node stacks: six AMD Ryzen 9 9955HX machines, with 96 GB of RAM per node.

That doubles the documented cluster footprint from three nodes to six. It does not establish twice the speed, twice the throughput, or a benchmark result.

Meanwhile, a separate off-grid worker is now visible in Nevada. Its power story is compelling precisely because we can show the readings without pretending they answer every question.

02 / Documented cluster footprint

Two stacks.
Not one stretched cluster.

2Independent Proxmox stacks
6Ryzen 9 9955HX cluster nodes
96Physical cores / 192 threads
576GB installed cluster RAM

Documented hardware totals, not a live capacity test. The five hosts in the monitoring screenshots below are a different system and are not added to these figures.

STACK 013 × Ryzen 9 9955HX288 GB · own Ceph poolINDEPENDENT CLUSTERSTACK 023 × Ryzen 9 9955HX288 GB · own Ceph poolINDEPENDENT CLUSTERNEVADA WORKERSeparate monitored host8 cores / 16 threads · 11.5 GiBSEPARATE POWER / LOCATIONSTACK 013 × Ryzen 9 9955HX288 GB · own Ceph poolSTACK 023 × Ryzen 9 9955HX288 GB · own Ceph poolNEVADA WORKERSeparate monitored host8 cores / 16 threads · 11.5 GiB

A repeatable building block

Each three-node stack has its own quorum, Ceph storage pool, and dedicated switch. Expansion adds another independent unit instead of making one cluster responsible for everything.

Isolation is a design goal, not a magic shield

Separating cluster membership and storage limits shared dependencies at that layer. It does not eliminate site, upstream network, power, software, or operating risks. No unconditional uptime or zero-downtime promise is implied.

6 DGX Sparks

Dedicated inference hardware in the September inventory.

~24 mini PCs

Browser use, computer use, and agent-controlled desktop work.

5 laptops

Supporting video processing and CPU-heavy agent tasks.

These are inventory categories across the wider deployment, not Nevada-site counts or measured utilization. Hardware inventory and monitoring coverage are different views.

03 / The screenshot system

One in Nevada.
Four in Patterson.

A node’s name is not its location.

The dashboard’s site assignments put only Off-Grid Server onsite in Nevada. Nodes 02–05 belong to the Patterson Cluster in this capture, even though their names contain “offgrid.”

NEVADA / OBSERVED HARDWARE
8 cores / 16 threads

11.5 GiB measured RAM

One onsite monitored host. The other four each report 8 cores, 16 threads, and about 11 GiB of RAM, at Patterson—not on Nevada’s battery bank.

Node-level capture: Off-Grid Server is Nevada; Nodes 02 and 03 are Patterson. The 6.9 W reading is the mapped mini-PC outlet, not CPU or whole-site power. Click to inspect.
Five monitored hosts ≠ five Nevada workers.

The screenshot-wide totals are 40 physical cores, 80 threads, 55.3 GiB measured RAM, and 44.9 GiB available at that moment. They describe these five monitored hosts only—not the two Proxmox stacks.

04 / Follow the wire

Off-grid is a power architecture.
Not an autonomy claim.

Solar collection, charge controllers, a battery bank, and separate inverter circuits form the physical story. The monitoring story is narrower: some branches report, others don’t.

The equipment map is valuable because it makes those limits visible. South PV is isolated. Controllers report only partially. An auxiliary branch is unmetered. A disconnected monitoring device does not mean the connected equipment has no power.

Physical power map: 40.9 W covers two reporting outlets—mini PC 9.9 W and Starlink 31.0 W. Battery 98% uses 8 of 9 fresh BMS readings. South PV is isolated. Click to inspect.
The useful question isn’t “Can we put a computer in the desert?” It’s “Can we tell what is powered, what is measured, and what remains unknown?”

6.9 W is one instant, at one outlet.

The node card’s mapped mini-PC meter reports 6.9 W. That is whole-outlet draw at the capture time—not CPU power, not the complete off-grid system, and not a basis for an annual operating-cost claim.

40.9 W is another view, at another time.

The power map reports 9.9 W for the mini PC and 31.0 W for Starlink. Those partial outlets total 40.9 W. We do not add the separate 6.9 W capture to it or describe either as whole-ranch consumption.

05 / Night readings, daylight estimates

98% battery.
Still not a runway.

A nearly full gauge is reassuring. It is not a guarantee of how long a worker can run.

The reported state of charge is partial: eight of nine BMS readings. Without complete capacity, load, and operating-history evidence, we cannot responsibly turn that into hours or days of autonomy.

0 W observed solar

This is a nighttime capture, with South PV disconnected. Zero measured solar at night is not a daytime production result.

4.4 kWh forecast—not harvested energy

The chart marks its outlook as low confidence and uses a regional weather reference. That number is neither stored energy nor a measured daily yield. The displayed 35 W load is another partial-circuit reading, not a whole-site total.

Nighttime dashboard: 0 W observed solar; 98% reported battery with partial BMS coverage; 4.4 kWh low-confidence forecast. The blue curve is an estimate, not measured production. Click to inspect.
What would make the next update stronger?

Complete metering coverage, synchronized power readings, measured energy over time, and workload records tied to actual jobs. Those are the missing pieces—not claims we have already proven.

06 / Keep the history. Label the changes.

March was the blueprint.
This is the update.

The original infrastructure article remains available as the historical baseline. It describes the initial three-node build and the independent-stack expansion model.

The diagrams below are historical planning illustrations. They are not current telemetry, present-day pricing, or a workload-capacity guarantee.

Read the original infrastructure story →

The people behind the machines

Jeff J Hunter leads the service strategy, infrastructure oversight, and the connection between these systems and the jobs businesses need done.

Brandon, Developer & Network Engineer at Belew Consulting, designed and implemented the infrastructure architecture, including the node strategy, networking, and repeatable provisioning approach.

Hardware creates room to operate. Clear roles, maintenance, review, and a human team turn that room into a useful service.

View the historical within-stack upgrade diagram
Historical / conceptual: storage expansion within a stack. Original planning figures are not current pricing or a service guarantee. Click to inspect.
Built for the work behind your business

You shouldn’t have to
run the server room.

Start with the role you need filled. We’ll help define the AI Employee, its responsibilities, and the human review that makes the work useful.

Source & scope

Based on the owner-supplied infrastructure summary, its September 2026 inventory update, and five real monitoring captures from September 10, 2026. The original confidential source document is not published here. Screenshots are static evidence, not a live feed. Exact addresses, private endpoints, customer counts, and internal routing details are intentionally omitted. “Twice” refers to the documented three-to-six-node cluster footprint, not performance. No AI-job completion, autonomy, cost savings, or SLA is established by these captures.

Share this field noteLinkedInX
Beau, VA Staffer's AI Employee
Built by Beau

This page was created by Beau, VA Staffer's AI Employee.

Beau is Jeff's AI Employee for pages, assets, drafts, deployment, and support materials. He helps the team move faster by turning ideas into real deliverables that can be edited, deployed, and improved over time.

Get an AI Employee →