TrueNAS System Requirements & Recommended Hardware

This guide covers the component choices for a home TrueNAS build: CPU, ECC support, HBA, data and boot drives, networking, power supply, cooling, and bay count. It compares the vendor minimums with practical buying targets and explains which upgrades matter. Workload-specific memory calculations for apps, virtual machines, iSCSI, directory services, L2ARC, and deduplication are covered in the TrueNAS RAM requirements guide.

The hardware that matters most, in order, is:

• RAM: 16 GB floor, 32 GB comfortable, with ECC if the budget allows.
• HBA: an LSI HBA flashed to IT mode, never a hardware RAID card.
• Drives: CMR NAS-grade drives, not SMR.
• Power: an efficient 80 Plus Gold PSU sized for 24/7 operation.

CPU speed, 10 GbE, and SLOG/L2ARC matter far less than the community often claims.

TrueNAS system requirements: the official minimum

iXsystems publishes a hard floor for TrueNAS Community Edition (SCALE) in the SCALE Hardware Guide: a 2-core 64-bit CPU, 8 GB of RAM, a 16 GB boot SSD, and two identically sized data drives. It is lower than most forum advice implies, and it means “this boots and serves files” rather than “this is pleasant to live with for five years.” Community Edition and SCALE are one product under two names, not two hardware targets. TrueNAS Community Edition vs SCALE covers what the rename changed, which matters here only because older hardware pages are still written against the SCALE name.

Written out in full, as the 25.10 hardware guide publishes it, that floor is four lines long:

These minimums describe basic operation. The following home-build targets are editorial recommendations for additional capacity and workload headroom:

The rest of this page is the buying argument that sits on top of those numbers.

Two things that are not on the vendor’s minimum list but are effectively mandatory in practice: drives must be CMR rather than SMR, and the controller must present disks directly to ZFS rather than hiding them behind hardware RAID. Both are covered below.

RAM capacity as a buying constraint

The vendor floor is 8 GB. For parts selection, the motherboard should leave room for the intended workload:

• 16 GB is the sensible minimum for a small NAS you actually use.
• 32 GB is comfortable once apps like Jellyfin, Nextcloud, or Immich are running.
• 64 GB+ if VMs share the box with storage.

The ARC uses otherwise available memory as a read cache, so capacity beyond service requirements is not necessarily idle. Cache-specific adjustments are covered in ZFS performance tuning: ARC and recordsize.

What actually matters

1. RAM, in two dimensions: capacity and ECC

Capacity is covered in RAM capacity as a buying constraint above: 8 GB official floor, 16 GB realistic minimum, 32 GB comfortable, 64 GB+ with VMs. The second dimension is error correction, and it is the one people argue about.

On ECC: ECC (Error-Correcting Code) RAM catches and corrects single-bit memory errors. Non-ECC RAM does not. ZFS does end-to-end checksums on data, but those checksums are computed in memory. A bit-flip in RAM before the checksum is computed will result in a “correct” checksum for already-corrupted data, and ZFS will dutifully write that data to disk and replicate it.

Recommendation: prefer ECC when the CPU and motherboard explicitly support it. Confirm the supported memory type in the board’s documentation. ECC does not replace independent backups, and the TrueNAS hardware guide recommends checking memory before deployment regardless of its type.

2. HBA, not RAID controller

ZFS wants direct access to disks. It needs to see SMART data, write its own metadata, and manage redundancy itself. Hardware RAID controllers hide all of that behind the controller’s own abstractions, and ZFS cannot do its job correctly behind one.

The community standard is a flashed LSI HBA, typically an LSI 9207-8i, 9300-8i, or 9305-16i flashed to IT (Initiator Target) mode. These are inexpensive on the used market, support 8 to 16 SAS/SATA drives per card, and present the disks directly to the OS.

What to avoid:

