A Lightning node is two nodes
This trips up almost everyone. Lightning doesn't run on its own — it's a layer on top of Bitcoin, and it needs a fully validating Bitcoin node underneath it, on the same server, that it talks to constantly. So "run a Lightning node" really means "run a Bitcoin full node, and then run a Lightning node against it."
That underlying Bitcoin node has to download and verify the entire blockchain from genesis. This is the initial block download, and it is the first wall you hit:
- The full Bitcoin blockchain is well over 600 GB and grows by roughly 40–50 GB a year. Budget storage generously; running out of disk mid-sync is a miserable way to spend an evening.
- You can run a pruned Bitcoin node — keeping the recent chain and discarding old blocks — which cuts you down to something like a 15–20 GB working set plus the initial download. Pruning works with Lightning, with caveats: some operations that need old block data get slower or need a fallback. For a personal node it's usually the right call, and it turns the disk problem from "expensive" into "manageable."
- Either way you must validate the whole chain once. Initial block download takes anywhere from several hours on a fast box with good bandwidth to a couple of days on a modest one. CPU and disk I/O are the bottleneck, not RAM. An SSD is not optional here; on spinning disk the sync is genuinely painful.
Only after Bitcoin is fully synced does the Lightning node have something to attach to. Plan for the whole first day to be sync-and-wait.
The part that can actually lose your money
Read this one twice. On the Bitcoin base layer, your funds are recoverable from your seed phrase — twelve or twenty-four words, back them up on paper, done. Lightning is different, and the difference is the single most important thing on this page.
A Lightning channel is a shared balance between you and a peer, and its current state changes every time funds move through it. Your node has to know the latest state to close a channel correctly and get your money out. If you restore from a backup that is even slightly out of date — an older channel state — you can broadcast a stale commitment. To the network, publishing an old state looks exactly like an attempted cheat, and the protocol's penalty mechanism can let your peer take the entire channel balance. A stale channel backup isn't a minor inconvenience. It can zero the channel.
So the rules are non-negotiable:
- Back up your channel state (LND calls this the Static Channel Backup, or
channel.backup), and back it up every time your channels change — automate it, don't do it by hand. - Never restore an old channel backup to a running node and reopen it as if nothing happened. If you're recovering from a real backup, understand that the safe path is to use it to force-close and recover funds, not to resume operating on stale state.
- Your seed phrase alone is not enough for Lightning. It recovers your on-chain wallet. It does not, by itself, recover in-flight channel balances. This is the exact opposite of the mental model you built up on the base layer, and it catches people who assumed "I have my seed, I'm fine."
If that paragraph makes you nervous, good. The people who lose Lightning funds are almost always the ones who treated channel backups the way they treat a seed phrase: set once, forget.
Uptime is a feature now
On the base layer your node can be offline for a week and nothing bad happens. Lightning assumes you're watching. Channels are secured by the ability to respond if a peer tries to close on old terms, and if your node is down for long stretches it can't defend itself. In practice, for a personal node this risk is modest — your peers aren't usually trying to cheat you — but it's real, and it's why "run it on the laptop I close every night" is bad advice. A Lightning node wants to be always-on, which is precisely what a VPS is good at and a home machine on residential power and a flaky ISP is not.
There are mitigations (watchtowers, which are third-party services that watch for cheats on your behalf while you're offline), but the honest summary is: this is a service with an uptime expectation, and you're now on the hook for it.
The ongoing work nobody advertises
Say you're synced, backed up, and online. You're not done — you're started. The recurring tax:
- Liquidity management. A channel has your money on one side. To receive payments you need inbound liquidity — capacity on the other side — and getting it means opening channels to well-connected peers, or paying for inbound, or using services that provide it. This is the part that feels like a puzzle for weeks. "Why can't I receive payments?" is almost always a liquidity answer, not a bug.
- Channel economics. On-chain fees to open and close channels are real money. Opening five channels when fees are high, then closing them a month later, can quietly cost more than you saved by not using a custodial wallet. Batch your channel operations when fees are low.
- Routing, if that's your goal. If you want to route others' payments and earn fees, that's a whole discipline of rebalancing and fee-tuning, and realistic returns are small unless you commit serious capital and attention. Don't do it expecting income. Do it because the mechanics interest you.
Which client, briefly
Two mature choices. LND is the most widely deployed, has the richest tooling ecosystem, and the largest community, which mostly means the answer to your problem is already on a forum somewhere. Core Lightning (CLN) is leaner, very robust, and favored by people who like a smaller, more Unix-y system. Both sit on top of a bitcoind full node. If you have no strong opinion, LND has the gentlest on-ramp because everything is documented to death. If you like minimal and hackable, CLN.
Bundle distributions exist that wire bitcoind plus a Lightning implementation plus a web dashboard together and save you a lot of manual config. They're a reasonable way to start, as long as you understand what's underneath — because when it breaks, you're still the one operating a Bitcoin node and a Lightning node, dashboard or not.
So who is this actually for?
Be honest with yourself here, because the answer determines whether you'll be glad you did this in six months.
Run your own Lightning node if you want to genuinely understand the second layer, if you value routing your own payments without a custodian in the middle, if you want to experiment with the protocol, or if self-sovereignty is the point rather than a side effect. Those are all good reasons, and a VPS with real storage and steady uptime is close to ideal hardware for it.
Do not run one if what you actually want is to occasionally pay with Lightning. If your goal is spending sats at a checkout now and then, a good mobile Lightning wallet — even a non-custodial one — gives you the payment experience with none of the sync, backups, liquidity juggling, or uptime obligation. You'd be building and maintaining a small piece of financial infrastructure to accomplish something a 30 MB app does for free. There's no shame in that answer; matching the tool to the need is the whole skill.
If you do decide to run one, the base-layer requirements are unforgiving in exactly one dimension: disk. You need a plan with real storage headroom and an SSD, kept online. Somewhere like NoctHost that bills hourly from a prepaid balance and lets you pick a generous-disk plan without a card is a natural fit — you can size for that 600-plus-GB chain, and if the experiment isn't for you, you're not locked into a year of it. But the provider is the easy part. The commitment is the channel backups. Get those right and the rest is just patience.