AmeriBrit 20U Rack
Media / Game / Cloud

What it is actually suited for

The constraints decide this more than the CPU does. No PCIe, no 3.5″ bays, one 2.5″ bay, 32 GB ceiling, ~10–30 W. That rules out anything storage-shaped and anything wanting a card.

What it leaves is compute in a small envelope — a Docker host, a second Pterodactyl node if the game server ever needs one, a staging box for the panel before changes reach the VPS, or a DNS/Pi-hole and light services box.

Two jobs it should not take. Anything the N2+ already owns — NUT, sensors, Home Assistant — because splitting those across two boxes doubles the config and halves the clarity. And anything holding data that matters, since there is one bay and no redundancy in it.

It is also the obvious eventual replacement for the FX-6300, on roughly +33–40% single-thread and a fraction of the draw. That is a decision for when the FX gives trouble, not now.

Answer these before spending anything on it

One teardown plus one boot settles all of it, and none of it is worth doing until it has a job.

The caddy is the one that bites. HP Desktop Minis configured M.2-only frequently shipped without the 2.5″ bracket and its SATA/power cable. It is a separate HP part at roughly $15–25 used, and without it a 2.5″ drive has nowhere to mount. Check it before ordering any drive for this box.

Not to be mistaken for a fault: on some Desktop Mini models HP firmware throws a boot warning when a 2.5″ drive is fitted without the caddy's cooling fan. Dismissable, machine runs fine.

A healthy OEM NVMe may mean no boot drive purchase at all. Worth the thirty seconds before assuming a spend.

Racking it, if it ever earns a U

Not placed in the elevation. A box with no job does not get a rack position reserved for it — that is how spare U quietly disappears. It would take 1U in the printed mount, and the sheet's spare 1U at U15 is the obvious candidate.

The print is Printables 658936, already on the print list as conditional. It was designed around the 800-series bezel and this is a 705 — same 1 litre chassis, and the commercial ModMount family covers 705 G3–G5, so it should fit, but the front port layout differs. Check the facade cutouts against the machine before committing filament.

Placement rules if it lands: not directly above the media server's rear 80 mm exhausts, and leave the U above it clear unless whatever sits there has an open bottom. On the 65 W build the perforated top is a primary intake — stacking on it chokes the machine, and a printed sleeve that covers it is a larger threat to cooling than any workload.

Power would come off the BR1000MS alongside the game server and the N2+. At ~10–30 W it is noise against that unit's ~194 W.

Worth doing whenever it is next open

Independent of role, and cheap while the lid is off:

The fin stack is the biggest single win on a used mini — dust packs where you cannot see it — and factory paste is 2019 vintage. MX-7 is already costed on the media server line and covers this too.

Free levers, and they are AMD ones. Fan profile to maximum cooling; HP's defaults assume a desk. Cap cTDP in BIOS if exposed, or use ryzenadj for STAPM/PPT limits on Linux — not intel_rapl or MSR 0x150, which are the wrong platform entirely. Raven Ridge has no undervolt offset interface, so power limits are the only lever.

Raven Ridge Tctl throttles at 95 °C, and sustained 75–85 °C under load is normal. Temperature alone is not a failure — only clock collapse is.

Storage ports and bays

The board has six SATA, but the M.2 socket disables SATA 5/6 when populated — and it is populated, since the SK Hynix NVMe is the boot drive. That trade is already made, not hypothetical. The GPU takes the only x16 slot, so an LSI HBA is off the table and the x1 SATA card is the workaround.

The five drives on hand fit with room left. They use six of seven bays and six of eight ports, so there is one bay for a sixth drive. After that, bays bind before ports do — the eighth port would have nowhere to put a drive.

Boot costs nothing in this budget: the NVMe sits on the board, using no port and no bay. Growing past six HDDs means the NAS, not this chassis.

