Whoa. Running a full node is more satisfying than I expected. Seriously. It’s not just a box that verifies blocks; it’s a civic duty and a debugging tool all at once. My instinct said this would be fiddly, and that proved true—though once you get the plumbing right, it hums along quietly for months.
If you already understand the basics, this is a hands-on checklist with tradeoffs and gotchas—storage choices, pruning vs archival, network hardening, systemd tips, and how to keep your node both useful and resilient. I’ll be blunt about what I do and why. I’m biased toward stability and observability, not flashy setups. Oh, and somethin’ to keep in mind: your needs may change if you run services that rely on historical queries.
Hardware: real constraints, real choices
Short answer: CPU and RAM matter during initial sync; disk speed and endurance matter for long-term reliability. If you want the node to catch up fast, a modern multicore CPU and at least 8GB RAM help. For long-term storage, use an NVMe or a high-quality SATA SSD. HDDs work for archival nodes but will slow IBD and can be a point of failure under heavy I/O.
For archival nodes plan for several hundred gigabytes (expect 500GB+ depending on the date you read this). For constrained environments, pruning is your friend: set prune=550 to operate as a pruned full node (minimum about ~550MB of block storage). Pruned nodes validate and relay blocks but won’t serve old blocks to peers. That’s a tradeoff—less disk, less service to the network.
My setup choices, in order of priority: reliable SSD, UPS, ECC RAM if available, and a decent network uplink. If you’re building a remote colocated node, balance bandwidth costs against usefulness—upload matters more than you think when other peers ask for data.
Bitcoin Core configuration tips
I run bitcoin core in systemd containers on some machines and directly on others. For initial block download, bump dbcache to a few GB (dbcache=2048 or 4096) if you have RAM to spare; it speeds up validation. But don’t set dbcache so high that the OS starts swapping—trust me, swap kills performance.
Txindex=1 is only necessary if you need global transaction lookup via RPC. If you don’t run block explorers or services that query arbitrary txids, leave it off. Enabling it increases storage and indexing overhead. If you later decide you need it, reindexing takes time—a lot of time.
Be explicit with network interfaces: use bind and rpcbind to avoid exposing RPC to the world. Add rpcallowip sparingly and consider using a reverse proxy or ssh tunnel for remote RPC access. For example, keep RPC on localhost and use SSH port forwarding for occasional remote administration instead of opening RPC ports.
Privacy and Tor
On one hand Tor integration is straightforward. On the other hand, misconfigurations can leak your real IP. Use -proxy or -onion when you want to route outgoing connections through Tor, and set -listenonion to control whether you accept incoming onion connections. If you run an outgoing-only Tor-only node, combine -onlynet=onion with -proxy and be aware this limits reachable peers—startup sync can be slower.
I’m not 100% paranoid, but I prefer separate machines or VMs for wallets and network-facing services. Keep private keys off internet-facing systems. If you need the convenience of a local wallet, consider hardware wallets or a separate signing device.
Network & Firewall
Open port 8333 if you want to accept incoming IPv4 peers. If you’re behind NAT, enable UPnP if you trust your router; otherwise forward the port manually. Use UFW or nftables to restrict RPC ports and allow only necessary traffic. Rate-limit peers if your node is on a metered link.
Bandwidth is easy to underestimate. The initial sync will download the entire chain and verify it; that’s hundreds of GB. After sync, traffic settles into a steady state but spikes still happen (reorgs, serving peers). Limit upload if you must, but remember that a well-connected node helps the network.
Monitoring, maintenance, and backups
Set up systemd unit files with Restart=on-failure and resource limits. Use logrotate for debug logs (or redirect logs to syslog). Periodically check getblockchaininfo and getpeerinfo via cron or a monitoring system. Alerts for “not syncing” or “too few peers” save you headaches.
Back up wallets religiously. Automated copies to an offline medium are simple and effective. If you run multiple wallets, separate them into different datadir paths so a single mistake doesn’t corrupt everything. And test restore procedures—don’t assume backups work until you’ve restored one.
Performance tuning and common pitfalls
Increase dbcache during sync then lower it for day-to-day operation if RAM is needed for other services. Avoid overcommitting system memory. If you run other disk-heavy services (like databases), separate them onto another volume or machine to avoid I/O contention.
Reindexing happens when you change certain config options. It’s slow. Plan for it and don’t make needless changes. Also, avoid frequent restarts during sync—each restart costs time as peers reassign and validation resumes.
FAQ
Should I run an archival node or a pruned node?
If you want to support the network by serving historical blocks, run archival. If you only need to validate and secure your own transactions and conserve disk space, pruned is perfectly fine. Consider your role: hobbyist and privacy-focused users often choose pruned nodes; infrastructure providers choose archival nodes.
How much bandwidth will my node use?
Expect a large initial download (hundreds of GB). Ongoing usage is modest but variable—tens of GB per month is common for well-connected nodes. If you have a cap, monitor and set bandwidth limits in the config.
Can I run other services (Lightning, explorers) on the same machine?
Yes, but isolate them where possible. Lightning implementations like LND or Core Lightning are commonly co-located, but keep separate datadirs, monitor resource usage, and use separate users to reduce risk of accidental access to private keys.
Non-custodial Cosmos wallet browser extension for DeFi – https://sites.google.com/mywalletcryptous.com/keplr-wallet-extension/ – securely manage assets and stake across chains.