I’ve run full nodes for years, and there are things that only reveal themselves after a few re-downloads of the chain and a couple of midnight troubleshooting sessions. If you’re an experienced user planning to operate a long-lived node, this is a focused, practical guide — not hand-holding, but the kind of transfer of tacit knowledge that saves you hours of hair-pulling. Expect hardware choices, network configuration, verification trade-offs, privacy and security notes, and operational best practices.
Short version: run bitcoin core on a dedicated machine with a fast SSD, decent RAM, and a reliable network connection. But of course, the devil is in the details.
Initial block download (IBD) is the first hurdle. IBD is I/O heavy and network-intense. Use an NVMe or modern SSD, set -dbcache high (I run 8–16GB on machines with 32GB RAM), and avoid running heavy parallel workloads during the sync window. Verify that your peer connections are healthy: get at least 8 outbound connections with -maxconnections set higher if you expect many inbound peers. If you rely on a metered or flaky ISP, consider fetching a recent chain snapshot for faster bootstrap, but be careful — snapshots change your trust model slightly because you’re trusting whoever prepared that snapshot for initial speed.
Operational choices, and why they matter — bitcoin core
Okay, so check this out — there are a few forks in the road every operator has to choose between: archival node vs pruned node, wallet-enabled vs watch-only RPC-only, Tor vs clearnet, and whether to enable txindex. Each choice affects disk, privacy, and what services you can offer.
Archival node: keeps the entire blockchain. Useful if you need historic lookups, block explorers, or chain analysis. Expect ~500+ GB (and growing) and plan for long-term backups of any critical data. Pruned node: keeps only recent blocks and caps disk usage; great for validating current state and supporting your own wallet without huge storage. Pruning drastically reduces disk but makes some RPC calls impossible (no getblock for old heights, unless you keep external copies).
txindex and indexing. If you plan to serve queries for arbitrary transactions or support an explorer, enable -txindex (or build a separate indexer). This increases disk and index rebuild time after -reindex. Most operators don’t need txindex — wallets and thin clients use other methods — but if you need full searchability, enable it from the start.
Network and privacy. Run as a listening node (set -listen=1) if you want to help decentralization. If privacy is a priority, bind and route through Tor by setting -proxy and -listenonion with a hidden service; that isolates your node’s IP from peers and indexers. Also consider disabling UPnP (-upnp=0) and manually configuring firewall/NAT to avoid accidental port exposure. If you must run behind NAT, reserve a static internal IP and forward port 8333 to it; dynamic IPs are OK but add dynamic DNS if you want a stable hostname.
Performance tuning. Use -dbcache to give Bitcoin Core more RAM for LevelDB/BDB, which speeds validation. On multi-core systems, -par controls script verification threads — core count of 4–8 is often optimal; each extra thread helps until you hit I/O or memory limits. For heavy loads (indexing, many RPC clients), separate data directories onto different disks if you can: one for the chainstate and blocks (fast NVMe), another for logs and spool. Always test upgrades on a staging node if you run mission-critical services.
Security and wallets. If you’re running a node to support a hot wallet, lock down RPC (use rpcauth rather than rpcuser/rpcpassword), use TLS where possible, and isolate the wallet host from exposed services. Hardware wallets remain the best option for cold-key security; use your node with a hardware signer through PSBTs or hardware-wallet aware wallets. Back up wallet.dat and, better yet, migrate to descriptor wallets (they’re easier to back up consistently). If you keep wallet functionality on the same node, accept the operational burden: frequent backups, careful upgrades, and a plan for wallet corruption recovery.
Verification modes and trust. Bitcoin Core offers flags like -assumevalid and -checklevel controls. Leaving defaults is safest for most operators — the project balances speed and security there. If you want maximum assurance, you can set -checklevel=4 and avoid -assumevalid, but expect much longer IBD. Some operators run an initial “fast” sync and then re-verify with higher check levels on a separate machine to spot-check integrity — a heavy but robust approach for critical infra.
Monitoring and maintenance. Keep an eye on conn count, orphan rates, and mempool behavior. Use the REST and RPC interfaces to monitor health, but keep RPC bindings restricted. Configure logrotate for debug logs; they can fill disks if verbose logging is enabled. Schedule periodic reboots only if needed; bitcoin core is stable for long uptimes, but kernel and OS updates sometimes force restarts. Make sure your backup schedule includes block data only if you’re making copies to save time for future nodes — most operators simply rely on re-download for reproducibility.
Upgrades. Always read release notes. Major releases sometimes change the chainstate layout or default parameters. Staging nodes help — run new releases against non-critical data first. If you must upgrade in place, ensure you have current backups and enough disk for potential temporary growth during reindexing.
FAQ
How much bandwidth will I use?
IBD can consume hundreds of GB during initial sync. Ongoing bandwidth depends on peer activity and whether you serve blocks: expect tens of GB per month for a standard node, more if you serve many inbound connections. Tor will increase latency and some overhead, but bandwidth use is comparable.
Can I use a VPS for a full node?
Yes, but check provider TOS and resource limits. VPS disks and IOPS matter: cheap VPSs with slow disks make IBD painful. Also think about centralization risks: if the VPS host forks or seals accounts, your node availability is impacted. For long-term service, a colocated or self-managed box at home or colocation is preferable.
What backup strategy should I use for wallet files?
Regular encrypted backups of wallet files, stored offline and geographically distributed. Prefer descriptor-based and PSBT-friendly setups. Test restores periodically — it’s easy to back up, but much harder to trust a backup if you never verify the restore.