19 TB raw, and no parity. Two 8 TB drives plus three 1 TB. Nothing here is redundant — a drive failure loses whatever was on it, which is the argument for the NAS running SnapRAID rather than the media server growing indefinitely.

The three 1 TB drives are worth reconsidering. Each costs a bay and a port to contribute 1 TB, and consolidating them into one larger drive would free two of each — the scarce resources in this chassis are physical, not capacity.

Power draw

750 W puts you near 43% load, right by the Gold efficiency peak. A 550 W would have saved $50 but leaves no room for a future GPU.

UPS headroom

The CyberPower is 1000 W and could carry all three at about 65%, with even a simultaneous cold boot inside the envelope. Note the 1500 VA figure is not the constraint — active-PFC supplies run a power factor near 1.0, so the 1000 W rating is what binds.

It should not have to. Moving the game server to the BR1000MS drops this to ~475 W and takes runtime from roughly five minutes to ten — see the office split below. The figures above are the all-on-one case, kept as the ceiling to design against.

Runtime, not capacity, is the limit either way. Ten minutes is a graceful-shutdown window, not a ride-through — worth wiring up NUT or apcupsd before you rely on it.

Adding the NAS later pushes typical toward 770 W, around 77%, which is where headroom starts to matter. The 2000 VA version of the same unit is $449.95, so about $90 buys that margin if the NAS is a certainty.

The misc server, if it is ever racked, is noise here. At ~10–30 W on the BR1000MS it moves that unit from ~194 W to at most ~224 W, still around a third of its rating. Worth knowing mainly because it means the decision to rack it never has to wait on power.

The interim APC is only 600 W. It carries the media server alone comfortably and two servers at idle with little to spare, but a simultaneous cold boot overruns it — exactly what happens when utility power returns after an outage. Until the CyberPower lands, stagger the boots in BIOS or run the game server straight off the wall. It is the one box whose sudden loss costs nothing.

Splitting the office load

Never plug one UPS into another. The downstream unit's charger looks like a nonlinear load with real inrush to the upstream one, most manufacturers forbid it, and the runtimes do not usefully add. Both office units hang off the wall independently.

Leaving the BR1000MS on 30 W of network gear wastes it. It is pure sine, so it is one of only two units in the house allowed to carry a server — and hours of network runtime buy little once the servers are already down. Put the game server on it.

The media server's runtime roughly doubles, from about five minutes to ten, which is the real prize. Both units land near half load, which is where their batteries last longest and run coolest.

The game server is the right one to move: it holds nothing that a sudden loss would damage, so pairing it with the older battery costs the least. Media and cloud — the two that hold data — stay on the newer, larger unit.

Both USB runs land on the N2+, so there is still only one shutdown path. Two units, two data cables, but one upsd and one master upsmon — every server is an identical slave pointed at U16. The simplicity that splitting the load used to cost has been recovered: you get the extra five minutes and one config.

The N2+ adds ~4 W to the BR1000MS, taking it from ~190 W to ~194 W. Not enough to restate the table.

Coming back up

Shutting down cleanly is the easy half. Coming back on is two separate settings, and neither is on by default.

1 · BIOS: restore on AC power loss. Set it to Power On, not Last State.

Last State reads as the safer option and is the wrong one here. NUT shut the box down cleanly, so the last state is off — and it stays off.

2 · The UPS has to actually cut its outlets. This is the step that gets missed. NUT's shutdown must finish by telling the UPS to drop the load, so it re-energises when mains returns — shutdown.return, issued by upsdrvctl shutdown at the end of upsmon's sequence.

Without it, the failure is specific: power comes back before the battery is flat. The outlets never de-energised, the servers never see an AC transition, and they sit there off until someone walks over and presses a button. A battery running all the way down does the right thing by accident — you do not want correct behaviour to depend on the outage being long enough.

Confirm each unit supports it before relying on it, because CyberPower's NUT load-shed support is less consistent than APC's: upscmd -l cyberpower should list shutdown.return.

