A bitcoind + LND stack on a Garrison at $11.90/mo, Tor-routed by default, BTCPay-ready. KYC-free hosting for the routing of KYC-free payments — the symmetry matters.
Garrison at $11.90/mo runs pruned bitcoind + LND comfortably; Ravelin at $23.90/mo holds the full ~700 GB mainnet on NVMe with headroom for BTCPay.
Tor-only routing by default — your node is a .onion, no IP leak to the public LN graph, no port-scan footprint. Clearnet+Tor remains available for routing nodes.
KYC-free signup + crypto-only billing + Nordic jurisdiction with no KYC-AML treaty obligation to log routing-fee earnings. Symmetric all the way down.
Bitcoin's headline property — "don't trust, verify" — degrades to "don't trust, ask a wallet provider" the moment you use a custodial or light-client wallet. Running your own bitcoind means every transaction you sign or receive is validated by your own copy of the consensus rules; every UTXO you spend is one your node knows about firsthand. Verification is what the protocol was designed to make possible; self-hosting is what makes it actual.
Lightning compounds the case. A routing node's economics, the channel-balance discipline, the on-chain fee strategy at force-close time — none of these are decisions you want delegated to a third party that holds your keys. The Lightning specification was written assuming the operator controls the box; running on someone else's custody is a different (and worse) product.
A small VPS makes this tractable. A Garrison runs pruned bitcoind + LND with room left over; a Ravelin holds the full mainnet history on NVMe if your use case wants it. BTCPay Server stacks on top for merchant flows. The whole pipeline — from receiving sats to routing HTLCs to issuing invoices — runs on one (or two) boxes you administer.
The right question is not "self-host or custodial" in the abstract — it is "do I treat my keys as mine, or as someone else's product". If the answer is the first one, the rest of this page is the recipe.
For a pruned bitcoind + LND on Tor — the canonical entry-level setup that handles personal payments, a small set of channels and a private payment-routing posture — the Garrison ($11.90/mo, 4 vCPU, 8 GB, 240 GB NVMe) is the right tier. Pruned bitcoind sits around 5 GB, LND adds 1–3 GB, and the remaining 200+ GB is yours for logs, channel-state backups and the occasional re-IBD.
For a full archival bitcoind (~700 GB and growing) plus LND or CLN plus BTCPay Server on the same box, the Ravelin ($23.90/mo, 8 vCPU, 16 GB, 480 GB NVMe) is the right call. The NVMe is the part that matters — Bitcoin Core's UTXO writes are extremely random-IO-heavy during validation, and the NVMe-vs-SATA difference shows up as hours vs days on IBD and seconds vs minutes on block tip catch-up.
For a serious routing node — opening dozens of channels, optimising for fee revenue, running an actively-managed liquidity strategy — the headroom of a Bulwark tier or a two-box split (bitcoind on one tier, LND + BTCPay on another, linked via WireGuard) is the natural next step. We are happy to walk through that layout; ticket us when you get there.
What none of these are: a custodial Lightning service for end users. NordBastion hosts the box — the keys, the channel state, the routing policy and the fund custody are entirely the operator's domain.
A skeleton sketch — Bitcoin Core's docs and the LND tutorial remain the canonical references for fine-tuning. The flow below is the path of least friction.
From the bitcoin.org PPA for Ubuntu or the upstream tarball with verified GPG signature. Do not trust random distribution packages for this one.
add-apt-repository \
ppa:bitcoin/bitcoin
apt update && apt install \
bitcoindPruned mode, ZMQ enabled (LND needs the block-and-tx feeds), RPC restricted to localhost. Keep it minimal at first.
prune=550
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
rpcbind=127.0.0.1~24 hours pruned on a Garrison, ~48 hours full archival on a Ravelin. Tail debug.log and bitcoin-cli getblockchaininfo for progress.
systemctl enable \
--now bitcoind
bitcoin-cli \
getblockchaininfoFrom the lightninglabs release binaries, verified signature. tor.active=true and listen exclusively on the .onion service.
# /etc/lnd/lnd.conf
[tor]
tor.active=true
tor.v3=true
tor.streamisolation=truelncli create writes the seed once — write the 24 words on paper, no exceptions. Then enable channel.backup ship-off-box immediately.
lncli create
# record the 24-word seed offline# rclone-ship channel.backup off-box on changePick a well-connected hub (LN+ marketplace, Amboss, BoltzExchange) and open with a fee-rate appropriate to current mempool conditions. Watch it confirm.
lncli openchannel \
<NODE_PUBKEY> 1000000 \
--sat_per_vbyte 8Routing KYC-free payments from a hoster that did full KYC on you re-introduces the chokepoint Bitcoin was designed to remove — just one layer down. KYC-free signup, crypto-only billing and no card on file mean the chain of custody for "who runs this routing node" cannot be subpoenaed via the hoster's billing department. The protocol is permissionless; the hoster is at least permissionless-friendly.
Sweden, Finland, Norway and Iceland do not impose KYC-AML reporting on infrastructure operators who happen to host Bitcoin nodes — running a node is not a regulated financial activity in any of the four. There is no equivalent of a US MSB filing for "I forward HTLCs", no obligation on us as the hoster to know which wallet earned which routing fee. The records simply do not exist on our side.
NVMe on every tier — not as an upsell — turns Bitcoin Core's UTXO-write-heavy validation path into a non-event, and keeps LND's channel-graph gossip ingestion fast. The 1 Gbps unmetered uplink absorbs the IBD download and the steady-state gossip without invoicing extra. Two specs that hosters often sell separately; here they are baseline.
Self-hosting a Bitcoin + Lightning node is the operational expression of the "don't trust, verify" property the protocol was designed for. For roughly the price of a single custodial-wallet "premium" tier you get verifying-node + routing-channel infrastructure whose keys live on your box, whose routing fees never touch a third party, and whose hoster does not know whose wallet they belong to.
NordBastion is opinionated about the parts that matter for this specific job — KYC-free signup so the chain of custody stops at your prepaid balance, Nordic jurisdiction with no MSB-style reporting obligation, NVMe across every tier so the IBD does not take a week — and deliberately ordinary about the rest. bitcoind is bitcoind. LND is LND. Tor is the upstream daemon. The box is the box.
The pruned-then-grow path is the right starting posture: get the node running, get the first channel open, get the channel.backup ship-off-box rclone job working. The serious-routing-node decisions can come later, on a Bulwark or a two-box split. The first node is a Garrison and an evening.
The eight questions node-operators actually ask before lncli openchannel. Channel-backup discipline is question four for a reason.
For a payment-routing node and a BTCPay frontend, pruned=550 (~5 GB on disk) is perfectly sufficient — LND, CLN and BTCPay only need the UTXO set and recent block history to validate and route. Pruned drops the storage requirement from ~700 GB down to single-digit GB and the IBD-then-keep-up workload from "weeks" to "days". Run full archival only if you have a research or block-explorer use case that needs historical block-data access by height; otherwise pruned wins on every operational axis.
LND is the most-deployed (~70% of the public Lightning graph), has the largest tooling ecosystem (Thunderhub, ride-the-lightning, Balance of Satoshis) and the most BTCPay integration polish. Core Lightning (CLN) is the more conservative codebase, has the cleanest plugin architecture, and is what many node-operators-of-operators run for routing-business reasons. Eclair is the Scala implementation, mostly seen behind ACINQ's wallet. For a first node, LND on a Garrison is the lowest-friction path; CLN is the right choice if you want to push routing performance and care about plugin extensibility.
Tor-only (tor.active=true, no clearnet listener) is the privacy-maximalist default — your node is reachable only as a .onion, no IP leak, no port-scan footprint. Clearnet + Tor (dual listener) gives better channel-discovery and lower routing latency at the cost of exposing your node IP to the public graph. Most operators start Tor-only because the operational cost of opening a clearnet port is nontrivial (firewall, port 9735, careful identification of LN-related logs) and graduate to dual once they actually care about routing-fee optimisation.
Use Static Channel Backups (SCB) — LND writes channel.backup whenever a channel opens or closes, and that file is sufficient to recover on-chain funds (force-close from the counterparty's side) but not to resume the channels. Ship channel.backup off-box on every change (rclone to encrypted Backblaze, or a tiny script that uploads to a separate VPS). The one rule that costs people sats: never restore an old channel.db. Restoring a stale state triggers the counterparty's justice transaction and you lose the channel funds. SCB is the safe path.
A Lightning routing node's wallet is necessarily hot by definition — the keys have to sign HTLC commitments in real time. The discipline is sizing: keep only what you need for the channel balances you operate, treat the routing-node wallet as the float (not the savings), and move excess on-chain balance out to cold storage on a regular cadence. For a small-scale operator, $500–$2,000 in the hot wallet is typical; for a serious routing node, the hot balance reflects the channel capacity you have committed.
A pruned node on a Garrison's 4 vCPU / 8 GB / 240 GB NVMe completes IBD in ~24 hours over a 1 Gbps uplink — most of that time is signature validation, which is CPU-bound. A full archival node on a Ravelin (8 vCPU / 16 GB / 480 GB NVMe) completes in ~48 hours. The NVMe matters: spinning disks turn IBD into a multi-day affair because Bitcoin Core's UTXO writes are extremely random-IO-heavy. NordBastion is NVMe across every tier.
BTCPay Server's docker-compose stack expects bitcoind + an LN implementation + nbxplorer + the BTCPay web tier. On a Ravelin you can host the whole stack on one box for a small merchant (a few thousand transactions a year); on a Garrison the squeeze is real once nbxplorer indexes start churning, so we recommend splitting BTCPay onto a second tier — Garrison for the node, Sentinel for BTCPay reverse-proxying back over WireGuard to the node. Both flows are KYC-free end-to-end.
Bitcoin's value proposition is permissionless settlement. The moment your routing infrastructure runs on a hoster that knows-its-customer, did-its-AML, holds-card-on-file, you have re-introduced a chokepoint — not at the protocol layer, at the infrastructure layer. KYC-free hosting for KYC-free payment infrastructure is not absolutism; it is removing the place where the chain of custody for "who runs this routing node" can be subpoenaed. The protocol is permissionless; the hoster should be at least permissionless-friendly.
Donate Nordic bandwidth to the Tor network — the natural neighbour of a Tor-routed Lightning node on the same operator's account.
Kernel-fast VPN exit on a Sentinel — for ssh-ing into your node and your BTCPay frontend over your own tunnel.
End-to-end encrypted Synapse — for the operator who runs their own sovereignty stack messaging-and-money side by side.