Hardware requirements for running a full node with the official client

[Mad7Scientist2]

OS: 64-bit.
Blockchain disk space needed (~/.bitcoin/blocks/ on *nix): At least 814GB and growing as of September 2026.

RAM with HDD: 12GB of available disk cache RAM with ~/.bitcoin/ on an HDD. The amount of available RAM needed actually varies with the amount of disk cache needed to cache all of the ~/.bitcoin/chainstate/ directory.

RAM with SDD: 2GB or a bit more with ~/.bitcoin/chainstate/ on your SDD, with ~/.bitcoin/blocks/ put on an HDD, or with everything on an SSD.
Putting two or more SSDs on RAID 1 to store ~/.bitcoin/chainstate/ may improve performance. The chainstate/ directory grows but it should be under 20GB for the near future.

With enough low latency storage for the ~/.bitcoin/chainstate/ directory, the big weeks or months long I/O delay won't be a problem, and a good multi core CPU with enough Internet download bandwidth will get you synced in a few days.

I didn't see a current hardware thread around, so I thought I would start a new one.

[NotFuzzyWarm]

Way off on disk size. The chain is nearing 1TB and 2TB drive will only be good for around another couple of years. For best IBD speed a ssd is preferred vs a spinner as it can literally shave days off of the initial block download time..
For the rest, even an I5 or AMD equivalent cpu with 16GB of DDR3 ram will do fine tho 24 or 32GB ram would be ideal along with using 2x at least 2TB drives in RAID1.

It also should go without saying that the computer running the node should be used ONLY as a node. To minimize any attack vectors no browsing, streaming, etc

[tdk2]

have been running a full node (inc. ElectRS server and Lightning node) on a Raspi 4 with 8GB RAM for years. Just recently had to upgrade the single USB SSD from a 1TB to a 2TB drive.

Should be good for years to come. Once the blockchain outgrows the 2TB drive, but not before that, I'll buy a bigger one.

[ABCbits]

Putting two or more SSDs on RAID 1 to store ~/.bitcoin/chainstate/ may improve performance.

RAID 1 just duplicate same data on 2 drive, it can't be used to improve performance. RAID 0 may improve disk speed on certain read/write usage, but IMO people should check if there's bottleneck elsewhere during initial sync before even considering RAID 0 SSD setup.

[Mad7Scientist2]

Raid 1 allows multi threaded programs, such as bitcoin-qt, to access multiple files at the same time. Another thread can be accessing part of a different file while the first drive is busy. It also allows doubling the single threaded read speed by dividing the work load between the two drives, where each drive reads every other section of data.

To minimize any attack vectors no browsing, ...

Yes! Really, fully disabling Javascript in your browser is sufficient. That's where 95%+ of the security problems are. and don't use any other risky software that connects to the network and reveals its exact version and compiler version and date. Lots of software does this. This information is exactly what an attacker needs to have success on the first try.

[Cricktor]

In current times when RAM and SSD storage is rather expensive, we shouldn't go too crazy with requirements for a full Core node. In my opinion it also depends on what is your use case.

I had full nodes running on Raspi 4B with 8GiB RAM perfectly fine until my 1TB SSD ran out of space. RaspiBlitz node with electrs and later Fulcrum Electrum server, LND lightning node, worked fine. It's not rocket fast, but again, totally fine to operate as a personal Electrum server for an Electrum or Sparrow SPV wallet.

To continue operation on such a Raspi 4B base, I'd upgrade it with a Sandisk SSD Plus 2TB SSD and it would be fine for some more years. Pay attention that a Raspi 4B's total power budget for it's USB ports is rather quite limited and power hungry SSDs can produce nasty issues. The SanDisk SSD Plus series is remarkably low on power needs, therefore a recommended choice for Raspi 4Bs.

This also works as a platform for a RaspiBolt node where you can tinker a bit more yourself and learn a thing or two depending on your own knowledge of Linux command-line.

I would run such Raspi 4B setups headless, the GUI overhead for OS likely eats up valuable RAM. Should still work if you use something lean.