• Hardware RAID cards that cannot be flashed to IT mode (older Dell PERCs without IT firmware, Adaptec, some HP cards).
• USB-attached disk enclosures for primary pool storage. USB is unreliable for sustained SATA-style workloads and ZFS detection of misbehaving USB devices is poor.
• Port multipliers and SATA expanders. They share bandwidth and confuse SMART reporting.

If your motherboard’s SATA ports suffice for the drive count you need, you do not need an HBA. The HBA is for when you outgrow the chipset’s port count.

3. Drives

Drive selection involves more religion than engineering, but a few things are concrete:

• CMR (Conventional Magnetic Recording), not SMR. SMR drives are deceptively cheap and are catastrophic for ZFS resilvers. The problem drew public scrutiny after one major manufacturer shipped SMR drives in its “NAS” line without disclosing it. Confirm CMR before buying. Manufacturer datasheets are the only source of truth here.
• NAS-grade drives (WD Red Plus/Pro, Seagate IronWolf/IronWolf Pro, Toshiba N300) have firmware tuned for 24/7 operation, longer error-recovery timeouts (TLER/ERC), and vibration tolerance. The price premium over desktop drives is small enough to be worth it.
• Mix manufacturing batches. If you buy six identical drives from one batch, they will tend to fail in lockstep. Buy from two retailers, or buy in two batches a month apart.

For SSDs in a ZFS pool, power-loss protection (PLP) is worth seeking out for any drive used as a SLOG. Consumer SSDs without PLP are fine for general pool members and L2ARC, but a SLOG without PLP defeats most of the safety guarantee SLOG is meant to provide.

4. Power supply and cooling

A NAS runs 24/7 for years. The PSU is the unsexy component people skimp on first and regret later.

• Use a 80 Plus Gold or Platinum rated PSU. The efficiency premium pays for itself over years of 24/7 operation and the build quality on these tiers is consistently better. The hardware guide’s own worked example is a useful sanity check: a Platinum unit costing $50 more than a comparable Gold “should save you at least $10 per year on your power bill for that investment to pay off over five years,” which only holds if you know the machine’s real draw rather than guessing at it.
• Size appropriately, not aggressively. A NAS pulls 40–80 W at idle for an 8-drive system. A 750 W PSU is more than enough; a 1200 W PSU runs at very low load and is less efficient at that load point.
• Active cooling for drives matters. Spinning drives running consistently above 45°C have shorter lifespans. A single front intake fan that pushes air across the drive bays is enough for most cases. Check temps via S.M.A.R.T. after first boot and adjust if needed; the scrub and S.M.A.R.T. disk health guide explains which attributes to watch and how to schedule the tests.

What matters less than people say

CPU performance

A home NAS does not need a fast CPU. Even with ZFS doing checksums, compression (LZ4 is essentially free on modern CPUs), and the occasional scrub, an entry-level desktop CPU from the last decade handles a 4–8 disk NAS without breaking a sweat. Where CPU does matter:

• If you run media transcoding (Plex, Jellyfin) on the NAS. Then you want an Intel CPU with QuickSync (recent generations) or a discrete GPU passed to a VM/app.
• If you run many apps and VMs on the NAS. Then you want core count.

For pure storage, an i3 or Ryzen 5 is overkill. Core count is rarely the constraint; the characteristics the hardware guide actually calls out are:

• Clock speed for SMB. Samba is lightly threaded, so a higher-frequency CPU with fewer cores usually wins on SMB-only workloads.
• Core count for encryption and virtualization, which parallelise well.
• AES-NI, which accelerates both filesystem and network encryption.
• SHA extensions (Intel Goldmont and later, Ice Lake and later, Rocket Lake and later, AMD Zen and later), which accelerate ZFS checksumming.
• VT-d or AMD-Vi if you intend to pass PCIe devices through to virtual machines.
• ECC support, which on the Intel side generally means a workstation or server chipset such as W680 rather than a consumer board.

10 GbE networking

