TrueNASGuide
Flat isometric illustration of a grey NAS tower with blank front panels, a stack of drive trays beside it and a cabled power supply on a cream background
hardware

TrueNAS System Requirements: Minimum & Recommended

TrueNAS needs a 64-bit 2-core CPU, 8 GB RAM, a 16 GB boot SSD and two data drives. Compare the official minimum with practical home NAS targets.

By TrueNASGuide Editorial · ·Updated August 29, 2026 · 13 min read

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.

The hardware advice in the TrueNAS community ranges from “anything works” to “you must buy server-grade or your data will spontaneously combust.” Reality is in between. ZFS does have hardware preferences, and getting them right saves you headaches down the line, but most of the more extreme advice is a holdover from the early days, and a thoughtful build today using modern desktop parts is perfectly viable for a home NAS. This guide is opinionated about what genuinely matters and what you can deprioritize.

Where the vendor floor sits

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:

RequirementOfficial minimum
Processor2-core Intel 64-bit or AMD x86_64
Memory8 GB
Boot device16 GB SSD
StorageTwo identically sized devices for a single storage pool

That is the whole list. Everything else you have read on forums is a recommendation, a preference, or folklore. The documentation is candid about how low the floor is: it notes that TrueNAS “installs, runs, and operates jails (in TrueNAS 13)” and “also hosts SMB shares and replicates TBs of data with less” than the stated minimum, and that the figures exist because “the TrueNAS team recommends the above for better performance and fewer issues” rather than because the installer refuses to run below them.

Two clarifications that save arguments:

  • The 2-core requirement is nearly meaningless. The guide says so directly: TrueNAS “does not require two cores, as most halfway-modern 64-bit CPUs likely already have at least two.” If the CPU is 64-bit and made this decade, that line is satisfied.
  • The boot device does not have to be an SSD, but iXsystems explicitly discourages spinning disks and USB sticks for boot. USB boot media in particular has a long history of silent failure in this role.

Side by side with what a home build should actually target:

ComponentOfficial minimumRecommended for a home NAS
CPU2-core Intel 64-bit or AMD x86_644+ cores with AES-NI; higher clock for SMB-only, more cores for VMs
RAM8 GB16 GB floor, 32 GB comfortable, 64 GB+ with VMs
Boot device16 GB SSD120-250 GB SATA SSD or small NVMe, leaving room for boot environments
Data drivesTwo identically sized devices4-8 CMR NAS drives bought across two batches
ControllerOnboard SATALSI HBA in IT mode once you outgrow the chipset ports
NetworkOne interface2.5 GbE onboard; a single fast link beats bonding slow ones
ECC memoryNot requiredPreferred where the data is irreplaceable

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.

The probability of this in any given hour is very low. The probability across years of continuous operation on a large pool with many terabytes of data is not negligible.

Recommendation: for a home NAS holding irreplaceable data (family photos, document archives), prefer ECC if the budget allows. The cost premium today is much smaller than it used to be. Ryzen Pro CPUs and many AM4/AM5 motherboards support unbuffered ECC, and used Xeon E3/E5 boards are inexpensive on the secondary market. If non-ECC is already available, pair it with rigorous off-site backups. The hardware guide’s own summary of the debate is measured rather than dogmatic (many TrueNAS systems run every day without ECC, and RAM of any grade can fail), and the concrete advice buried in it applies either way: test all RAM before deployment, since failures usually surface in the first three months.

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.

A concrete starting build

For a typical 6–8 bay home TrueNAS SCALE server with VMs and apps:

  • Platform, pick one. AM5 is an AMD socket and W680 is an Intel chipset, so a board and CPU have to come from the same column. Both take DDR5 ECC and both reach 4+ SATA ports and 2.5GbE at this tier.
    • AMD: an AM5 server or workstation board that validates unbuffered ECC (ASRock Rack and Supermicro both list AM5 boards with ECC support) plus a Ryzen 7000-series Pro CPU.
    • Intel: a W680 workstation board, which is the chipset that enables ECC on mainstream Core CPUs, plus a Core i5 13th or 14th gen if you want QuickSync for transcoding.
  • RAM: 32–64 GB DDR5 ECC, unbuffered, on the board vendor’s validated list
  • HBA (if more than 4–6 drives): LSI 9300-8i in IT mode (used)
  • Pool drives: 6× 8 TB or 12 TB CMR NAS drives (WD Red Plus, Seagate IronWolf, or Toshiba N300)
  • Boot device: 1× 120–250 GB SATA SSD or small NVMe, boot pool only, sized for boot environments as in the table above
  • App and VM storage: 1× 500 GB–1 TB NVMe as its own pool, kept off the boot device so a boot-pool rebuild does not take your apps with it
  • PSU: 600–750 W 80+ Gold modular
  • Case: 6–8 hot-swap bay case with good airflow (Fractal Design Define R7 / Node 804 / Silverstone CS381)

This is not cheap, but it is honest. You can build less if your needs are smaller; the best budget NAS build for home shows a lower-cost parts list that still respects the non-negotiables above. The hardware here is appropriate for 5+ years of continuous operation.

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?

They apply to current TrueNAS, the Linux-based line formerly branded SCALE and now shipped as TrueNAS Community Edition. Per the software status page, the general-use recommendation is 25.10.6 “Goldeye”, with 26.0.0-BETA.2 on the early-adopter track and 25.04 “Fangtooth” in maintenance.

TrueNAS CORE, the FreeBSD line, is a separate case. Its final releases were 13.3-U1.2 in April 2025 and 13.0-U6.8 in July 2025, and it receives no further development. Its hardware requirements are broadly similar, but there is no reason to plan a new build around it; TrueNAS SCALE vs CORE in 2026 covers the migration question, and TrueNAS Community Edition vs SCALE explains what the renaming did and did not 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

See also

Sources

  1. TrueNAS SCALE Hardware Guide (official minimum requirements)
  2. TrueNAS Hardware Guide, 25.10 (official minimum requirements)
  3. TrueNAS Hardware Guide (documentation hub)
  4. TrueNAS Software Status (current release recommendations)

Related