VPS-XL · VPS
- AMD EPYC 9124 (8 vCPU)
- 32 GB DDR5 · 400 GB NVMe
- 1 Gbps · Unlimited bandwidth
Pruned bitcoind + LND fit in 400 GB NVMe and 32 GB RAM — a serious hobby routing node at VPS price.
Lightning channels are live contracts: if your node goes offline you can't route, can't receive, and in the worst case an old channel state gets force-closed against you. Home nodes die with power cuts and flaky uplinks. A datacenter node with redundant power and unmetered bandwidth keeps your channels breathing 24/7 — and because the node holds hot keys, the no-KYC part matters twice: nobody should be able to look up whose money that is.
Realistic sizing for a mainnet node in 2026 — chain size, memory, disk and bandwidth. Based on what actually runs in production, not on minimum specs that stopped being true two years ago.
Every plan ships with unlimited bandwidth, NVMe storage and full root access — the three things a node actually consumes. Deploy with a token, pay in the same coin your node secures.
From order to synced node. Commands are copy-paste ready for Ubuntu 24.04 — adapt paths if you run Debian or Rocky.
DS-1 recommended — Lightning wants dedicated uptime. Netherlands peering helps you reach the big hub nodes with low latency.
Follow the Bitcoin node setup first — pruned is fine for LND. Enable Tor while the chain syncs.
Grab the release binaries, verify signatures, install. Create a dedicated user and a systemd unit so the node survives reboots.
# after bitcoind is synced (pruned is fine for LND)
wget https://github.com/lightningnetwork/lnd/releases/download/v0.19.0-beta/lnd-linux-amd64-v0.19.0-beta.tar.gz
tar xzf lnd-linux-amd64-v0.19.0-beta.tar.gz && install -m 0755 lnd-linux-amd64-v0.19.0-beta/* /usr/local/bin/
Point LND at your bitcoind, enable tor.active with a static onion address, set your alias and fee policy. Back up the seed offline — channel funds depend on it.
# ~/.lnd/lnd.conf
bitcoin.mainnet=1
bitcoin.node=bitcoind
tor.active=1 # hide your node's IP
tor.v3=1
Fund the wallet, open channels to well-connected peers, install RTL or ThunderHub as a dashboard, and push static channel backups (SCB) off-box automatically.
lnd &
lncli create # scripted wallet init
lncli getinfo
The Lightning software itself is light — a few GB of channel database, 2–4 GB of RAM. The real weight is the Bitcoin backend behind it: pruned (~50–100 GB) or full (~760 GB). What Lightning uniquely demands is reliability: NVMe that won't corrupt the channel database under sudden load, ECC memory on the dedicated tiers, and a network that never disappears mid-HTLC. That's why the recommended tier is bare metal even though the CPU rarely breaks a sweat.
Force-closes hurt: if your node is offline while a peer broadcasts an old state, only a watchtower can punish the cheat. Run your node where uptime is backed by a 99.9% SLA, add an external watchtower (or host one for friends on the same box), and keep static channel backups synced off-server. The node's job is to never miss a block — everything else is fee tuning.
Your node's alias, pubkey and IP are public on every Lightning explorer. If that IP is your home, your physical location is one lookup away from your channel balances. Hosting offshore under a token breaks the chain: explorers see a Moldovan or Icelandic datacenter, payments route exactly the same, and the operator behind the pubkey stays unmapped. Add a Tor-only announce address if you want the node fully dark.
Start with a few million sats across 3–5 well-picked channels on the Starter tier. When forwards become steady, move up: more RAM keeps bigger channel graphs in memory, more disk lets the backend go archival, and spare cores host a second implementation or an LNbits stack. Migration is a channel-preserving copy of the LND directory — or run old and new in parallel and rebalance across.
Related reading: Crypto Payments for Hosting: Monero vs Bitcoin vs USDT · The First Hour of VPS Hardening: A Checklist · Crypto nodes