Lei Aldir Blanc

Started this because I kept bumping into the same annoyances on IRC and in forums. Seriously — configuration nightmares, unclear pruning choices, and weird networking gotchas. I’m not here to hand-hold newbies; this is for people who already run services and want a resilient, private, and low-friction full node that actually helps the network.

Quick take: a full node is simple in concept and fiddly in practice. It validates everything, serves peers, and preserves your sovereignty. But the operational choices you make — disk layout, backup strategy, bandwidth shaping, monitoring, and how you expose RPC — determine whether the node is a force-multiplier or a recurrent headache.

Okay, so check this out — the rest of this piece walks through practical decisions that experienced operators care about: storage, pruning vs. archival, networking and Tor, automation, monitoring, and some deployment patterns I’ve found robust. I’ll flag tradeoffs and offer commands or config snippets where useful. No fluff. If you want the vanilla upstream client, grab bitcoin core from the usual place: bitcoin. Use that as your baseline and then tweak.

Storage and performance: SSDs vs. HDDs, and layout

Short version: store the block index on a fast SSD; blocks can live on a cheap HDD if you need capacity. But read this carefully — access patterns matter. During IBD (initial block download), disk throughput and random I/O kill time-to-sync. An NVMe or modern SATA SSD shaves days off sync on large chains.

If you have multiple machines, use an archival node only where necessary. Most operators can run a pruned node (prune=) and still provide SPV-grade service for wallets and Lightning channels. Pruning to 550–2,000 MB keeps UTXO validation intact while saving terabytes.

Mount points: put datadir on its own volume. Snapshotting the OS volume without the datadir is asking for trouble. If using LVM or ZFS snapshots, make sure the node is quiesced or stop bitcoind briefly — inconsistent state bites you later.

Networking, peers, and privacy

Expose only what you intend. If you want your node to help the public network, open TCP/8333 and advertise it. If you need privacy, route RPC and P2P over Tor or an SSH tunnel. Running an onion service reduces your public IP surface and avoids some ISP throttling.

Firewall rules should be explicit. Rate-limit inbound RPC and restrict JSON-RPC by IP or socket file. Never expose RPC publicly without authentication and strong network controls. I’ll be honest: I’ve seen operators accidentally leak wallet RPC endpoints — ouch. So, use rpcallowip cautiously, and prefer cookie-based auth or an ssh-tunnel to access RPC.

Peer management: setmaxconnections should reflect your capacity. Too many connections hurt CPU and memory; too few reduce the node’s usefulness. On a VPS with limited bandwidth, limit outbound to a modest number and prioritize incoming if you’re hosting. Use addnode/connect only for trusted peers; persistent peers can help reliability, but they can also bias your view of the network if misconfigured.

Pruning, archival, and when to do each

On one hand, archival nodes are the gold standard for historical research and some exchanges. On the other hand, they cost a lot to host and maintain. For most operators running services (wallet servers, Lightning hubs), pruned nodes are perfectly fine. The node still validates transactions and enforces consensus rules.

My rule of thumb: run archival only if you need to rescan far-back transactions often, or you are a data provider. Otherwise, keep it pruned and maintain periodic off-node backups of critical metadata (wallets, channel backups, txindex if you enabled it).

Automation and orchestration

Automate safely. Systemd units are fine. Avoid “one-off” scripts that assume a clean environment. Use configuration management to set RPC credentials, enable TLS on interfaces as needed, and rotate logs. I like combining systemd for process supervision and a cron job or systemd timer for safe backups and health checks.

Containerization? Fine, but bind-mount the datadir and ensure correct ulimits. Containers can make updates easier, but remember: a container restart is not a backup. Use orchestration for deployment consistency, not for hiding the datadir lifecycle.

Monitoring and alerting

Monitor these things: block height vs. reference peers (lag), mempool size, connection count, disk I/O wait, and wallet balance changes if relevant. Logs are rich; export metrics to Prometheus with node-exporter or a lightweight exporter. Alert on chain reorgs of unusual depth, stalled IBD, and disk filling above thresholds.

Logging: rotate logs and keep them for a reasonable retention period. Forensic logs are useful if something odd happens. But remember privacy: logs may contain addresses or metadata you’d rather not ship to third-party SaaS without encryption and clear policy.

Backups and recovery

Wallet backups are simple conceptually, but brittle if your workflow forgets wallet-encryption or fails to capture deterministic seeds. Use exported seeds and encrypted backups. Test restores on a separate host. Automated backups should be encrypted at rest and in transit.

If you use watch-only descriptors, keep your descriptors and the script that created them. For Lightning, store channel backups off-node and test your recovery procedure. Don’t assume “it’ll work” — practice restores quarterly.

Common pitfalls and threadbare advice

Here are the things that keep biting operators:

• Letting disk fill up. A full disk can corrupt the DB. Set alerts and reserve space for OS overhead.
• Exposing RPC to the internet. Don’t. Use tunnels or tight firewall rules.
• Mixing multiple datadirs or symlink tricks without documentation. You’ll regret it later.
• Upgrading without reading release notes. Consensus-critical changes matter; plan maintenance windows.