TrueNAS Hardware Sizing: RAM, HBA, NIC and Boot Disk

Most TrueNAS build advice circulating online is answering a question the documentation stopped asking. The “1 GB of RAM per terabyte of storage” rule that appears in nearly every forum thread is not what the current hardware guide says. The 50% ceiling on ZFS ARC that shaped a generation of memory recommendations stopped applying in April 2024. And a large amount of build-list folklore was written for TrueNAS CORE, which no longer exists as a separate product.

This is what the current documentation asks for, where each number comes from, and which of these decisions are expensive to reverse once disks are in the machine.

Check which release you are building for

Hardware guidance ages badly because the platform underneath it changed twice in two years. The release map matters before any of the numbers do.

Release	Codename	Apps backend	Status
23.10	Cobia	Kubernetes (k3s)	Archived
24.04	Dragonfish	Kubernetes (k3s)	Archived
24.10	Electric Eel	Docker	Archived, final update August 2025
25.04	Fangtooth	Docker	Maintenance
25.10	Goldeye	Docker	Stable, recommended
26	—	Docker	Early release, currently 26-BETA.2

TrueNAS 25.04 “Fangtooth” was the release that unified the FreeBSD-based CORE line and the Linux-based SCALE line, and iXsystems’ own announcement of it states that “TrueNAS SCALE is now officially known as TrueNAS Community Edition” and that “the unification of CORE and SCALE is complete”. The version status page lists 25.10 “Goldeye” as the recommended release for general users, with 25.10.6 published on 12 August 2026, and TrueNAS 26 still an early release.

The practical consequence for hardware: advice that assumes FreeBSD driver support, or that assumes Kubernetes-based apps, is describing a machine you cannot build today. If a guide mentions k3s, it predates the Electric Eel release in December 2024 and its memory maths is out of date. The move from k3s to Docker changed how much overhead the app layer carries.

The documented minimum, and why nobody builds it

The TrueNAS hardware guide states the floor plainly: any x86_64-compatible Intel or AMD processor, 8 GB of memory, a 20 GB SSD boot device, and two identically-sized devices for a single storage pool.

That is a genuine minimum for getting the system installed and serving files. It is not a target. Every workload that people actually buy a NAS for pushes at least one of those numbers upward, and the guide says so itself in the sections that follow.

Memory: the per-drive rule, not the per-terabyte rule

This is the number most often quoted wrongly. The hardware guide bases memory on drive count, not capacity:

8 GB covers basic operation with up to eight drives.
Add 1 GB for each drive beyond eight.

So a twelve-bay chassis lands at roughly 12 GB by the documented rule, whether those twelve drives are 4 TB or 24 TB each. The per-terabyte version of the rule survives in forum lore because it happened to produce sane answers on the small drives of a decade ago. On modern high-capacity disks it produces absurd ones: a 240 TB pool does not need 240 GB of RAM.

Specific workloads carry their own additions, and these are where real requirements come from:

Workload	Documented memory guidance
Base file serving, up to 8 drives	8 GB
Each drive past the eighth	+1 GB
iSCSI block storage	16 GB for good performance, 32 GB or more for optimal
L2ARC cache device	About 1 GB of RAM per 50 GB of L2ARC (conservative)
Deduplication enabled	Roughly 5 GB per TB of stored data

Two of those deserve emphasis. An L2ARC device is not free: it consumes RAM to index itself, so adding a 1 TB cache SSD to a memory-starved system makes performance worse rather than better. The guide suggests sizing L2ARC between 5x and 20x the system RAM, which means the RAM has to be there first. Deduplication is the single largest memory multiplier in the list, and the reason most home and small-office pools should leave it off.

ARC no longer stops at half your RAM

Older SCALE releases capped the ZFS Adaptive Replacement Cache at 50% of system memory, a Linux-side default that made SCALE noticeably slower than CORE on identical hardware. TrueNAS SCALE 24.04 “Dragonfish” removed that cap and brought ARC allocation in line with CORE. Cobia was the last release where the 50% limit applied, and no manual zfs_arc_max tuning is needed on Dragonfish or later to exceed it.

Two things follow from that, and both surprise people building their first modern system.

First, a healthy TrueNAS box reports very little free memory. ARC expands to fill what is available and releases pages back under pressure. A dashboard showing 90% memory used is the cache doing its job, not a leak.

Second, ARC and container apps now compete for the same pool of memory. On a machine running a dozen apps alongside storage, the apps take their share first and ARC absorbs whatever is left. That is the argument for buying more memory than the drive-count rule suggests: not because ZFS demands it, but because everything else on the box is taking a cut before ZFS sees it. The TrueNAS sizer on this site estimates that combined figure from drive count, app count and concurrent share users, which is a workload-comfort target built on top of the documented per-drive floor.

OpenZFS exposes zfs_arc_max and zfs_arc_min as module parameters if a specific ceiling is needed, for instance to guarantee headroom for a memory-hungry virtual machine. Setting them is a deliberate act with a reason behind it, not a default step.