For IBD with such a Raspi setup, go as lean as possible to be able to reserve 3-4GiB for dbcache. When your internet connection isn't the bottleneck, your Raspi should finish an IBD in about a week or so. My last experiment to test IBD speed with a Raspi 4B with 8GiB RAM is a bit too old to give a good prediction for today, see quoted debug.log entries below (Bitcoin Core 25.0.0; dbcache=4883):

Code:

2023-06-22T18:00:43Z UpdateTip: new best=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2009-01-03T18:15:05Z' progress=0.000000 cache=0.0MiB(0txo)
...
2023-06-26T16:43:37Z UpdateTip: new best=000000000000000000017ba8b29ebaf27c3906954bf93ff571ed1bfdb0208614 height=796032 version=0x25b6a000 log2_work=94.265126 tx=856789548 date='2023-06-26T16:37:22Z' progress=0.999998 cache=3589.4MiB(22517213txo)
2023-06-26T16:46:24Z Saw new header hash=00000000000000000000a2c9c72ff100692ba39a89d5b84417a8b9d0e947db39 height=796033
2023-06-26T16:46:24Z [net] Saw new cmpctblock header hash=00000000000000000000a2c9c72ff100692ba39a89d5b84417a8b9d0e947db39 peer=3385
2023-06-26T16:46:31Z UpdateTip: new best=00000000000000000000a2c9c72ff100692ba39a89d5b84417a8b9d0e947db39 height=796033 version=0x2fffe000 log2_work=94.265140 tx=856792482 date='2023-06-26T16:46:05Z' progress=1.000000 cache=3589.5MiB(22517925txo)

I know that in mid 2023 chain tip of my experiment was just 796033 when we are today now at 966096. IBD to tip at 796033 took little less than 4 days, therefore my prediction that IBD to tip at 966k might be done within a week.

You can always add more RAM, more cores, faster storage, depending on your use case. I would set the minimum at 8GiB RAM, if an IBD shouldn't take ages, SSD storage for chainstate, block storage files are fine on a spinning rust HDD. Plan with at least 2TB storage space for a full node. Transaction index takes space, too, and you need it if you also want an Electrum server on top which of course also needs quite some space for its index files. Especially Fulcrum is more demanding than electrs.


Other than the Raspi platform, you can use a mini pc or a second-hand laptop. That's what I use for my full node(s) right now. Works like a charm, even 24/7. My goal is to use something that doesn't use much more than ~10W power consumption on average when I operate it 24/7/365 for a full node.

Here is space consumption of an Umbrel VM with 2TiB storage:

Code:

umbrel@umbrel:~$ df
Filesystem      1K-blocks       Used Available Use% Mounted on
udev             12270360          0  12270360   0% /dev
tmpfs             2458952       3176   2455776   1% /run
/dev/sda2         9856072    4622168   4751648  50% /
tmpfs            12294752          0  12294752   0% /dev/shm
tmpfs                5120          0      5120   0% /run/lock
/dev/sda1          204580      49736    154844  25% /boot/efi
/dev/sda4      2118474640 1181176744 937281512  56% /data
tmpfs             2458948          0   2458948   0% /run/user/1000

Space consumption of Bitcoin Core node data:

Code:

umbrel@umbrel:~$ du -h umbrel/app-data/bitcoin/data/bitcoin/
12G	umbrel/app-data/bitcoin/data/bitcoin/chainstate
69G	umbrel/app-data/bitcoin/data/bitcoin/indexes/txindex
110M	umbrel/app-data/bitcoin/data/bitcoin/indexes/blockfilter/basic/db
13G	umbrel/app-data/bitcoin/data/bitcoin/indexes/blockfilter/basic
13G	umbrel/app-data/bitcoin/data/bitcoin/indexes/blockfilter
81G	umbrel/app-data/bitcoin/data/bitcoin/indexes
145M	umbrel/app-data/bitcoin/data/bitcoin/blocks/index
815G	umbrel/app-data/bitcoin/data/bitcoin/blocks
907G	umbrel/app-data/bitcoin/data/bitcoin/

Space consumption of Fulcrum 2.1.2 electrum server:

Code:

umbrel@umbrel:~$ du -h umbrel/app-data/fulcrum/data/fulcrum
192G	umbrel/app-data/fulcrum/data/fulcrum/fulc2_db
192G	umbrel/app-data/fulcrum/data/fulcrum