Useful if you have a multi-machine workflow that moves large files. Not useful if your access is one Macbook on Wi-Fi pulling a 4K stream from Jellyfin. Add 10GbE when you have a documented bandwidth ceiling you are hitting, not preemptively. When you do add it, Intel X550-T2 or Mellanox ConnectX-4 Lx on the used market are the standard cards.

SLOG and L2ARC on day one

SLOG (separate intent log) is only useful for synchronous writes: NFS-shared VM datastores, iSCSI block targets, and databases. For a typical home file server using SMB, sync writes are rare and SLOG does nothing.

L2ARC (read cache on SSD) is only useful when your working set exceeds your ARC and you have read patterns that benefit from caching. On a NAS with 32 GB+ of RAM serving a typical home workload, L2ARC adds little.

Skip both on day one. Add them later if you can measure a specific bottleneck.

Turn the requirements into a parts list

Match the CPU, motherboard and memory from the board’s compatibility lists. Count SATA ports, PCIe slots and drive bays together, then reserve a separate boot SSD. Use the targets above to budget memory and data disks. The budget NAS build provides a concrete parts example; verify current specifications before buying.

How many bays and how much capacity to plan for

The most common over- and under-builds both come from guessing at capacity. Two rules keep the build honest:

• Buy bays you will grow into, not capacity you might use. ZFS cannot easily widen a RAIDZ vdev’s disk count after creation (RAIDZ expansion exists in recent OpenZFS but is slow and has caveats), so the cleaner growth path is larger drives or an added vdev. A case and HBA with spare bays cost little now and save a full rebuild later.
• Plan to fill a pool to no more than ~80%. ZFS performance degrades as a pool approaches full because it works harder to find contiguous free space. Size usable capacity so your real data sits under that line with headroom for snapshots.

For the topology that turns those drives into usable space, work the drive count through ZFS pool design: RAIDZ vs mirrors before you buy, because the redundancy choice changes how much raw capacity you need. To put a real number on it (usable space after parity, padding, the slop reserve, and that ~80% ceiling), model the build in the ZFS pool capacity calculator.

Which release do these requirements apply to?

The cited requirements apply to the Linux-based TrueNAS releases formerly branded SCALE and now shipped as Community Edition. Use the software status page for the General release recommendation before downloading.

TrueNAS CORE is the legacy FreeBSD line. The SCALE vs CORE comparison covers its status, migration considerations and the Community Edition naming change.

Will an old desktop run TrueNAS?

Usually yes. Run this checklist against the machine in the closet:

1. 64-bit x86 CPU? Anything from roughly 2010 onward qualifies. ARM and 32-bit do not.
2. Can it take 16 GB of RAM? 8 GB boots; 16 GB is where it stops feeling constrained.
3. A boot device that is not a USB stick? Any small SATA SSD works and costs little.
4. At least two data drives of the same size? One disk is not a pool worth having.
5. SATA ports presenting disks directly? If motherboard RAID is enabled, turn it off.
6. Room and airflow for the drives? The hardware guide puts a well-cooled spinning disk at around 28 °C in production and cites a study finding twice the failure rate for every 12 °C above that, so a case with no drive-cage airflow is a real cost rather than a cosmetic one.

Fail one of the first four and the build is not ready. Pass all six and the old desktop is a legitimate first TrueNAS box; how to set up TrueNAS SCALE picks up from there.

Next steps

• Once your hardware is chosen, TrueNAS SCALE vs CORE in 2026 covers OS selection.
• ZFS Pool Design: RAIDZ vs Mirrors walks through the topology choice for your specific drive count.

See also

• Docker homelab tutorials
• homelab firewall guide

Related across the network

• OpenMediaVault Hardware Requirements and Build Guide: openmediavaultlab.com
• OpenMediaVault vs TrueNAS vs Synology: Which NAS?: openmediavaultlab.com

Related on this site

• Best CPU for TrueNAS SCALE 2026