Here a repo with Practical guides and tools for running a sovereign, private, and self-hosted Bitcoin and Lightning nodes on Linux. Covers things like system hardening, monitoring, network configuration, and operational best practices.
Everything is based on what the user learned running its own nodes — No theory. No marketing. Just working configurations and commands tested on real systems. Stuff that actually works in production.
Still a work in progress, contributions welcome.
GitHub: https://github.com/shadowbipnode/sovereign-linux-tools
GuidesGuides
| Guide | Description |
| gocryptfs | File-level encryption on Linux — lock sensitive data even while the system is running |
| signal-opsec | Signal notification settings, metadata leaks, iOS vs GrapheneOS |
| lnd-backup | Automated LND backup with GPG encryption and cloud redundancy |
| sovereign-backup | Triple-redundant encrypted backup for Bitcoin/Lightning nodes |
| ssh-hardening | Complete SSH hardening for production Linux servers |
| tor-setup | Complete guide Tor Setup — Running Bitcoin Core and LND over Tor |
| tor-transparent-proxy-guide | Complete guide to routing ALL System Traffic Through Tor on Rocky Linux 9 |
More guides coming.
PhilosophyPhilosophy
Full-disk encryption is table stakes.
A VPN is not privacy.
Self-custody means running your own infrastructure.
These guides cover the practical gap between "I care about privacy" and "my setup actually reflects that."
Tools covered: encryption, node operation, key management, network hardening, backup, and more.
I'm curious why full disk encryption is table stakes. Is the threat model that someone will have physical access to your node, or is there a different threat model that I don't understand?
Also, there is something wrong with the tor-setup guide link: https://stacker.news/items/guides/tor-setup.md
Yes, for a Bitcoin/Lightning node, full disk encryption is mainly about physical access, but that’s not the only reason. It’s also a strong baseline against theft, resale, repair-shop access, seized hardware, and any situation where the machine is powered off but still contains sensitive keys, backups, logs, or config files. It does not protect you while the node is unlocked and running.
Link is not formatter properly, here the correct one https://github.com/shadowbipnode/sovereign-linux-tools/blob/main/guides/tor-setup.md
re: FDE and the threat model — it depends on your deployment. For a home node stuck behind a desk, your threat is more "stolen laptop" than "targeted raid". FDE means they can't pull the SSD and read your channels.db. If you're colo or VPS, the cloud provider already has physical so FDE matters less there — encrypted lnd wallet + gocryptfs for config secrets is usually enough.
Bigger gap I don't see covered much: automated off-chain channel backup that survives both hardware failure AND provider lock-in. Their LND backup guide covers encrypted cloud redundancy which is the right approach. Would love to see a guide on restoring from those backups on a different provider with minimal downtime — that's the real production pain point.