Run a Bitcoin full node on a VPS

Three things, and only two of them are about privacy.

• Verification. Your node enforces consensus itself — every signature, script, subsidy and difficulty adjustment, checked against its own copy of the chain. Nobody can convince it that a coin exists when it does not. This is the part that cannot be delegated: a light wallet trusts a server’s answer.
• Privacy at the network layer. A light wallet has to tell someone which addresses it cares about. Even the polite protocols hand a server enough to cluster your addresses into one wallet and pin it to an IP. Your own node answers those queries locally.

What a node does not buy is on-chain anonymity. The ledger stays public and permanent; a node fixes the network layer only. If unlinkability on the chain itself is the requirement, that is a different chain — run a Monero node instead — and is a crypto-paid VPS really anonymous? sets out the rest of the accounting.

Both kinds of node validate identically. A pruned node downloads every block, checks every rule and builds the same UTXO set, then deletes old block files it no longer needs. What it gives up is the ability to serve history: it cannot feed old blocks to a syncing peer, cannot rescan a wallet whose coins predate its prune horizon, and cannot back an index that reads arbitrary historical transactions.

The size gap is not subtle. In 2026 the unpruned chain is well past 700 GB and still adding tens of gigabytes a year — check the current figure before committing to disk, because it only goes up. A pruned node at prune=5000 keeps about 5 GB of block files plus the UTXO set and Core’s own databases: call the datadir 20 GB.

So prune unless you have a specific reason not to. The reasons are narrow: serving historical blocks back to the network, txindex for a block explorer, or running your own Electrum server.

• CPU. One core keeps up with the tip indefinitely. Initial block download is where cores earn their keep, because signature verification parallelises — 2 to 4 vCPU shortens the first sync and then goes back to idle. Full KVM virtualisation matters more than core count: real hardware isolation and your own kernel, not a container sharing someone else’s.
• RAM. 2 GB is the working floor for a pruned node. dbcache is the dial that matters — a gigabyte or two of UTXO cache during IBD removes hours of random reads, and you can drop it back afterwards.
• Disk. Sized as above, and NVMe rather than anything else. IBD is dominated by random access to the chainstate, not by the download.
• Bandwidth. IBD moves the entire chain regardless of pruning: several hundred gigabytes, once. A listening node then uploads steadily to peers, cappable with maxuploadtarget. Every plan here runs a 1 Gbps port with unlimited traffic and no overage invoices.

Concrete numbers from our grid, because “it depends” is not an answer:

• Pruned, personal use — Cub, 1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo. A 20 GB datadir with headroom, and the honest recommendation for most readers.
• Pruned, comfortable — Scout, 2 vCPU / 4 GB / 70 GB, $9.00/mo. Roughly halves the sync wait. If this box will do more than one job, start here.
• Node plus Lightning plus monitoring — Runner, 3 vCPU / 6 GB / 100 GB, $14.00/mo.
• Full archive — where honesty beats upselling. Garmr (500 GB, $69.00/mo) no longer fits an unpruned 2026 chain, so do not buy it for this. Fenrir (16 vCPU / 64 GB / 800 GB NVMe, $99.00/mo) does, with a runway measured in a few years rather than forever.

Location is irrelevant to a node, which has no latency requirement, so choose on price or jurisdiction: Amsterdam, Paris, Bucharest and Sofia sit at base price, while Stockholm, Kuala Lumpur, Reykjavik and Zurich carry a multiplier. Annual billing charges ten months instead of twelve.

IBD is not a download problem. Several hundred gigabytes arrive over a 1 Gbps port in a matter of hours; the days come from what happens next — verifying every signature since 2009 and maintaining a UTXO set that is constantly re-read at random. That workload is bound by storage latency first and CPU second.

The practical effect is an order of magnitude. On NVMe RAID10 with a couple of gigabytes of dbcache, a pruned IBD typically finishes in about a day. The same job on a budget host’s shared SATA SSD routinely runs a week and sometimes never finishes, because the operator gives up first. This is where NVMe versus SSD stops being a spec-sheet line. Every plan here is all-NVMe, which is why the cheapest tier is a realistic place to run a node rather than a technicality.

