Lightning, at a high level, is ultimately just software running on a group of online computers to form a network. Users are free to join and leave the network with their own individual nodes, much like how they can for the underlying consensus layer — Bitcoin. Lightning node software is written in a variety of programming languages and is typically portable to many different operating systems and CPU architectures. Nodes are connected to the internet and manage hot bitcoin wallets, so the underlying software and hardware is important for keeping private keys safe.

Core Lightning (CLN) is one of the handful of Lightning node implementations and runs on practically any *nix operating system, as well as Windows using WSL. CLN can also be built and run on different CPU architectures like x86, POWER, RISC-V, and ARM too.

Choosing which software and hardware to use for a Lightning Network node can be pretty daunting. Should you use an old Thinkpad? Raspberry Pi? A used rackmount server? Ubuntu? FreeBSD? Windows?

Each choice you make has trade-offs in terms of openness (e.g. closed source firmware), software support, compute ability, power usage, data integrity, and even noise (1U fans are LOUD).

For this article, we’ll explore the ideal combination of hardware and software for a home-based routing node. Let’s go over some of the hardware options.

Consumer Hardware

Typical desktop and laptop hardware fall under this category. Most desktops are actually fairly decent for running a LN routing node since you can add more storage devices and potentially create a RAID array, but they tend to lack ECC memory support unless you opt for more expensive workstation / enterprisey options. Consumer desktop hardware also lacks open firmware options unless you go the route of manually flashing your chips, which can backfire and brick your hardware.

Laptops are okay since they have some fault tolerance given the batteries, but they lack the IO to have redundant storage and the ECC memory support — although there are a handful of models that do have ECC strangely…

Consumer hardware can be cheap (e.g., Raspberry Pis), but not include things like proper IO, ECC memory support, or firmware auditability which I think are essential for an online computer managing hot private keys.

Rack Hardware

Rackmount hardware is a crapshoot. You can pick up pretty decent decommissioned enterprise units off of eBay, but they’ll be either expensive, loud, partly broken, lacking hardware or IO, include closed firmware, or some combination of those things. Of course, you can build your own, but that can become expensive, and there is a sad lack of open firmware options.

99% of the time, the ebay rackmount units will have LOUD high-RPM fans that penetrate drywall and can be heard throughout your home, so that’s something you’ll appreciate learning before pulling the trigger on buying one.

Having touched briefly on some of the (IMO not great) options available for running a LN node, here’s a list of hardware and software components that seem ideal to me.

I believe this hardware/software list is well-balanced for price, openness, data integrity, reliability, power usage, and compute ability. I don’t list off less important hardware like the computer case or power supply, but the general rule is don’t cheap out.

Ideal Hardware

SynQuacer Linaro96board

CPU: 24-core ARM Cortex-A53
RAM: 32 GB of ECC DDR4 (included with mobo purchase!)
IO: three PCIe slots and two SATA ports
Power usage: ~35 watts with 32 GB RAM, 4x SATA SSDs
Cost: ~$415 US

This ARM board is pretty exceptional for a Lightning node for many different reasons:

Many Cores

The ARM Cortex-A53 is extremely popular and has been used in cheaper SoCs like the Raspberry Pi 3. The difference with this board is there are 24 A53 cores instead of the usual four, which lets you run a larger LN node with many open channels. I’ve tested 100+ channels while running the CLBOSS plugin. ARM is now ubiquitous, too, with excellent software support among operating systems, and especially in the Bitcoin software ecosystem. There are also some security benefits to using ARM over x86 that I won’t go into detail here but are related to SPECTRE and other architectural flaws in x86 processors.

Safe Memory

One of the most important components of this motherboard is the ECC memory support. Without ECC, bad things can happen. ECC memory ensures the integrity of your important Lightning data, so bit rot and other harmful things can’t permanently corrupt your data and cause funds loss. The board includes 32 GB of ECC DDR4 memory with purchase, which is pretty awesome! That is plenty for a CLN node.

Plenty of IO

With two SATA ports and three PCIe slots, you can easily build an array of disks for storage, whether it’s using software RAID, ZFS, BTRFS or whatever you’re comfortable with. You can’t do that with an RPi! Well, not easily, I guess.

The combination of ECC memory and the ability to have redundant storage (which doesn’t rely on flaky USB) makes this board an excellent choice for any use case that requires data integrity — including running a Lightning node.

Power Efficiency

By running this SynQuacer board with e.g. four SSDs and 32 GB of memory you can reach a whopping ~35 watts of power draw. This means you’ll save on your power bill and keep more of your earnings from routing compared to other CPU architectures like x86 and POWER.

Auditable Firmware

One of the primary reasons for choosing this board is its open firmware. Inspect the board’s firmware, compile it yourself, and install it. Good luck doing that with 99% of other available platforms.

Build Source for Developerbox

Developerbox contains a Cortex-M3 System Control Processor(SCP) which manages system power and is responsible for…

www.96boards.org

Storage Hardware