ECC memory: recommended, not required

The hardware guide’s position on ECC has been consistent and is worth quoting rather than paraphrasing: ECC RAM is recommended for all OpenZFS systems as another data-integrity defence, and many TrueNAS systems operate every day without it.

That is the whole answer. ECC corrects single-bit errors in memory before they reach the pool. ZFS checksums protect data on disk, not data in flight through RAM, so ECC closes a gap the filesystem cannot close by itself. Whether the gap matters depends on what the pool holds and how long it has to survive. It is not a prerequisite, and treating it as one has talked plenty of people out of building a NAS at all.

If ECC is on the list, it constrains the platform choice: it requires a CPU, chipset and motherboard that all support it, which in practice means a server or workstation platform rather than a consumer desktop board.

The storage controller is the decision to get right

Of everything here, this is the choice that is genuinely hard to undo, because the wrong controller hides disk state from ZFS permanently.

The hardware guide asks for 6 or 12 Gbps Broadcom SAS host bus adapters, flashed with IT or Target Mode firmware to disable the optional RAID functionality present in IR firmware. Where a hardware RAID card is unavoidable, the guidance is not to use or configure its RAID facility.

The reason is structural. ZFS is the volume manager. It expects to see each physical disk, its SMART data and its error counters directly. A RAID controller that presents a logical volume, caches writes in its own battery-backed memory, or silently remaps sectors is making storage decisions that ZFS also thinks it is making, and the two disagree in ways that only show up during a failure.

Card options split into two families. The 6 Gbps LSI 9211-class cards and their rebranded siblings are long-established in this role and widely available second-hand, though listings for them are almost entirely third-party resellers of the same OEM board with inconsistent firmware and cabling, so the seller matters more than the price. Broadcom’s newer 9400 and 9500 series cover 12 Gbps SAS. Broadcom’s own host bus adapter product line is the reference for which model covers which port count and generation.

Whichever card arrives, confirm the firmware mode before building a pool on it. A card in IR mode with RAID volumes configured is not an HBA, regardless of what the listing said.

Boot device

A 20 GB SSD is the documented minimum. Boot devices are cheap and the configuration on them is not the data, so this is not a place to spend heavily, but two rules apply.

Do not put apps or data on the boot pool. The apps pool belongs on the data pool, and putting it on the boot device removes the redundancy and snapshot coverage the rest of the system depends on.

Export a copy of the system configuration off the machine. TrueNAS keeps its configuration in an exportable file, and a failed boot device is then recovered by reinstalling, restoring that file and importing the existing pool. That recovery path is what makes a single non-redundant boot SSD an acceptable risk. Without the exported configuration it is not.

Disks

Pool layout matters more than drive model, and vdev shape is the part that cannot be changed later. That decision is covered separately in planning pools, datasets and shares.

On the drives themselves, the constraint that matters is recording technology. Shingled magnetic recording overlaps tracks to raise density, which makes random rewrites slow and turns a ZFS resilver into a multi-day event on a drive that would otherwise finish in hours. NAS-labelled lines are where the CMR models live: Western Digital’s WD Red Plus and Seagate’s IronWolf ranges both publish their recording technology per capacity, which is the specification to check before ordering rather than after. Both lines span many capacities, so buy from the capacity table rather than from a generic product link.

Network

The hardware guide’s networking advice is short and often ignored: faster individual interfaces such as 10, 25, 40 or 100 GbE are preferable to aggregating slower ones, and Intel and Chelsio interfaces are the best-supported options.

Link aggregation across four 1 GbE ports does not give one client 4 Gbps. It gives four clients a gigabit each, at best, and only when the hashing algorithm cooperates. A single 10 GbE link removes that entire class of problem, and it is the point at which a pool of spinning disks rather than the network becomes the limit on sequential throughput.

For copper 10 GbE on a standard PCIe slot, the Intel X550-T2 is the dual-port card that matches the guide’s driver-support preference and runs over ordinary Cat6 rather than requiring optics. Its main practical advantage is not performance but identification: the market is full of third-party cards built on the same X550-AT2 controller with varying firmware, and matching the Intel part number avoids that lottery.

Whether 10 GbE is worth it depends entirely on the workload. Serving media to a handful of clients saturates nothing. Editing video off the array, running iSCSI datastores, or replicating between two systems on a schedule all hit the gigabit ceiling immediately.

A build order that avoids rework

Pick the release first, then check that every component has current Linux driver support.
Count drive bays, not terabytes, for the base memory figure, then add for apps, iSCSI or deduplication.
Choose the controller before the case, because port count and cabling constrain the chassis.
Confirm HBA firmware mode before creating any pool.
Decide pool topology before the first byte lands, because vdev shape is fixed afterwards.
Export the system configuration off the machine, then verify the restore path once.

Steps four and five cost real time when skipped. Everything else here can be changed later with a screwdriver.

Once the machine runs, the next decisions are software: how the app layer works after the move to Docker, and what it takes to run a service the catalogue does not ship, such as a CUPS print server.