One lever if you are impatient: raise dbcache as high as RAM allows for the duration of the sync, then put it back.

Core has first-class Tor support, and for a personal node Tor-only is the default worth choosing. It hides which node a transaction originated from, keeps your VPS address out of Bitcoin’s permanently gossiped peer lists, and lets your own wallets reach the node from anywhere without opening an inbound port.

Install tor, add the daemon’s user to the debian-tor group so Core can reach the control port, and add to bitcoin.conf:

proxy=127.0.0.1:9050
onlynet=onion
listenonion=1
discover=0
dnsseed=0

Core creates and advertises its own v3 onion service automatically; confirm with bitcoin-cli getnetworkinfo that the onion address is listed and the onion network shows as reachable.

The honest trade-off: onion peers are fewer and slower, so syncing over Tor takes noticeably longer. If Tor is running on the box anyway, our Tor relay guide and the Tor-friendly VPS notes cover the policy side — relays and onion services are welcome here, not merely tolerated.

An Electrum server sits between your node and Electrum-protocol wallets, keeping an address-indexed view of the chain so a wallet can ask “what is at this scripthash?” and get an instant answer. Running your own means Electrum, Sparrow and BlueWallet connect to you rather than to a public server that sees every address you own.

The catch the one-line tutorials skip: electrs and Fulcrum both require an unpruned node. They build their index by reading block files directly, so the history has to still be on disk. Adding an Electrum server therefore drags you from a $5 pruned box to a full archive node plus another 50–100 GB for the index — Fenrir territory, not Cub.

Between the two, electrs is lighter on memory and slower to build its index; Fulcrum indexes and answers faster but wants more RAM. Both listen on 50001 plaintext and 50002 TLS. Keep them bound to localhost and reach them over a WireGuard tunnel or an onion service rather than exposing them.

A Lightning node needs a Bitcoin backend it can trust, and yours is the obvious candidate. Both major implementations run alongside Core on the same VPS:

• LND talks to bitcoind over RPC and ZMQ. Add zmqpubrawblock and zmqpubrawtx endpoints to bitcoin.conf, bound to localhost only.
• Core Lightning shells out to bitcoin-cli by default, which is simpler to reason about and opens no extra ports.

Pruning complicates this too. LND can work against a pruned bitcoind but must fetch missing historical blocks from peers, which is slower and occasionally fragile; Core Lightning is happier with the history present. If Lightning is the goal from the outset, either accept an unpruned node or take on that friction knowingly.

Lightning itself is light — the channel database is hundreds of megabytes — but it must stay online to watch for channel breaches, which is the argument for a VPS over a laptop that sleeps. Port 9735 is the Lightning P2P port, and a Tor-only Lightning node is entirely normal.

A node is not a secret, but it is a machine that runs continuously, advertises an address to a global gossip network, and — if you are careless — is rented in your name with a card in your name.

• Sign up without identity. There is no KYC here by design: no ID, no document upload, no verification step to fail.
• Pay on-chain. Top up in BTC and deploy from the balance, or in Monero if you would rather the payment itself not be a permanent public record — worth sitting with when the thing you are funding is a Bitcoin node. Either way there is no card and no third-party processor; the mechanics are in buying a VPS without a credit card.
• Put no identity on the box. Don’t name the hostname after yourself, don’t reuse an SSH key that appears on a public code-hosting profile, and remember that a listening node’s address is published by design — the strongest practical argument for the Tor-only mode above.

What the host can see is a machine moving steady peer-to-peer traffic on a well-known port. Nothing about your wallet, your addresses or your balances — those never leave the box, which is the entire point. A validating node is ordinary infrastructure and is explicitly welcome; the one neighbouring line in the acceptable use policy is that cryptocurrency mining is not permitted on shared plans, because it monopolises shared cores. A node is not a miner: after IBD it sits close to idle.

Day two is undramatic. Core ships a major release roughly every six months, and upgrading means stop the service, replace the binaries, start it again — the datadir is forward-compatible and there is no re-sync. Back up your descriptors if the node holds a wallet at all; nothing else matters, because the chain re-downloads by definition. If you outgrow the disk — and an archive node will — moving up a tier grows the disk online with no reinstall, charged pro-rata from your balance.