Self-host a Bitcoin Lightning node.
Six steps. Your own LN router on owned Nordic metal.
Bitcoin Core + LND (or Core Lightning) on a KYC-free Nordic VPS. Optionally with BTCPay Server as a self-hosted payment-receive layer.
- 01
Tier
Ravelin / Bulwark
- 02
Bitcoin Core
Pruned or full
- 03
Sync IBD
1-12h
- 04
Lightning
LND / CLN
- 05
Fund + open
First channels
- 06
Optional
BTCPay Server
Pick by chain mode. Pruned vs full is the deciding question.
Pruned mode — Ravelin ($23.90/mo, 480 GB NVMe) recommended. Bitcoin Core verifies every block during IBD then discards old block data, keeping only the UTXO set and the last 10 GB of chain history. The LN daemon can do everything it needs against a pruned chain. Total disk usage stays around 15-25 GB for Bitcoin + LND combined, well under Ravelin's 480 GB. RAM headroom for BTCPay-style add-ons later.
Full archival — Bulwark ($46.90/mo, 960 GB NVMe). If you also want to verify historical transactions, run your own block explorer locally, contribute the chain to other nodes, or just hold the complete record. Bitcoin Core archival is currently ~700 GB and grows by roughly 50 GB/year; Bulwark holds five-plus years of headroom.
Bastion choice. Any of the four. Latency from your LN node to most peers is similar across the Nordic backbone. Pick the jurisdiction that matches your other workloads, or one of the lower-latency-to-EU options (Stockholm, Helsinki) if you expect to route payments for European customers.
Install, verify, sync. Patience for IBD.
Download Bitcoin Core 26.x from bitcoincore.org. Verify the release signatures — get the SHA256SUMS file plus SHA256SUMS.asc, verify with GPG against the keys in the bitcoin/guix.sigs repo. Skipping this step is the single most common mistake.
Minimal /home/bitcoin/.bitcoin/bitcoin.conf for pruned mode + Tor-only outbound:
server=1
prune=10000
txindex=0
rpcuser=<random-username>
rpcpassword=<long-random-password>
onlynet=onion
proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
Run as systemd unit owned by a non-root bitcoin user. Start the daemon, then monitor IBD progress:
bitcoin-cli getblockchaininfo | grep verificationprogress
# climbs from ~0.0 to ~1.0 over a few hours
Pruned mode on Ravelin via Tor: roughly 2-4 hours for first sync. Without Tor it is faster (under 2 hours), but defeats the network-anonymity layer. Wait the extra time.
LND or Core Lightning, on top of bitcoind.
Install LND from the official lightningnetwork/lnd releases (verify the GPG signature). Minimal /home/lnd/.lnd/lnd.conf:
[Application Options]
alias=my-nordic-node
color=#5EE2FF
listen=localhost
restlisten=localhost:8080
[Bitcoin]
bitcoin.active=true
bitcoin.mainnet=true
bitcoin.node=bitcoind
[Bitcoind]
bitcoind.rpcuser=<same as bitcoin.conf>
bitcoind.rpcpass=<same as bitcoin.conf>
bitcoind.rpchost=127.0.0.1
bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333
[tor]
tor.active=true
tor.v3=true
Start lnd, create wallet (lncli create — writes a 24-word seed; back it up on paper, the wallet cannot be recovered without it), unlock (lncli unlock). The node advertises itself over Tor v3 — your node ID is a 66-character hex string published to the Lightning network with the .onion address as its endpoint.
Fund the wallet, open the first three channels.
Get an on-chain receive address:
lncli newaddress p2tr
# returns a bc1p... taproot address
Send 0.01 BTC. Wait for one confirmation (~10 min). Then pick three well-connected peer nodes — visit 1ml.com or amboss.space, sort by routing-volume, look for nodes with low fee rates and high uptime. Note their pubkey + .onion address.
Open three channels of about $80-100 each:
lncli openchannel --node_key=<peer-pubkey> --local_amt=200000 --sat_per_vbyte=5
# 200,000 sats ≈ $90 at $45k/BTC
Channels confirm in 3-6 blocks (30-60 minutes). Once active, the node is on the network — it can route, send, receive (with inbound liquidity caveat from the FAQ).
A self-hosted Stripe-equivalent, in one Docker stack.
BTCPay Server wraps your LND node with an invoice UI — generate payment links and QR codes, manage stores, plug into WooCommerce / Shopify / custom apps. The official deployment script handles everything (Docker, nginx, Let's Encrypt, Tor hidden service):
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-docker
BTCPAY_HOST=<your-domain.com> \
NBITCOIN_NETWORK=mainnet \
BTCPAYGEN_LIGHTNING=lnd \
BTCPAYGEN_REVERSEPROXY=nginx \
BTCPAYGEN_ADDITIONAL_FRAGMENTS=opt-add-tor \
./btcpay-setup.sh -i
Result: a self-hosted payment gateway accessible at your domain, with an .onion mirror, accepting Bitcoin on-chain and Lightning through your own node. No third-party processor. No KYC. Privacy-host with privacy-payment, end to end.
Questions, answered.
Eight questions a first-time Lightning node operator asks before opening the first channel.
Pruned or full node?
Pruned (10-50 GB) for personal Lightning operation — you do not need the full history to participate in Lightning, you just need a functioning Bitcoin node. Full (~700 GB and growing) if you also want to verify historical transactions, run a block explorer locally, or contribute to network resilience by serving the chain to other nodes. Most personal LN operators choose pruned; node-operator hobbyists choose full.
LND or Core Lightning?
LND if you want the broadest ecosystem — BTCPay Server, RTL, ThunderHub, mobile remote-control wallets, the bulk of Lightning developer tooling. Core Lightning (CLN) if you value the smaller codebase, the plug-in architecture, the C implementation, or you participate in the Bitcoin maximalist culture that prefers it. Both implementations interoperate on the Lightning protocol; you can change later by restoring the wallet seed into the other.
How much BTC do I need to start?
A practical minimum is ~0.005 BTC. That covers one or two outgoing channels of $100-200 each plus on-chain reserve for channel management. Below that, channel-open and close fees eat too high a percentage of the principal. The sweet spot for someone learning is 0.01-0.05 BTC across three to five channels with well-connected nodes.
Can I run a Lightning node on the cheapest VPS?
Technically yes if you use pruned mode and tight memory settings, but you will fight the resource limits constantly. Sentinel ($5.90, 4 GB RAM) is enough for a pruned node + LND in idle state but tight under any real traffic. Ravelin ($23.90, 16 GB) is comfortable. Bulwark ($46.90, 32 GB, 960 GB disk) is the right home for an unpruned full node plus LND plus BTCPay.
How do I keep the node from being deanonymised by network analysis?
Three practices. (1) Configure bitcoind with onlynet=onion and proxy=127.0.0.1:9050 — all outbound P2P traffic goes through Tor. (2) Run LND with tor.active=true and tor.v3=true so channel-open/close traffic also goes over Tor. (3) Do not advertise your node's clearnet IP in the channel-open metadata. Done properly your node is fully Tor-routed and only the on-chain channel-open transaction is publicly visible.
How often do channels need attention?
Less than you might think. A well-funded channel with a good peer can sit for months without intervention. The main maintenance: occasionally rebalance liquidity (in/out routing), close and re-open if a peer is consistently offline, and bump fees on channel-close transactions during high-fee mempool periods. Tools like Balance-of-Satoshis (LND) or summary.py (CLN) automate most of this.
Can I receive payments without inbound liquidity?
No — Lightning requires that at least one channel has enough capacity on the receiver-side. Either open channels TO well-connected nodes (slightly counter-intuitive — you open outbound, they have liquidity inbound to you), or pay a liquidity service (Bitrefill Thor, LNBig, Lightning Pool) to open a channel from them to you. For receiving meaningful volume, ~0.05 BTC inbound is a reasonable starting target.
What jurisdiction matters for a self-hosted LN node?
Two considerations. (1) Where the server physically sits — Sweden, Finland, Norway, Iceland for the Nordic constitutional regime; the deep-dive is at /guides/nordic-jurisdictions-for-privacy-hosting/. (2) Whether running an LN node is regulated where you reside as the operator — most EEA / EU countries treat self-hosted nodes as personal infrastructure, not as a regulated financial service, but a few have grey areas. The host's jurisdiction protects the server; the operator's jurisdiction governs your personal posture.
Order a Ravelin and start your LN node.
Last reviewed · 2026-05-20 · Tested · Bitcoin Core 26.x · LND 0.17+
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
What “no KYC” actually means — and what it does not.
Why Sweden, Finland, Norway and Iceland — the legal floor of each.
XMR end-to-end — wallet, transfer, confirmations, change.
Lightning invoice → paid VPS in under 30 seconds.