Run a Lightning node at home: LND vs Core Lightning
A home Lightning node gives you full control and a lot of chores, so most people are better off with a self-custodial wallet.
Run your own Lightning node if you want to learn how Lightning works, take payments without a middleman, or help the network, and you already run a Bitcoin node. If you only want to send and receive small payments, a self-custodial Lightning wallet does the job with far less upkeep. A home node needs a Bitcoin backend, ideally your own synced node, plus funded channels, a machine that stays online, and backups, and its wallet is a hot wallet, so keep only spending money in it.
Disclosure: I work at Blockstream, which maintains Core Lightning, one of the two implementations compared here. There are no affiliate links on this site.
Who should run a Lightning node, and who should not
Running a node means you are the bank for your own channels. You open them, fund them, watch them, and recover them if the machine dies. I would run one only if you fit one of these:
- You already run a Bitcoin node and want to use it for payments too.
- You take payments for a business or project and do not want a third party in the middle.
- You want to understand channels, fees, and liquidity by doing it.
Skip the node if you want to pay for coffee with a few thousand sats and never think about it. A self-custodial Lightning wallet keeps your keys without making you manage channels or inbound liquidity. The Bitcoin reason to run a node is verification and independence: your wallet talks to a node you control instead of one a company runs. Neither choice is wrong, and for most people the wallet is the better one.
What a home Lightning node involves
- A Bitcoin node underneath. LND can run without one in Neutrino mode, but its docs recommend Bitcoin Core or btcd on the same machine or network. Core Lightning needs bitcoind by default, and its docs say version 25.0 or above should work.
- Hardware. LND asks for at minimum 2 GB of RAM, a 1 GHz quad core, and 5 GB of storage, and says to use a good SSD and not an SD card, because it reads and writes often.
- Channels and inbound liquidity. To receive, someone else must hold balance on their side of a channel with you. LND's docs list ways to get that inbound capacity: spending your own sats, asking peers to open channels to you, a swap service such as Loop Out, or buying channels on a marketplace such as Pool.
- Being online. A peer can try to close a channel with an old state, and you can only punish that while you are watching. LND's docs give the example of a 144-block delay, which means your node or a watchtower has to be online and synced at least once every 24 hours to safely monitor channel closures. The delay is typically scaled to the channel size. If you need your money out while a peer is offline, a force close is the way, and the side that starts it waits a set period before it can spend its funds.
- A hot wallet. The keys sit on an internet-connected machine and sign payments all day. Fund it with what you would carry in a physical wallet, and keep savings on a hardware wallet.
Updates are part of the job. LND's security guide says LND needs to be regularly updated, like the operating system under it, and to use a firewall to limit exposure. Opening the Lightning peer port is not required but is recommended, so other nodes can connect and open channels to you, and the REST and RPC ports only need exposing when an external app requires them.
Backups that matter
A Bitcoin wallet restores completely from a seed phrase. A Lightning node does not, and this is the biggest difference to understand before you put money in. Channel state changes with every payment, and an old copy of that state can cost you funds. Both projects say so plainly.
For LND, the docs describe three pieces:
- The aezeed, a 24-word seed created when you first start the node. On its own it recovers all on-chain funds in the LND wallet, plus funds from channels your peers force close on you after your node goes offline. The docs suggest paper or encrypted storage; if you set a cipher seed passphrase, you need that too.
- The static channel backup, the channel.backup file. It is encrypted with your node's private key, so it only works with your aezeed. It is updated each time a channel opens or closes, and the docs say to keep a copy on a separate machine and update that copy whenever a channel opens. It does not revive channels. It lets your node ask former peers to force close them, and some peers may be slow or offline when you try.
- The channel.db file. LND's docs say to back it up regularly but not to rely on it, and warn that using it in a recovery is risky if it is not up to date: peers can invalidate your commitment transactions, and you can lose all funds in those channels. Use it only if you recovered it directly from the crashed node.
For Core Lightning, the backup page lists three as well. The hsm_secret file is created with the node and never changes, so a one-time backup is enough. Nodes created on version 25.12 or later use a 12-word mnemonic as that secret, and the docs say the best way to back it up is to print the words with Core Lightning's own hsmtool and write them on paper. If you set a passphrase, back it up separately, because recovery needs both. Older nodes get a codex32 string from the same tool. The hsm_secret is enough to recover on-chain funds but not channel funds, and the docs say there is no single-seed backup for funds locked in channels. The emergency.recover file is Core Lightning's static channel backup. It is updated each time you open a channel, so back it up after every new channel, and the docs call it a last resort that needs peer cooperation. For the database, the docs discourage snapshot-style backups, because any loss of state may mean permanent loss of funds, and say real-time replication is the recommended approach, with tools still in active development.
The common result in both: restoring from a seed plus a static channel backup closes your channels and returns the settled funds on-chain. That works, and it costs fees and time. Practice the restore with a small test node on spare hardware before you put in anything you would miss. A static channel backup restore closes every channel it recovers, so never practice with the backup of the node you plan to keep.
LND vs Core Lightning
Disclosure applies here: Blockstream maintains Core Lightning, and I work at Blockstream. Both are open-source, so the choice comes down to the details below. Details are as of November 2026.
| LND | Core Lightning | |
|---|---|---|
| Language and licence | Go, MIT | Mostly C with Rust plugins, BSD-MIT (bundled ccan modules have their own licences) |
| Bitcoin backend | Bitcoin Core, btcd, or Neutrino | Bitcoin Core by default, through a backend plugin that custom plugins can replace |
| Extending it | Add-on programs such as Loop, Pool, and Lightning Terminal | Plugins; the reckless installer supports Python and Rust plugins for now |
| Backup model | aezeed plus channel.backup; channel.db is risky to restore | hsm_secret plus emergency.recover; database replication is the recommended approach |
| Runs on | Windows, macOS, and Unix, with Unix recommended | Linux and macOS in the README; the install docs also list BSD and others |
| One-click on | StartOS, umbrelOS | StartOS, umbrelOS |
LND can run in Neutrino mode without a full Bitcoin node and has add-on programs for liquidity. Core Lightning has a plugin system, and even its Bitcoin backend is a plugin, though out of the box it expects bitcoind. Recovery works the same way in both: a static channel backup asks peers to force close, and neither can bring open channels back from a seed alone. On the database side, LND warns that restoring an out-of-date channel.db can lose channel funds, and Core Lightning's docs say its replication tools are still in active development. I would pick LND if you want Neutrino or the Loop and Pool tools, and Core Lightning if you want plugins. Both work.
One-click installs on StartOS and umbrelOS
The easiest way to run either one is on a node operating system. My Start9 vs Umbrel guide covers choosing between them. Install and sync the Bitcoin app first.
On StartOS, LND and Core Lightning are both packaged. Read the backup notes before you rely on them: each package deliberately leaves the channel database out of the StartOS backup, so a restore recovers the wallet and force closes your channels instead of resuming them. For LND, a StartOS backup also holds only the channel.backup that existed when it was taken, so a channel opened later is not in it. The LND package closes that gap with continuous backups: a copy of channel.backup kept on Google Drive, Dropbox, Nextcloud, SFTP, or email, updated whenever your channels change.
On umbrelOS, the app store lists Lightning Node, which runs LND, and Core Lightning.
Start with one or two channels and money you can afford to lose, and practice a restore before you add more.
Dashboards: RTL and ThunderHub
Both are free web dashboards for opening channels, setting fees, and watching balances. Ride The Lightning (RTL) is MIT licensed and works with LND, Core Lightning, and Eclair. ThunderHub is MIT licensed and works with LND only.
RTL has a StartOS package and an Umbrel listing. ThunderHub is on Umbrel as an app, and on StartOS as a community package rather than an official Start9 one. If you run Core Lightning, RTL is the pick. If you run LND, either works, and I would start with RTL because it keeps working if you switch implementations later.
Frequently asked questions
Do I need to run a Lightning node to use Lightning?
No. A self-custodial Lightning wallet lets you send and receive without running a node or managing channels. A node makes sense if you want to learn, take merchant payments, or already run a Bitcoin node.
Is LND or Core Lightning better for a home node?
Neither wins everywhere. LND has Lightning Labs' add-on tools and can run without a full Bitcoin node in Neutrino mode, while Core Lightning has a plugin system and uses Bitcoin Core by default. Blockstream maintains Core Lightning, so weigh my view with that in mind.
Can I restore my Lightning node from a seed phrase?
You can recover on-chain funds from the seed, and LND's seed also recovers funds from channels your peers force close on their own. For the rest of your channel funds you need a static channel backup, which asks your peers to force close the channels and return your money on-chain. Core Lightning's docs say there is no single-seed backup for funds locked in channels.
How much bitcoin should I keep in a Lightning node?
Keep only what you would carry as spending money. The wallet is hot, with keys on an internet-connected machine, and a bad backup or a failed disk can strand channel funds. Keep savings on a hardware wallet.
Can I run a Lightning node on a Raspberry Pi?
Core Lightning's install docs have a section on cross-compiling for Raspberry Pi. LND says to use a good SSD and not an SD card, so plan on an SSD for either one. You also need a synced Bitcoin node, which has its own hardware needs, so check the node guide first.