3 · Test it the long way. Pull the plug and leave it — all the way down, outlets dead, then restore mains. Cutting the test short at "they shut down" only proves the half that was already easy.

Nothing on the monitoring panel can verify this. It sees a broken shutdown path; it cannot see a server that would never come back, because that only shows up during the one event you are building for.

WAN headroom

2.5 Gb down, 300 Mbps up. Only one of those numbers matters here: self-hosting spends upload. Every remote Jellyfin stream, every Immich share, every restic push leaves the house, so the 300 is the figure to plan against and the 2.5 Gb is close to irrelevant.

Which end binds depends on the stream, and that is new. For transcoded playback the RTX 3050 still runs out first — NVENC manages roughly 8–12 simultaneous 1080p encodes, and 300 Mbps would carry closer to thirty. But for 4K direct play the uplink now binds instead: no transcode means the GPU is not involved at all, and four to seven streams is the ceiling. Direct play is also the case a good client picks by default.

The path in is now 2.5 Gb the whole way, which changes what that download is worth. Both Netgears were replaced, so eero to edge switch to main switch runs at 2.5 Gb with nothing in the middle throttling it. An earlier revision of this sheet said the opposite; it was written when both switches were gigabit.

Individual machines are still capped near 940 Mbps, because every main-LAN NIC in the rack is gigabit — the 2.5 Gb cards are committed to the isolated storage island. No single server got faster. What changed is contention: two or three machines pulling at once now share a 2.5 Gb trunk instead of queueing behind one gigabit uplink, which is the case that actually shows up during a large download or a restic seed.

Everything else is noise: game servers are 10–50 kbps per player, Immich sync is inbound and bursty, restic is incremental after the first seed and runs overnight.

The mesh backhaul is no longer the thing to watch. Two wireless hops could hold the rack to 200–400 Mbps, which used to be a real haircut against a gigabit uplink — against 300 Mbps up it is roughly a wash. Confirming the backhaul is wired still matters for downloads and for the LAN, just not for what leaves the house.

Sizing the panel VPS

2 vCore, 4 GB, 40 GB NVMe at $5/month. The instinct is that 40 GB is tight for a metrics database. It is not the constraint.

Five agents now — three servers, the NAS when it lands, and the N2+. Even with the retention job never written, that is roughly 2.6 GB a year, or a decade of headroom on 40 GB.

Set retention before the first agent connects anyway — but for the right reason. It is an index-size and query-speed decision, not a capacity one, and being clear about which problem you are solving stops it being deferred as "we'll deal with it when the disk fills". The disk will not fill.

4 GB is comfortable for Postgres, Caddy and the panel itself. The panel is a Rust binary in the tens of megabytes resident, so the database gets essentially all of it. Two cores are idle most of the time: a handful of agents posting every 15 s and an alert sweep every 60 s is not a workload.

Two things would break this sizing, and neither is planned: shipping logs to the panel rather than just metrics, or keeping full-resolution history for a year instead of rolling it up. Both are disk problems, and both are decisions rather than surprises.

Airflow

One 120 mm in (~70 CFM), two 80 mm out (~80 CFM) plus PSU exhaust. Slightly negative pressure.

Not a thermal problem — intake pulls through the drive cage, cooling the HDDs on the way past. It is a dust problem: unfiltered air enters through every seam. Blow the chassis out every few months.

If the P12 Pro has to run loud to hold GPU temps, drop to one rear P8 Max. Less exhaust, closer to neutral, quieter.

PCIe slots

One x16 (GPU) plus x1 slots. Two cards want them: the SATA card and the dual-port NIC. That is the same count as before only because the NIC became a dual — the media server now needs 2.5 Gb on both the main LAN and the island, and two single cards would have made it three.

Prefer the x4-capable slot for the dual NIC. B450's x1 slots are PCIe 2.0, roughly 4 Gb/s, against 5 Gb/s if both its ports saturated simultaneously. In practice they will not, but if a slot with more lanes is reachable past the GPU, use it there.

