Run your own Bitcoin node on a VPS

Running your own node is the line between taking someone's word about the chain and verifying it yourself. Your node enforces every consensus rule independently, and your wallets can query your node instead of a public server that quietly logs all your addresses. The wall people hit: a full archival node wants 600 GB+ of disk and keeps growing. A pruned node steps around that — it still validates the entire chain, then discards the old blocks it no longer needs, landing around 10–15 GB. That fits a small VPS. Here's the honest how, and what pruning costs you.

What a node actually gives you

• Independent validation. You enforce the rules yourself. Nothing invalid gets past your node because it believed a stranger.
• Privacy for your own queries. Your wallet asks your node, not a public explorer that sees every address you look up.
• A base for the rest. A node is the foundation other things sit on later — Lightning, explorers, your own apps.

Pruned vs full — the honest core

During the initial sync, your node downloads and verifies the entire chain. That's roughly 600 GB of bandwidth, once. Pruning changes only what happens after: it keeps recent blocks and drops the old ones, so final disk stays small.

What you give up is real: a pruned node can't serve historical blocks to other peers, and it can't rescan arbitrary old wallet history. So if you'll import an old wallet with early transactions, you need full history — a full node on a big disk, not a pruned one. For simply validating and running current wallets, pruned is exactly right.

What you need

• Disk: ~15–20 GB for a pruned node — a small box is fine.
• RAM: 2–4 GB. More dbcache speeds the initial sync; you can lower it afterward.
• Bandwidth: real throughput for the one-time full download.
• A reachable IP: to accept inbound peers on port 8333 and actually help the network, you want a public IP with 8333 open — a dedicated-IP plan. On NAT you get one SSH port and can't open 8333.

The setup

Install bitcoind, then a minimal bitcoin.conf:

prune=10000        # keep ~10 GB of recent blocks
dbcache=2048       # faster initial sync; lower it later
listen=1           # accept inbound peers

Run it under systemd so it restarts on crash and comes back after a reboot, and open port 8333 so peers can reach you. Then let it sync — this is the long part, hours to a day or two, because it's verifying the whole chain from genesis.

Lock it down

• Keys-only SSH, firewall to 8333 and your SSH port. (The ten-minute checklist.)
• Never expose the RPC port to the internet. Bind it to localhost and reach it over an SSH tunnel or only from apps on the same box. An open RPC is an open door.

The honest limits

• The first sync is long and bandwidth-heavy. That's inherent — validating the chain from scratch isn't a step you can configure away.
• A pruned node can't serve old blocks or rescan old history. Need those? That's a full node and a big disk.
• Monero is a fair question, and the honest answer is scope. Its chain is larger — a couple hundred GB, and even pruned around 90 GB — so it wants a bigger disk than our small plans carry. That's a full-node story for a different kind of box, and we'd rather say so than pretend it fits.
• You maintain it: updates, disk, the occasional peer hiccup. A node is a small commitment, not a fire-and-forget.

Paying for it

Sign up with an email and pay in USDC or USDT — no card, no ID. A fitting way to pay for running your own corner of Bitcoin.