[Danish Ali]

If the node machines require more than 814GB storage, then pruning, which is an existing feature in Bitcoin Core, takes care of this. The amount of storage can be reduced greatly by configuring prune=550 in bitcoin.conf (this keeps only the necessary data needed to process reorganizations and maintain the current chain state). This does come with some trade-offs though: old blocks will not be serviced over P2P, txindex is disabled, and compatibility with Electrum servers (such as Cricktor's setup above) is lost since they need a full block archive. For a user that just wants to run their own wallet without any extra indexing services, however, pruning reduces the SSD requirement from "784GB+" to a much more realistic level.

[Cricktor]

...

A pruned node isn't the topic here, so why do you bring it up?

[Danish Ali]

...

A pruned node isn't the topic here, so why do you bring it up?

Fair point. Storage size and SSD costs were being discussed as a big blocker, so I just mentioned pruning as a cheap hardware option for beginners.

[gmaxwell]

A pruned node isn't the topic here, so why do you bring it up?

Yes it is, it's literally the topic statement. A pruned node is a full node!  A full node is a node that fully validates the chain and enforces all the network rules.

In any case, even for an archival full node there is no need to put the historical blockchain data on a SSD.  It's only used for serving historical blocks and so it's accessed whole blocks at a time to stream out to peers at no more than the speed of your network (which is usually slower than spinning rust).


The question in the OP is somewhat underdefined-- the required hardware depends on what you intend to use it for.  If it's merely to keep up with the network than very low end hardware will work.  If you intend for it to mine or meaningfully contribute to block propagation then the requirements are much higher.

If you intend to use it to protect a wallet or act as a protocol firewall in front of a node that protects a wallet then the ideal hardware might be different yet.

[philipma1957]

...

A pruned node isn't the topic here, so why do you bring it up?

a pruned node allows a 1tb ssd so it could be mentioned.

maxwell beat me to my answer.

——————————————-
to me an i5 8th gen or better

32 gb ram

2tb ssd

eth connection

100 or better speed internet
with wifi and bluetooth disabled

and a 1tb rasp pi with 8gb

is asking for grief

and it is short lived but

the setup above i picked will be good for three years to five years.

[ABCbits]

Raid 1 allows multi threaded programs, such as bitcoin-qt, to access multiple files at the same time. Another thread can be accessing part of a different file while the first drive is busy. It also allows doubling the single threaded read speed by dividing the work load between the two drives, where each drive reads every other section of data.

Fair point, i was focused too much on write performance. Anyway, i did quick search and found read speed of RAID 1 can be faster than single SSD.

But the benefit of RAID 1 is rather small for random read and i didn't find such benchmark for newer SSD.

[Danish Ali]

I think gmaxwell is right in that block data does not require SSD speeds in itself.
Since nobody has said how much gmaxwell's points can be used for - putting some real numbers on it:

• Wallet-protection / firewall node: pretty much anything with an internet connection, a Pi 4 with 4GB RAM will be more than enough here. In this use case speed of spreading is not really a priority, and passing along a block to you could take 30+ seconds even for fast relays it does not matter, as there is no competition for any blocks.
  
  
• Keep-up-with-network only: this is where the numbers up-thread (such as 2GB RAM + any SSD for chainstate) apply. The speed with which you do it is not too considered with regard to IBD, as you only have to do it one time.
  
  
• Propogation / low-delay-relay: This is where the quality of the CPU single core speed and the network delay to peers actually become a factor since the first node to pass along a block will win the game! A slow CPU here can actually have an impact on a network spreading time and not just on your own experience.
  
  
• Mining next to (getblocktemplate serving): In the mining side, the most strict requirement is for CPU/delay, because creating a block template is directly related to a miner's ability to quickly build on the mining tip.
  
  
  

Most of what is talked about in this thread for the home-node is in the first two levels of the list where hardware is almost not important (Pi 4 / mini PCs etc.). Requirements do not become serious unless you are in the 3rd or 4th level which very few home operators need.

[hmbdofficial]

~snip
I think gmaxwell is right in that block data does not require SSD speeds in itself.

I agree with the main point here too. A node does not automatically need a high end SSD or a very powerful CPU just because it’s running the full blockchain. The hardware requirements depends on what exactly the node is doing. A normal home node mainly needs to validate blocks, maintain the UTXO sets and just stay synchronized with the network, so modest hardware can be just sufficient here.

The situation may be different with node that are optimized for very low latency block propagation, or are serving miners with getblocktemplate. In those kind of cases, the CPU performance, storage performance and latency should have more noticeable effects. But For home users, I think the goal is just to simply run a reliable validating node, and not to compete in block propagation or construct mining template. And that’s why I think relatively inexpensive hardware can be just enough for a normal bitcoin node IMO.

[Antidote47k]

chainstate is part of the workload that is more latency-sensitive in the context of IBD, due to its random database I/O. The block files are more suitable for slower storage.
If you have sufficient RAM, increasing dbcache can help reduce disk I/O during IBD, as Core is able to store more of its UTXO database state in memory. So rather than the 12 GB of RAM being a static requirement, it’s worth playing with the dbcache based on the amount of RAM and storage available.

A second possible, albeit less expensive, solution is to run chainstate on a small SSD, and the large blocks directory on the HDD. You don’t necessarily need a 2TB SSD to move the latency sensitive part to a solid state storage, the block files can be placed on a different drive using -blocksdir.
Sounds like a sweet spot for those with an already large hard drive and desire some more IBD performance without having to replace the entire storage system, just remember to reset dbcache back to default at the end of IBD, or you will use up system memory unnecessarily when operating the node normally!

[darkvector-dev]

I configured nodes with "old" mini-pc ThinkCentre, these machines are perfect for this use. They are cheap, silent, easy to find, and use very little power.

I use StartOS with Bitcoin Core.

My last configurations were:


ThinkCentre M93
Intel i7 4785T
16GB DDR3 (2x 8GB 1600)
SSD SATA 2TB
StartOS with Bitcoin Core, Electrs, Mempool, Tor

ThinkCentre M710Q
Intel i7 6700T
16GB DDR4 (2x 8GB 2133)
SSD Nvme 4 TB
StartOS with Bitcoin Core, Fulcrum, Mempool, Tor, Am I Exposed, RoboSats (on this machine i also ran LND, Lightning Terminal, now removed).




More than enough and future proof.

[NotATether]

It also should go without saying that the computer running the node should be used ONLY as a node. To minimize any attack vectors no browsing, streaming, etc

You can also install SELinux on the node and set it to enforcing.

This is equivalent to isolating different software across different machines, but it needs a bit of sysadmin work to allow applications to talk to each other.

[Mad7Scientist2]

You can also install SELinux on the node and set it to enforcing.

SELinux just limits system services, including those that run as root such as exim, to the minimum file and /dev permissions needed. It does not improve the security of a non privileged user account beyond what can already be done by setting filesystem permissions. It doesn't limit Chromium's access to 3D graphics, audio, kernel system calls, X11/Wayland, or any other areas where there could be exploits.

A VM would be a better choice as Linux gets more and more bloated and there is more and more possibility for local exploits.

A 2TB SSD is still $220, and you have the issues with TLC/QLC flash where the data storage life can be as little as 1 year on an older worn out drive that is exposed to higher temperatures. It's 10 years when the drive is new, which isn't that much worse than an HDD.

[LFC_Bitcoin]

Way off on disk size. The chain is nearing 1TB and 2TB drive will only be good for around another couple of years.

You’re wrong there, 2TB is enough space for at least another 4-5 years. Based on block sizes over the last 3 years,   2TB will be enough until 2030/2031 at least.

[Cricktor]

I looked up what space has been used by blk*.dat and rev*.dat files of my archival Core node in the last two years (about September 14^th, 2024 until September 13^th, 2026. It's very little over 180.14GiB, assuming similar yearly growth of approx. 90GiB, I'd say, 2TB storage for a node should last another good 8 years. That's my estimation with a few grains of salt, give or take.

I know that I ignore index files growth. I take this into account by not estimating 9 years, but 8.

Indexes folder is roughly 10% of block files size (includes txindes and blockfilter stuff). I hope the storage prices madness doesn't last next 8, 9 or 10 years...