Plan storage and sync
A full node and a pruned node have different disk needs, and those needs change over time. Check current upstream requirements and leave growth room. Initial block download can take substantial time and resources.
Restrict control interfaces
Keep Bitcoin RPC and Lightning administration on a private authenticated route. Exposing an unauthenticated control endpoint can endanger funds and the host. Public peer ports and private administrative ports need different firewall rules.
Understand channel liquidity
A Lightning channel ties up funds and has inbound and outbound liquidity constraints. Running a node does not promise routing revenue. Consider fees, channel management and the risks of a hot wallet before funding it.
Back up the correct state
Follow the specific implementation’s recovery procedure for wallet seeds and channel backup material. Store recovery data off the node and test understanding without exposing secrets. A generic filesystem copy may not be a safe live-channel backup.
Choose an implementation and follow its recovery rules
Bitcoin Core supplies a Bitcoin backend. LND and Core Lightning are separate Lightning implementations with their own configuration, plugin ecosystem and backup procedures. Choose one supported stack and follow its current documentation; do not mix recovery instructions between implementations. Synchronisation completion, peer connectivity and wallet recovery are separate acceptance checks.
A pre-funding checkpoint
Before placing meaningful funds online, verify that administrative ports are private, updates are scheduled and wallet and channel recovery material is stored independently. Understand the difference between a seed, static channel backup and a full data copy in your implementation. Keep only the online funds your operating plan requires. A routing node is an operational commitment, not a passive-return product.
Accept the Bitcoin backend before opening channels
Verify the software’s release provenance using its project instructions, choose a supported full or pruned layout, and allow initial synchronisation to finish. Keep space for database overhead, logs, updates and growth rather than allocating the exact expected chain footprint. A pruned backend may require additional planning for historical wallet discovery or rescans. Do not present an arbitrary current disk figure as a permanent requirement.
- Check synchronisation progress, peer connectivity and disk consumption independently.
- Keep the RPC listener and authentication private; opening a peer port does not require exposing administrative control.
- Choose LND or Core Lightning with a documented compatible Bitcoin backend, then verify its own sync state.
- Run a small test and understand funding, inbound liquidity and fees before placing meaningful funds online.
Official documentation: LND: disaster recovery · Core Lightning: wallet and channel backups
Treat stale channel state as a recovery hazard
A general VPS snapshot is not automatically a safe live-channel backup. LND’s disaster recovery can use its seed and static channel backup to request channel closure; it is a last-resort process, not a normal migration method. Keep the old instance stopped during recovery to avoid competing copies. Follow LND’s procedure for the material you actually possess rather than restoring an arbitrary old channel database.
Official documentation: LND: disaster recovery
Keep the recovery plan specific to the implementation
Core Lightning distinguishes the wallet secret, emergency channel recovery material and the live database. Its documentation discourages ordinary snapshot-style restoration of stale channel database state and describes implementation-specific backup approaches. Preserve the required key material off the node, monitor updates to channel recovery files, and test your understanding before funding. If the disk fails, preserve the damaged data and consult the correct recovery procedure before restarting an old copy.
- A restored on-chain balance does not prove that every channel has been recovered.
- A channel with no inbound capacity cannot receive merely because the node is online.
- A peer outage and a failed local RPC credential require different troubleshooting.
- Do not infer automatic income or guaranteed recoverability from a successful node installation.
Official documentation: Core Lightning: wallet and channel backups