Google Preferred Source See Bitcoin.now more often.

Add Bitcoin.now to your preferred sources so Google can surface more of our Bitcoin reporting and explainers in your results.

Make Bitcoin.now preferred Opens Google’s source preferences. You stay in control.
Google Preferred Source
Hardware planning worksheet

Plan the hardware for running your own Bitcoin node

Choose a node profile and estimate practical storage and bandwidth needs. The planner explains what pruning changes - and what it does not.

Plan a node profile

Storage target -
Recommended free space -
Bandwidth fit -
VerificationFull rules

Projected storage headroom

Projection uses a planning assumption, not a protocol promise. Block usage and software behavior can change.

A pruned node still validates Bitcoin

Pruning removes older block files after the node has downloaded and validated them. It does not replace consensus validation with trust in a third party. The trade-off is that the node cannot serve the entire historical chain to peers or rescan arbitrary old wallet history without downloading again.

Initial sync is the heavy step

CPU, disk speed and network quality affect initial block download. An SSD and stable wired connection usually improve the experience more than chasing a large memory number.

Start with what a Bitcoin node does, check current Bitcoin software releases, and monitor chain state on the network dashboard.

Practical node checklist

ResourcePlan forWhy
StorageChain plus growth and free-space marginDatabases need working room
BandwidthInitial sync plus relayUpload can be significant
PowerStable, continuous serviceUnexpected shutdowns slow recovery
BackupsWallet data, not the public chainThe chain can be downloaded again
UpdatesVerify signatures and release notesSoftware supply-chain safety
Method and boundary

How the node plan turns a goal into hardware headroom

Archival and pruned nodes validate the same rules but need different storage plans and serve different follow-up jobs.

01

Choose the job

Archival storage supports full historical block serving. Pruning retains a smaller rolling set after validation.

02

Add operating margin

Projected chain growth is paired with free-space headroom so databases and updates are not planned against a full disk.

03

Check the bottleneck

Bandwidth, disk speed, CPU, uptime, and initial sync can matter more than a single headline specification.

Node-planning questions before choosing hardware

Does pruning weaken validation?

A pruned node downloads and validates historical blocks before discarding older block files. It still enforces consensus rules, but cannot serve the full archive to other peers.

Do I need to back up the blockchain?

Usually no. Public block data can be downloaded again. Back up wallet keys, descriptors and configuration that cannot be recreated, using an appropriate secure process.

Can a node run over Tor?

Bitcoin Core can use Tor for peer connections. Tor changes network privacy and performance trade-offs; it does not make wallet behavior automatically private.

Hardware planning worksheet

Size a node for the job you want it to do

A Bitcoin node's requirements depend on choices: full history or pruned, indexed or not, Tor or clearnet, and how much bandwidth you can spare. The planner turns those choices into disk, memory and network figures.

Planning grid

Configurations and what they need

SetupDiskMemoryBest for
Pruned, non-listeningAbout 10 GB1–2 GBWallet verification on a small device
Full archive700 GB+2–4 GBServing blocks to peers, Lightning backends
Full + txindex800 GB+4 GB+Explorers and research
Electrum-style server1 TB+8 GB+Fast wallet queries for many addresses
Plan 1

Storage follows the history you keep

The full chain is several hundred gigabytes and grows by 50–100 GB a year. Pruned mode validates everything but discards old blocks, keeping the node under a few gigabytes plus the current UTXO set.

  • A transaction index adds tens of gigabytes and is only needed for looking up arbitrary old transactions.
  • Use an SSD; initial sync on a hard disk can take days.
  • Leave headroom for a year of growth.
What a node validates →
Plan 2

Bandwidth is the quiet cost

Initial sync downloads the whole chain once. Afterwards a node serving peers can upload tens of gigabytes a month; capping upload or running as a listening node behind Tor changes that figure.

  • Set a maximum upload target if your connection is metered.
  • Tor hides your IP from peers and works with pruned nodes.
  • A phone-class connection can run a pruned, non-listening node.
Why your own node protects privacy →