Running a Lightning Node: Complete 2026 Guide

Security advisory (5 November 2026): a flaw in the Linux kernel, CVE-2026-98432, affects home Lightning nodes running on Linux. The demonstrated attack needs a Multipath TCP listener, which LND 0.20.x and 0.21.x, Lightning Terminal, Loop and Alby Hub opened by default. Update LND to 0.21.6 or 0.20.7, and Lightning Terminal, Loop or Alby Hub if you run them; on Umbrel, update umbrelOS to 2.0.1 and then the Lightning Node app. Install your system’s kernel update now if it is out (Debian and Raspberry Pi OS have it); until then, turn Multipath TCP off. LND says the kernel patch is the only fix. The fixed versions and the exact commands are in the steps of our Lightning node advisory.

Affiliate disclosure: the Umbrel Home link in the software table below is an affiliate link (we may earn a commission). The Start9 Server One link next to it is not. Building your own node, as this guide does, is what we recommend for most readers.

What Is a Lightning Node and Why Run One?

A Lightning node is software that connects to the Bitcoin Lightning Network — a second-layer protocol built on top of Bitcoin that enables near-instant, low-fee transactions through a network of payment channels. If you are new to Lightning, start with our Lightning Network explainer for Bitcoiners. When you run a Lightning node, you operate a piece of this infrastructure directly.

Your node opens payment channels with other nodes, locks bitcoin into multisig contracts, and routes payments across the network. Every transaction that passes through your channels earns you a small routing fee. More importantly, running your own node means you verify every transaction yourself instead of trusting someone else’s infrastructure.

Here’s what running a Lightning node gives you:

• Full sovereignty — You hold your own keys and validate your own transactions. No custodial wallets, no third-party trust.
• Routing fee income — Well-connected nodes earn satoshis by forwarding payments. For a small home node the amounts are small, so treat them as a bonus; what you reliably gain is a working knowledge of how the network moves payments.
• Privacy — Sending payments from your own node means no wallet company sees your payments. Your channel partners and the nodes that forward a payment still see the part that passes through their own channels, and channel openings and closings are public on the blockchain.
• Network participation — Every new node strengthens the Lightning Network’s decentralization and routing capacity. At the last data point mempool.space publishes (30 August 2026), the public network had about 16,200 nodes and 32,700 channels, with about 3,800 BTC of public capacity. Private channels are not counted in those figures.
• Direct access to Lightning apps — Many Bitcoin applications (LNbits, BTCPay Server, Lightning Terminal) work best when connected to your own node.

If you already run your own Bitcoin node, adding Lightning is a natural next step. You already have the full blockchain synced — Lightning just builds on top of it. For a deeper look at how the protocol works under the hood, see our Lightning Network architecture guide.

Hardware Requirements

Running a Lightning node doesn’t demand server-grade hardware, but you need to meet certain minimums for reliable operation. Your node needs to stay online as much as possible — offline nodes can’t route payments and risk losing funds through outdated channel states.

Bitcoin’s blocks took about 780 GB on 28 October 2026 and grow about 80 GB a year (blockchain.com), so plan storage around the growth rate rather than a fixed snapshot. Here’s what you need:

Component	Minimum	Recommended
Device	Raspberry Pi 4 (4 GB RAM)	Raspberry Pi 5 (8 GB RAM) or x86 mini PC
RAM	4 GB	8 GB
Storage	2 TB SSD (USB 3.0); 1 TB is nearly full on day one	2 TB NVMe SSD
Power	Official 5V/3A adapter	UPS for power outage protection
Network	Stable broadband (10+ Mbps)	Wired Ethernet, unlimited data
Estimated Cost	~$350	~$500–$650

Storage note: The blocks alone fill about 78% of a 1 TB drive. Bitcoin Core also keeps undo data and the UTXO set (the list of every unspent coin), so Bitcoin Core 32.1 asks for at least 911 GB, and Umbrel’s Bitcoin Node also builds a transaction index and a block-filter index by default. A 1 TB drive is nearly full on day one. Buy 2 TB. A 2 TB NVMe SSD gives you years of growth headroom and faster sync times. The Raspberry Pi 5’s PCIe 2.0 interface supports M.2 NVMe drives natively through HAT+ boards, eliminating the USB bottleneck that plagued earlier Pi setups.