Verify the exact slot count on your board before ordering either. If there is only one usable slot after the dual-slot GPU, something still has to give — most likely the SATA card, with bulk storage moving to the NAS instead.

10 GbE is not possible here. It needs x4 or x8. 2.5 G over x1 is the ceiling.

Fan control on Debian

The hub is a dumb splitter, so lm-sensors and fancontrol drive it through the motherboard header. The real obstacle is the Super I/O driver.

Nuvoton chips need acpi_enforce_resources=lax at boot. ITE chips need the out-of-tree it87 module via DKMS — the frankcrawford fork is the maintained one.

Run sensors-detect after the build. If pwmconfig finds no PWM outputs, that's the ACPI lock, not the hardware. Fallback: set a conservative fixed curve in BIOS and move on.

Wiring the fans

Cooler stays off the hub so it tracks CPU temp independently. The hub reports RPM from slot 1 only — put the intake there, since it's the fan whose failure matters most.

Every server is dual-homed

Onboard gigabit to the main switch for internet, SSH, web UIs and management. A second 2.5 Gb card to the island, where applicable, for NFS, Immich originals and restic.

Main LAN addressing is DHCP from the eero — reserve a fixed lease by MAC for every server so hostnames stay stable.

The N2+ is the exception, and deliberately so: one port, main LAN only. It has no storage traffic to carry, the island is gigabit-irrelevant to it, and a 5-port switch has nothing spare. It still needs the fixed lease — more than the servers do, since three NUT slaves resolve it by name.

The rack sits four hops out

Modem to Bedroom to Kitchen to the BrosTrend switch, which fans out to the Eufy HomeBase 3 and to the Office eero. The Office unit then feeds the whole rack.

That makes the BrosTrend a single point of failure for everything in the rack. It is a $38 unmanaged switch carrying the entire WAN path — if it dies, the rack loses internet even though every eero is still up. Worth keeping a spare in a drawer; it is the cheapest insurance in the build.

It is at least on battery, sharing the BE850M2 with the kitchen eero and the Eufy, so a power cut does not take it out. Note this is the second reason that unit matters more than its size suggests.

Worth confirming the backhaul is wired. These are dual-band, so there is no dedicated backhaul radio — on a wireless mesh each hop shares airtime with clients, and this far out the rack could see well under half the 1 Gb service. Wired, it is a non-issue.

Note there are two 2.5 Gb switches in play. The Kitchen BrosTrend is ordinary LAN and carries the rack's uplink. The rack one is the isolated island and must never be confused for it.

The telemetry path is protected end to end

This wasn't planned and it happens to be right, so it is worth stating as a property of the design rather than leaving it to luck: the N2+'s entire path out of the rack — main switch, edge switch, office eero — is already on the BR1000MS alongside the N2+ itself. The one machine that must keep reporting during an outage shares a battery with every hop it needs to do so.

Combined with the modem and both intermediate eeros upstream, the path from the N2+ to the VPS is on battery with no exceptions.

One ambiguity it does not solve. Because the link is wired-only, a dead main switch or a bad patch cable takes the N2+ off the network along with all four servers. The panel still catches it — five agents going quiet at once is unmistakable — but it cannot distinguish the rack is down from the switch is down, and those are very different 2am problems. A ~$10 USB wireless dongle associating to the office eero as a backup path would resolve exactly that. Against it: a second interface on a box whose job is to be simple, plus route metrics to get right so it never becomes the primary path. Left undecided on purpose.

One Homebridge constraint while it is in mind: HomeKit discovery is mDNS, so the N2+ must stay in the same broadcast domain as the phones and the eero-attached accessories. Flat DHCP from the eero across unmanaged switches satisfies that today. If the main LAN is ever segmented, Homebridge is the thing that breaks first and least obviously.

Cable colours

Blue for main LAN, server onboard NICs to the main switch. Green for the storage island. White or red for the eero uplink.