For storage, go SSD. Samsung makes excellent SSD s— particularly their Pro models. Buy a few depending on your budget and set up a mirror, so data is duplicated to the devices. Don’t go overboard with complicated setups. We just need duplication and device failure tolerance. For a multi-device storage array, you will likely need a PCIe SATA adapter to run more SSDs.

Ideal Software

Operating System

Choose a good *nix such as Ubuntu, Debian, Fedora, or a BSD like FreeBSD. What matters most is your familiarity with the OS you choose. CLN and related software runs best on *nix, so I would definitely advise against running a routing node on Windows or macOS.

Lightning Node Implementation

I’m partial to Core Lightning since it’s designed to be modular, performant, and resource-efficient, and that’s important for limited systems (practically any ARM device). Most importantly, its developers focus on specification compliance, which means your routing node can interoperate with other implementations on the Lightning Network.

Plugins let you customize your CLN node with the amount of functionality (read: complexity) you can tolerate. You can run a minimal node or not; it’s up to the user!

CLN Plugins

If you opt for adding plugins to your node, these are a couple I recommend.

CLBOSS: Fully automate your CLN node
Summary: Generate a tidy summary of your LN status, like inbound/outbound sats, msats earned, and more

There are a slew of plugins available. Many are created by the awesome community contributing to Core Lightning. Check them out!

GitHub - lightningd/plugins: Community curated plugins for core-lightning

Community curated plugins for c-lightning. To install and activate a plugin you need to stop your lightningd and…

github.com

Storage

Storage mirroring is a must. At a minimum, your CLN data directory should live on a RAID mirror with two SSDs (ideally Samsung Pro units), for better reliability and power efficiency relative to hard disk drives. Unless you’re logging with debug output firehose turned on, you won’t need much storage space. This means your storage array can be cheap. You can always compress logs too. Bitcoin blockchain data can be placed on a separate single drive. We don’t need to have it on our mirror.

Filesystem

The filesystem should be a modern one such as Ext4, XFS, or potentially ZFS or btrfs but I personally avoid these since I like to keep things as simple as possible. ZFS is an excellent project but much of the functionality would go unused in this use case. Btrfs, in my experience, is a nightmare. XFS does metadata checksumming, RAID mirroring provides hot spare(s) in case of device failure, and XFS is well-supported in the Linux kernel. Of course, if you choose FreeBSD as your node’s OS, then ZFS is basically your only choice aside from UFS.

Like the operating system choice, it’s more important for you to be familiar with the tools you use than for the tools to have fancy functionality that you can shoot your toes off with.

Backups

The Core Lightning docs include a comprehensive list of backup options for a node. Here’s a shortlist:

Mirroring
Probably the simplest and most effective route is to have a storage mirror with RAID. While some may not consider having a hot spare a “backup”, this situation is a little different since you simply cannot have long-term LN backups due to channel state needing to be constantly updated.

Remote DB
More advanced users can set up a remote device that your CLN node writes to over the network in order to save channel state. This is useful for avoiding a full local system crash — your data will at least be written to an entirely separate remote device and hopefully provide some recoverability.

Secondary DB on separate local storage
CLN also supports writing to separate local databases concurrently. As an example, this lets you plug in a USB storage device and write to it while at the same time writing to the primary storage device(s). This is similar to using a mirror, but you can mix different storage devices this way to avoid same-age / same-manufacturer device failure scenarios.

Highly sensitive CLN data is listed below. They’re located wherever you set your CLN data directory to, which is by default ~/.lightning .

hsm_secret : This is the secret for your node’s on-chain wallet. You can back this up once and be able to recover any on-chain funds.
lightningd.sqlite3 : This is repeatedly written to while your node is running. It contains toxic channel state that if restored incorrectly will result in a loss of funds. Be careful, and keep track of the backup date so you don’t restore old toxic channel state accidentally.

Ideal Extras

Uninterruptible Power Supply

Outfit your CLN node with a UPS in case there are power outages. These outages can cause data corruption, which is our primary enemy when running a LN node.

Connectivity

Research ISP options in your local area and pick the most reliable. No matter what you pick, residential ISPs will bring down your home connection for maintenance from time to time. Lightning is designed to be fairly resistant against temporary outages, but it’s best to have a backup just in case.

Cell networks have high reliability considering their usage by emergency services. Spend some time researching how you can leverage mobile device tethering in case your main ISP goes offline. Or you can have a dedicated 4G antenna setup for redundancy.

Node Privacy

Using a VPN to hide your home IP address is also a good idea. A cheap $5 Digitalocean or Vultr VPS and Warren Togami’s guide will get you set up. This will allow you to run a LN node from home but use the VPS’s IP address as the IP you announce to other LN nodes. Avoid running over Tor as that introduces too much latency for payments, causing them to fail and ruin your chance at collecting a forwarding fee.

GitHub - wtogami/vpn-nat-service-forwarding-howto: VPN NAT Service Forwarding HOWTO

This guide describes how to configure a VPN frontend server where incoming TCP IPv4 connections are forwarded over a…