Why not a cloud VPS? You can technically run a Lightning node on a VPS, but it defeats the purpose of sovereignty. The VPS provider can access your keys, shut down your node, or hand over data to authorities. A $250 Raspberry Pi setup in your closet gives you actual control.

If you plan to run a hardware wallet alongside your node for cold storage management, the recommended setup handles both without issues.

Software Options Compared

Four major node management platforms dominate the self-hosted Lightning space. Each packages Bitcoin Core, a Lightning implementation (LND or Core Lightning), and supporting applications into a web-based interface. The differences come down to customization, community support, and extra features.

Feature	Umbrel	Start9 (StartOS)	RaspiBlitz	myNode
Lightning Implementation	LND + Core Lightning	LND + Core Lightning	LND + Core Lightning	LND
Interface	Web UI (polished)	Web UI (clean)	Terminal + Web	Web UI
App Store	300+ apps	Growing marketplace	Curated add-ons	Built-in apps
Supported Hardware	Pi 5/4, x86-64, Umbrel Home[#aff]	x86-64, ARM64, RISC-V, Pi 4, Server One	Pi 4/5	Pi 4/5, x86
NVMe Boot (Pi 5)	Possible on some setups; Umbrel recommends microSD	No (StartOS does not support the Pi 5)	Yes (v1.12.0+)	Yes
Tor Integration	Built-in	Built-in	Built-in	Built-in
Migration Support	Export/Import	Import from Umbrel/RaspiBlitz/myNode	Export/Import	Limited
Cost	Free for personal use (sells hardware)	Free (sells hardware)	Free / Open Source	Free community / $99 Premium
Best For	Beginners, app ecosystem	Privacy-focused users	Tinkerers, CLI users	Set-and-forget operators

Umbrel is the most popular option for first-time node runners. Its app store covers everything from block explorers to Nostr relays, and the one-click setup makes initial configuration straightforward. The LND integration includes a built-in Lightning dashboard for channel management and payment tracking.

Start9 (StartOS) prioritizes privacy and self-sovereignty. It installs on your own x86-64, ARM64 or RISC-V machine, or on a Raspberry Pi 4. Its docs say other Pi models are not supported. It sandboxes each service in its own environment and supports running LND and Core Lightning simultaneously. The migration tool is particularly useful — you can import your existing LND node from Umbrel, RaspiBlitz, or myNode without closing channels. For a head-to-head comparison, read Umbrel vs Start9: which node software.

RaspiBlitz is built for users who want terminal access and deep customization. It runs a nice LCD display on the Raspberry Pi for monitoring and offers the most granular control over your node configuration. Version 1.12.0 added NVMe boot support for Pi 5.

myNode takes a set-it-and-forget-it approach. The free community edition covers basic node operation, while the Premium tier ($99 one-time) adds watchtower monitoring, remote access, and one-click updates. Premium+ adds remote monitoring through mynodebtc.com. Before you choose it, check which Bitcoin Core version it installs: myNode v0.3.53, released on 8 November 2026, installs Bitcoin Core 32.1, but installs still on a Debian release before 12 stay on 27.2, which has reached its end of life: Bitcoin Core maintains its latest three major versions, 30 to 32 today (myNode changelog, myNode source, Bitcoin Core life cycle).

Pre-assembled boxes. Umbrel and Start9 also sell their own hardware, linked in the table above. The Umbrel Home has an Intel N150 and 1, 2 or 4 TB of NVMe storage, from $499. The Server One has an AMD Ryzen 5 6600H and 2 or 4 TB, from $899 to $1,399 depending on storage and memory; all four versions were for sale on 8 November 2026. Both cost about as much as, or more than, the Raspberry Pi build in this guide (about $500–$650 for the recommended setup in the hardware table), which is still what we recommend for most readers.

For a detailed analysis of node deployment architectures, see our Lightning node architecture and deployment guide.

Step-by-Step: Setting Up Your Lightning Node

This walkthrough uses Umbrel on a Raspberry Pi 5 — the most common setup for new operators. The process is similar for other platforms with minor variations. For a comprehensive home setup walkthrough covering additional platforms, see our guide on how to run a Lightning node at home.

Step 1: Prepare Your Hardware

1. Get a microSD card of 32 GB or more from a known brand. On a Raspberry Pi, umbrelOS runs from the card, and your apps live on it until you move them.
2. Have a 2 TB SSD ready for the blockchain (see the storage note above). Leave it unplugged for now, because Umbrel’s guide adds USB drives once setup is done.
3. Connect an Ethernet cable to your router. Wi-Fi works but wired is more reliable for a node that needs consistent uptime.
4. Use the official Raspberry Pi USB-C power supply (5V/5A for Pi 5). Umbrel warns that third-party supplies can cause stability problems, especially with a USB drive plugged in.

Step 2: Flash the OS

These steps follow Umbrel’s Raspberry Pi guide as of November 2026. If the guide has changed, follow the guide.

1. On a Pi 4, update the bootloader first. Many Pi 4 boards will not start umbrelOS 2.0 until you do. Umbrel’s guide shows how, and it takes about five minutes.
2. Download umbrelos-pi.img.zip from umbrel.com/downloads. The same file works on the Pi 5 and the Pi 4. Check it against the SHA-256 checksum listed on that page.
3. Flash it to your microSD card with Raspberry Pi Imager or Balena Etcher.
4. Insert the microSD card into your Pi 5, connect Ethernet and power it on.
5. If a USB drive is connected during setup, umbrelOS asks you to select main storage. Umbrel’s guide says to choose the SD card. The drive then shows up as external storage.

Umbrel also lets you try running umbrelOS from a USB drive, or from an NVMe drive on a Pi 5, instead of a card. It says this does not work on every setup yet and recommends the microSD card for now.

Step 3: Initial Setup

1. Wait a few minutes for the first boot, then open a browser and navigate to http://umbrel.local (or find your Pi’s IP address on your router).
2. Create your account with a strong password.
3. Plug in your SSD. It shows up under External storage in Files. To hold apps it must be formatted as ext4. If it is not, right-click it there and choose Format (this erases the drive).
4. Install Bitcoin Node from the App Store, then move it onto the SSD straight away: open the app’s settings and choose Storage, then App storage, then Move. A 32 GB card cannot hold the blockchain.
5. Bitcoin Core then syncs the blockchain. Initial Block Download (IBD) takes about 2–4 days on a Pi 5 (3–7 on a Pi 4), depending on your drive and internet speed.

Two things to know about this layout, from Umbrel’s external storage guide (checked 3 November 2026): the SSD has to stay connected while Bitcoin Node runs, and apps stored on an external drive are not included in umbrelOS Backups.

Step 4: Install the Lightning Node App

1. Once Bitcoin Core has fully synced, open the Umbrel App Store.
2. Install Lightning Node (powered by LND). On 3 November 2026 Umbrel’s Lightning Node app ran LND v0.21.6-beta. The 0.21 series, first released in June 2026, added production simple taproot channels and basic onion-message support.
3. Wait for LND to sync with the blockchain. This takes a few minutes since it reads from your already-synced Bitcoin Core.

Step 5: Secure Your Seed Phrase

1. Open the Lightning Node app and navigate to settings.
2. Write down your 24-word seed phrase on paper. Store it securely — this backs up your on-chain funds.
3. Important: The seed phrase alone does NOT back up your Lightning channels. You need Static Channel Backups (SCB) for that — more on this in the maintenance section.

Step 6: Connect a Wallet (Optional)

1. Go to Lightning Node settings and find the connection credentials.
2. Scan the QR code with a compatible mobile wallet (Zeus, for example) to manage your node remotely. For a comparison of the best Lightning wallets in 2026, see our dedicated review.
3. Alternatively, use Lightning Node Connect (LNC) for a Tor-free remote connection through Lightning Terminal.

For more on node operation patterns and configuration, check our personal node operation guide.

Opening Your First Channels

Your node is synced and running. Now it needs channels to participate in the network. A payment channel is a multisig Bitcoin transaction between your node and another node — once open, you can send and route payments through it instantly. If you want to manage your on-chain funds with multisig while running a node, our Sparrow Wallet multisig tutorial walks through the process.

How to Find Good Peers

Not all peers are equal. A well-chosen peer improves your routing capabilities and earns more fees. Look for:

• High uptime — Peers that go offline frequently will freeze your liquidity in unusable channels.
• Good connectivity — Nodes with many channels can route your payments through more paths. Check nodes on amboss.space or 1ml.com before connecting.
• Services you use — Open a channel directly to a merchant (Bitrefill, for example) or a service you pay regularly, so those payments need no route.
• Lightning Network+ — Use lightningnetwork.plus to join triangle or ring-of-fire channel openings, where multiple operators open channels simultaneously to boost each other’s connectivity.

Channel Size Guidelines

Your first channels define your node’s initial capacity. Here are practical guidelines:

• Minimum for routing: about 500,000 sats (0.005 BTC). Smaller channels can only forward small payments, and the on-chain fees to open and close them weigh more against what they earn. For your own payments, a smaller channel is fine.
• Recommended first channel: 2,000,000–5,000,000 sats. Large enough to route meaningful payments, small enough to limit risk while you learn.
• Wumbo channels: Channels above 16,777,215 sats (about 0.17 BTC) require both peers to support large channels. In LND you turn this on with protocol.wumbo-channels=true.
• Total starter allocation: Open 3–5 channels with a total of 5,000,000–15,000,000 sats. Spread across different types of peers for balanced routing.

Setting Your Routing Fees

Routing fees have two components:

• Base fee — A flat fee per forwarded payment (measured in millisatoshis). Common range: 0–1000 msat.
• Fee rate — A proportional fee based on the payment amount (measured in parts per million). Common range: 1–500 ppm.

Start with moderate fees (base: 1000 msat, rate: 200 ppm) and adjust based on your channel utilization. If channels drain quickly in one direction, raise the fee on that side. Tools like charge-lnd can automate fee adjustments based on channel balance ratios. For a thorough breakdown of fee structures and optimization strategies, read our Lightning Network fees guide.

For deeper strategies on channel management, read our Lightning channel management best practices.

Managing Liquidity

Liquidity management is the single most important ongoing task of running a Lightning node. Understanding it is the difference between a functional node and a frustrating one.

Inbound vs. Outbound Liquidity

Every channel has two sides:

• Outbound (local) liquidity — Funds on your side of the channel. You can spend these or forward them in routing. When you open a new channel, 100% of the funds start as outbound liquidity on your end.
• Inbound (remote) liquidity — Funds on your peer’s side. Others can send payments to you through this capacity. New nodes typically have zero inbound liquidity — this is the biggest challenge for beginners.

How to Get Inbound Liquidity

• Spend through your channels — Every sat you spend becomes inbound liquidity. Buy gift cards on Bitrefill, pay invoices, or purchase from Lightning-enabled merchants.
• Loop Out — Lightning Labs’ Loop service lets you send sats from your channel to an on-chain address, converting outbound to inbound liquidity. Run loop out --amt 500000 to move 500k sats on-chain. For a full walkthrough, see our Lightning Loop and submarine swaps tutorial.
• Join a liquidity swap — On lightningnetwork.plus, a group of operators open channels at the same time: each opens one channel and receives one from another participant. You gain inbound capacity in return for the channel you open, paying only its on-chain opening fee.
• Buy a channel — Lightning Service Providers (LSPs) and marketplaces such as Amboss’s Magma sell inbound channels: you pay a fee and a seller opens a channel to your node. This costs money but provides immediate liquidity.

Rebalancing Channels

Over time, channels become lopsided — heavy outbound on one side, heavy inbound on another. Rebalancing sends a circular payment from your node through other nodes and back to yourself, evening out the balances.

Tools such as Balance of Satoshis (bos rebalance) find a route and send the circular payment for you, up to the most you are willing to pay in fees. To check your balances, or to make room on one channel with Loop Out instead:

# Check channel balances
lncli listchannels | jq '.channels[] | {alias: .peer_alias, local: .local_balance, remote: .remote_balance, capacity: .capacity}'

# Loop Out 1,000,000 sats from one channel (adds inbound liquidity to it)
loop out --amt 1000000 --channel 824637184278528

# Turn on Autoloop with a fee budget of 50,000 sats every 168 hours (one week)
loop setparams --autoloop=true --autobudget=50000 --autobudgetrefreshperiod=168h

# Keep at least 25% inbound and 25% outbound on this channel
loop setrule 824637184278528 --incoming_threshold=25 --outgoing_threshold=25

Autoloop automates Loop Out. You give it a fee budget and a rule for each channel or peer, such as the 25% thresholds above. About every 20 minutes it checks your channels and, within the budget, starts a Loop Out on any channel whose inbound share has dropped below its threshold. It only adds inbound liquidity, while a circular rebalance moves sats between your own channels. The commands are in Loop’s Autoloop documentation.

For more details on channel dynamics and network participation, see our Lightning Network liquidity guide.

Watchtowers: Protecting Your Channels Offline

A watchtower is a service that monitors your channels and broadcasts a penalty transaction if a peer tries to cheat by closing a channel with an outdated state. This matters because Lightning’s security model assumes you’re online to catch fraud — but no one has 100% uptime.

How Watchtowers Work

Every time your channel state updates (after each payment), your node generates an encrypted justice transaction and sends it to the watchtower. The watchtower can only decrypt it if the specific old state appears on-chain — meaning the peer attempted to cheat. When that happens, the watchtower broadcasts the penalty transaction, which sends both balances in the channel to you. LND’s towers don’t cover payments that were still in flight.

LND supports “altruist” watchtowers — they return all funds to the victim minus on-chain fees, with no cut taken. Ideally, you run your own watchtower on a separate machine in a different location.

Turn the client on when you open your first channel. LND ships with it switched off (wtclient.active=false), and a tower only learns the balances revoked while the client runs: one added the night before a trip leaves every older balance unguarded. Without a tower, your node can be off for no longer than the shortest waiting period among your channels, about a day (144 blocks) on small LND channels.

Enabling the Watchtower Client

Add wtclient.active=true to lnd.conf, under a [wtclient] section as in LND’s sample configuration:

[wtclient]
wtclient.active=true

Restart LND so it reads the change (until then, lncli wtclient add fails with “watchtower client not active”), then add a watchtower peer:

# Add a watchtower (replace with actual URI)
lncli wtclient add 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63@watchtower-ip:9911

# Verify it's connected
lncli wtclient towers

# Check tower statistics
lncli wtclient stats

Running Your Own Watchtower

If you have a second machine (a VPS, a second Pi, or any always-on computer), you can run your own watchtower. Add these keys to lnd.conf on the watchtower machine, under a [watchtower] section as in LND’s sample configuration:

[watchtower]
watchtower.active=true
watchtower.listen=0.0.0.0:9911

After restarting LND, get the tower’s public URI:

lncli tower info

Use this URI on your main node to add it as a watchtower client. A second tower run by someone you trust, in another place, covers the day your own tower is down too.

Umbrel and Start9 users can enable watchtower functionality through their respective app settings without editing config files directly. For a complete walkthrough covering all platforms, read our Lightning watchtower setup guide.

Maintenance and Monitoring

A Lightning node isn’t set-and-forget. Regular maintenance keeps channels healthy, funds safe, and software current.

Keeping Software Updated

Updates contain security patches, bug fixes, and protocol improvements. How often you update depends on your platform:

• Umbrel/Start9 — One-click updates through the web interface. Check weekly.
• myNode — With Premium, you upgrade from the Settings page in one click. The free Community Edition upgrades over SSH or by re-flashing the SD card, as myNode’s upgrade guide shows. Check weekly, and check which Bitcoin Core version the upgrade installs.
• RaspiBlitz — Run the update script from the menu or terminal. Check the GitHub releases page for changelogs before updating.
• Manual LND — Follow the migration guide in the release notes. Always read the changelog for breaking changes before upgrading.

Rule of thumb: Apply security patches immediately. Wait 1–2 weeks after a major version release for others to surface bugs before upgrading, unless the release fixes a vulnerability that affects you.

Channel Backups

This is non-negotiable. If your node’s storage fails and you have no copy of channel.backup, getting your channel funds back is hard and not guaranteed.

• Static Channel Backups (SCB) — LND keeps a channel.backup file and rewrites it each time a channel opens or closes. Restored with your 24 words on a new node, it asks each peer to force-close its channel: once that peer is online and closes, your settled balance comes back on-chain. If the old node still exists, keep it off for good. It doesn’t keep the channels: you’ll need to reopen them after recovery. Copy it off the node after every channel you open or close.
• Automatic backup — Umbrel’s Lightning Node app uploads an encrypted copy to Umbrel’s backup server by default; keep your own copy as well. For manual setups, a cron job copies the file on a schedule; copy it by hand too right after you open or close a channel, because a scheduled copy can miss a channel opened since the last run:

  # Copy channel.backup every 6 hours to a remote location
  0 */6 * * * scp ~/.lnd/data/chain/bitcoin/mainnet/channel.backup user@backup-server:/backups/lnd/
  

• Never restore an old channel.db — it is LND’s live record of every channel’s latest balance. An old copy holds out-of-date balances, and putting it back on a node publishes them, which counts as cheating: your peer can take everything in the channel. Restoring a snapshot of the whole machine counts too, if it includes the Lightning data. A copy kept aside is not a backup, though chantools can extract a channel.backup from it if you lose yours. umbrelOS Backups leave the Lightning Node app’s channel.db out on purpose.
• Test your backups — lncli verifychanbackup --multi_file=/path/to/channel.backup checks that a copy is intact and belongs to your node, without touching your channels. Our lesson on Lightning backups and watchtowers explains what a restore brings back.

Monitoring Tools

Several tools help you track node health and performance:

• Ride The Lightning (RTL) — Web-based node management dashboard. Comes pre-installed on most node platforms. Shows channel balances, forwarding history, and fee analytics.
• ThunderHub — Alternative to RTL with a cleaner interface and advanced features like batch channel opens and automated fee management.
• lndmon — Prometheus + Grafana monitoring for LND. Exports metrics you can graph: channel balances over time, forwarding volume, fee revenue, peer uptime.
• Balance of Satoshis (bos) — CLI tool for advanced node operations. Run bos accounting for profit/loss reports, bos peers for channel health checks.
• Amboss.space — Public dashboard for your node. Useful for tracking reputation and seeing how others view your node’s connectivity.

Routine Maintenance Checklist

• Daily: Check that your node is online and reachable. Monitoring tools or a simple lncli getinfo confirms this.
• Weekly: Review channel balances and forwarding activity. Identify dead channels (peers offline for 2+ weeks) and consider closing them.
• Monthly: Evaluate fee strategy, check for software updates, verify backups are current, review disk space usage.
• Quarterly: Assess overall node performance, close underperforming channels, open new channels to better-connected peers.

Common Mistakes to Avoid

Most node operators learn these lessons the hard way. Save yourself the trouble:

1. Opening channels that are too small for routing — Channels under about 500,000 sats can only forward small payments, and the on-chain fees to open and close them weigh more against what they earn. For routing, start with at least 2,000,000 sats per channel; for your own payments, any amount you are comfortable having locked up is enough.
2. Ignoring inbound liquidity — A node with only outbound liquidity can send but can’t receive or route payments effectively. Use Loop, spend through channels, or join channel opening groups to build inbound capacity.
3. Leaving your node’s data on the SD card — On a Raspberry Pi, umbrelOS runs from the microSD card and keeps apps on it until you move them. Umbrel itself notes that microSD cards “are slower than SSDs and wear out over time”. Move Bitcoin Node to an SSD, back up your Umbrel regularly, and keep copies of your Static Channel Backups off the device.
4. Not backing up channels — Your seed phrase recovers on-chain funds only. Without SCB files, channel funds are at risk if your storage dies.
5. Force-closing channels unnecessarily — When you force-close, your own share is locked for up to 2 weeks (the time-lock delay), and the extra transactions cost more in on-chain fees. Always try a cooperative close first.
6. Setting fees to zero — Zero-fee routing attracts heavy traffic that drains your channels without compensation. Set at least a minimal fee rate (50–100 ppm) to deter channel draining.
7. Opening channels to random nodes — Research peers before connecting. Check their uptime, channel count, and routing capacity on amboss.space or 1ml.com. A peer with 10% uptime will make your channel useless.
8. Not enabling a watchtower — If your node is offline for longer than a channel’s waiting period (about a day on small LND channels) and a peer broadcasts an old channel state, you can lose that channel’s funds. Turn on the watchtower client when you open your first channel and add at least one tower.
9. Putting all liquidity in one channel — Diversify across 3–5 channels minimum. One channel going down shouldn’t paralyze your node.
10. Updating LND without reading release notes — Major versions sometimes include database migrations that can take hours. Read the changelog, plan for downtime, and copy a fresh channel.backup off the node before upgrading.

Frequently Asked Questions

How much does it cost to run a Lightning node?

When we priced this guide, hardware came to about $350–$650: a Raspberry Pi 4 with a 2 TB SSD at the low end, a new Raspberry Pi 5 with a 2 TB NVMe drive, case and UPS at the top. Memory and drive prices rose through 2026, so check current prices. Electricity depends on your power draw and your price: a device drawing 10 W around the clock uses about 88 kWh a year, about $18 at $0.20 per kWh. You’ll also need on-chain bitcoin for opening channels — budget at least 500,000 sats per channel, and plan to open 3–5 channels initially. The on-chain fees for opening and closing channels vary with how busy the network is: as of November 2026, 1 to 3 sat/vB is usually enough, and at 1 sat/vB opening a channel costs about 150 sats and a cooperative close about 190. At the 300 sat/vB seen in December 2023, each step costs tens of thousands of sats.

Can I earn money routing payments on Lightning?

Yes, but expect small amounts. There is no reliable public data on what small nodes earn, so do the arithmetic instead. At 100 ppm your node keeps 100 sats for every million it forwards, so a small node that forwards a million sats a day earns about 3,000 sats a month. Many small nodes forward much less. Against that, count the on-chain fees to open and close channels and the cost of rebalancing; plenty of hobby nodes spend more than they earn. Our Lightning Channel Management: Best Practices guide covers routing strategy. Most small operators run nodes for sovereignty and learning, and treat any fee income as a bonus.

What happens if my Lightning node goes offline?

Your channels stay open but inactive. No one can route payments through them while you’re offline, and you can’t send or receive payments. The primary risk is a dishonest peer broadcasting an old channel state (a “breach attempt”) while you’re unable to respond. This is exactly why watchtowers exist — they monitor for breach attempts and broadcast penalty transactions on your behalf. How long is safe depends on the waiting period your node set for each peer: with LND’s defaults, 144 blocks, about a day, on channels under about 1.2 million sats, rising to 2,016 blocks, about two weeks, on the largest. Without a watchtower, keep outages shorter than your shortest window, with a margin; with one that has been watching since your first channel, longer outages are covered. Extended offline periods (weeks) may also cause peers to force-close channels with you.

Should I run LND or Core Lightning?

LND is the more common choice for home node operators. It has broader mobile-wallet support (Zeus among them), more management tools (RTL, ThunderHub, Balance of Satoshis), and the largest user community for troubleshooting. Core Lightning (CLN) offers a plugin architecture that allows deeper customization and tends to use fewer resources. If you’re a developer who wants to build on Lightning, CLN’s plugin system is powerful. For first-time operators, LND is the safer choice — the tooling ecosystem is more mature and finding help is easier.

How do I close a Lightning channel safely?

Always try a cooperative close first — this produces a normal Bitcoin transaction that settles immediately after confirmation:

# Cooperative close (preferred)
lncli closechannel --chan_point=funding_txid:output_index

# Force close (only if peer is unresponsive)
lncli closechannel --force --chan_point=funding_txid:output_index

A cooperative close splits the channel balance between both parties and confirms in the next block (assuming appropriate fee). A force close uses a pre-signed commitment transaction and locks your funds for a time delay (typically 144–2016 blocks, or 1–14 days). Only force-close when your peer is permanently offline or unresponsive. After closing, wait for the on-chain transaction to confirm before considering the funds settled. For advanced channel management and privacy considerations, see our technical deep dive.

Related Resources

• Lightning Network Architecture: Privacy Guide — How the Lightning protocol works at the architectural level, including privacy implications of different routing strategies.
• Lightning Channel Management: Best Practices — Advanced strategies for channel balancing, fee optimization, and peer selection.
• Lightning Node Setup: Personal Operation Guide — A broader guide to running Lightning infrastructure, covering operational patterns beyond basic setup.
• How to Run a Lightning Node at Home — Technical comparison of deployment architectures, security models, and implementation choices.
• Lightning Troubleshooting: Failed Transactions — How to diagnose and fix Lightning payments that fail.
• Lightning Network Liquidity: Channel Guide — Deep dive into liquidity dynamics, channel economics, and network participation strategies.
• Why Run Your Own Bitcoin Node — The case for running a full Bitcoin node, which is a prerequisite for your Lightning node.
• Hardware Wallet Buying Guide 2026 — Choosing the right hardware wallet for managing your on-chain funds alongside your Lightning node.