Uniform correct lengths matter more than cable spec. Avoid Cat 7 and Cat 8 — marketing labels at these speeds — plus flat cable, braided jackets, and anything not stating bare copper.

What this gives up

The gaming tower and every Wi-Fi client reach the NAS at 1 Gb, since they arrive through the edge and main switches rather than the island. Fine for occasional access, noticeable if you regularly pull large media off the NAS.

The fix is a 2.5 Gb card in the tower and a run to a reserved island port, or an 8-port island switch (~$60) to cover that and the future servers. Nothing here blocks either.

Throughput decides the board

A reverse proxy crosses the NIC twice per request, so effective throughput is roughly half of line rate. That single fact decides the board.

Both candidates clear the 300 Mbps upload with room to spare, which is the bar that matters: the proxy must never become the bottleneck instead of the connection. Anything on a USB-attached NIC rather than a native one fails that test, which is why the board choice is only between these two.

Before buying the fallback, work these four

Nearly every Pi 4 boot failure is one of these, and none of them is a dead board.

One diagnostic settles alive-or-dead: pull the SD card and power on. A green ACT LED flashing in a pattern means the board is fine and the problem is storage or image, not hardware.

The most likely outcome by a wide margin is that it boots and the fallback line is never actioned.

Placement and power

~5 W is negligible against the BR1000MS's existing load, and it belongs on the same battery as the network gear it depends on — a proxy running while its switch is dark is useless.

If it is later racked rather than shelved and the fallback N2+ was built, Printables 948730 fits it — a second copy of a print already proven by then, rather than a new unknown. Not required; the shelf has room.

Three bundles, one side each

Power runs down one rear post, data down the other, exactly as the build order calls for. Drawing them as one bundle per service is the point — a cable you can trace by colour and side is one you can unplug at 2am without tracing it at all.

Hovering a device dims everything else, which is the quickest way to see what a given box actually depends on.

The APC sits on the floor beside the rack rather than in it, so the game server, main switch and network shelf runs leave the frame at the bottom rear and terminate there. The 2U reserved for the second CyberPower stays empty until that swap happens.

Service loops are not drawn

Every run here is the straight-line path. Real ones need the 6–8″ of slack the build order specifies, so a chassis can slide out on its rails without unplugging.

That slack is why the 5 ft patch cables are more forgiving than the 1–2 ft the network design asked for, and also why they will coil behind the posts.

The network shelf

Three U, two trays, five devices — and width is now the binding constraint, not height. The main switch moved down here once it stopped being an 11″ Netgear, which handed a rack unit back and deleted a print. What it did not do is make everything fit on one tray.

That is why this is two trays rather than one. A 19″ shelf gives roughly 17.5″ of usable width between the ears, and the kit adds up to more than that — so the freed unit pays for a second tray instead of becoming spare. Two trays is ~35″ of run, which is comfortable rather than tight.

The 3U is clearance, not shelf thickness: the trays themselves are 1U each, and the extra unit exists because the eero stands taller than 1.75″. Worth stating plainly, because “we need a 3U shelf” would send you shopping for the wrong part.

Dropping the PDU paid for the second U. The bottom 2U is reserved for the second CyberPower rather than sitting empty. Everything still adds to twenty.

The N2+ took half of what used to be the spare 2U. The elevation summed to exactly twenty with no free U, so its mount had to come from somewhere: U16 for the N2+, U15 still genuinely spare. USB from U16 down to the CyberPower at U3–4 is roughly 4 ft internal, well inside the 5 m limit, and the BR1000MS sits on the floor at the same end.

The storage switch tray stays a separate print, and that was checked rather than assumed. Combining it with the N2+ mount into one 1U tray was considered and rejected: taking the island switch off the network shelf doesn't shrink that shelf below 2U, because the eero is taller than 1.75″ on its own. The combined tray would cost a real U instead of saving one.