How to run a Bitcoin full node on a VPS

A full node is the only way to use Bitcoin without asking somebody else what the truth is. Every other option — a block explorer, a light wallet talking to a public server, a balance on an exchange — means trusting a third party for your history and handing them your privacy along the way. Bitcoin Core itself takes about ten minutes to install. What actually decides whether your node is useful is the machine underneath it: how much disk you gave it, whether the upload is metered, and what the host can see.

What a full node does — and what it does not

A full node downloads every block, checks every signature and every consensus rule for itself, and maintains its own copy of the current set of spendable coins. It is a verifier. It is not a miner, and on its own it is not a wallet.

• It validates independently — no explorer, no exchange and no light-wallet server gets to tell you what is valid or what your balance is.
• It stops you leaking your addresses to a stranger's server every time a wallet syncs, which is the largest privacy leak most Bitcoin users have.
• It relays blocks and transactions onward, which is the part that helps the network rather than only you.
• It earns nothing, votes on nothing, and does not make your coins safer if your keys are already handled badly.

Archival, pruned or indexed: three very different disk footprints

This single decision drives the plan you need, so make it before you order anything. All three modes verify the chain in exactly the same way — the difference is only how much of it stays on disk once the verifying is done.

• Pruned — Core downloads and checks everything, then discards old block files and keeps only recent ones. With prune=5000 the block data stays around 5 GB; add the UTXO set and the operating system and you land near 25 GB in total.
• Archival — every block kept forever. That is past 750 GB of block data today, growing by roughly 7 GB a month, with the UTXO set on top. You need it to serve historical blocks to other peers, or to reindex later without downloading the chain again.
• Indexed — archival plus txindex=1, which lets you look up any transaction by ID and is what block explorers and some server software expect. It adds tens of gigabytes on top, and it cannot be combined with pruning.

Choosing a VPS for a Bitcoin node: disk, RAM and an unmetered port

Bitcoin Core is patient about CPU and fussy about disk. Random reads and writes against the UTXO database are what make a sync fast or miserable, which is why NVMe matters far more than core count here. Every plan on the offshore VPS range ships Gen4 NVMe in RAID-10 and unmetered bandwidth, so the real choice is capacity.

• Pruned node: VPS-4 at $7.49/mo — 2 vCPU EPYC, 4 GB DDR5 ECC and 60 GB NVMe, with comfortable room for prune=5000 plus logs. The $3.99 VPS-2 works too if you prune harder.
• Pruned node that syncs quickly: VPS-8 at $13.99/mo — 4 vCPU and 8 GB let you hand Core several gigabytes of dbcache, which is the single biggest lever on sync time.
• Archival node: VPS-64 at $89.99/mo is the only VPS tier whose 800 GB of NVMe fits an unpruned chain at all — and at today's size that leaves barely a year of headroom.

For an archival or indexed node, do the arithmetic honestly rather than buying the biggest VPS by reflex: a dedicated server starts at $64/mo with 64 GB of memory and 2 × 1 TB NVMe, so it is both cheaper and far roomier than the largest VPS tier. If you intend to keep the chain for years, or to stack an Electrum server and a site hosted without KYC beside it, start there instead of upgrading twice.

Step by step: from a crypto top-up to a synced node

1. 01Create an account with a burner emailAn email and a password. No name, phone or ID, so nothing on our side ties the node to you.
2. 02Top up your balance in cryptoFund a prepaid balance with Bitcoin, Monero or any of 8 coins. It never expires and is never frozen.
3. 03Deploy the VPSPick a plan, a region and a Debian or Ubuntu image. Root access is ready in about a minute at the median.
4. 04Install Bitcoin Core and verify the downloadTake the release from the Bitcoin Core project, then check the signatures before you unpack it. Skipping that step is how people end up running somebody else's binary.
5. 05Run it as its own user under systemdA dedicated bitcoin user, a data directory it owns, and a unit file so the node comes back by itself after a reboot.
6. 06Write bitcoin.conf, start it and watch the logSet your prune level, dbcache and network options, start the service, and follow the log until the verification progress reaches 1.

The bitcoin.conf lines that actually matter

Core ships with sane defaults, and a good configuration is usually six or seven lines. These are the ones worth understanding rather than copying from a forum post.

• dbcache — memory for the UTXO database, 450 MB by default. Raising it to a few thousand for the initial sync is the cheapest speed-up available, and you can lower it again afterwards.
• prune — a size cap in MB on block storage, minimum 550. Going from pruned to archival later means downloading the chain again, so decide before the first start.
• txindex=1 — builds a full transaction index. Set it only if a tool you actually run needs it; adding it later forces a reindex.
• listen=1 with port 8333 open — makes you a listening node other peers can reach. This is the difference between using the network and contributing to it.
• maxuploadtarget — a soft daily ceiling on outbound traffic, worth setting on any host that meters transfer.
• blocksonly=1 — stops relaying loose transactions. It cuts bandwidth sharply, at the cost of a useful mempool and of helping propagation.

Initial block download: what actually makes it slow

The first sync is the only genuinely heavy part of the job. Core replays the whole chain, and while it skips script checks below a hardcoded recent block by default, it still rebuilds the entire UTXO set from scratch — so the work is dominated by random disk I/O and hashing rather than by your connection. On Gen4 NVMe with a generous dbcache, a full sync normally finishes in well under a day; the same job on a spinning disk can run for a week. Give it more memory rather than more cores, and resist restarting it out of impatience: progress is written out periodically, but a restart mid-flush costs you the cache you were paying for.

Running the node over Tor

A listening node announces itself to peers. On a clearnet address that announcement is public, and it points at your server. Core has first-class Tor support: give it a local Tor SOCKS proxy and access to Tor's control port and it will publish its own onion service and accept inbound connections there. Add onlynet=onion and it will not speak to the clearnet at all.

This is a different job from running a Tor relay, which carries other people's traffic and is deliberately public. Here Tor is simply how your own node reaches its peers, and the trade-off is modest: onion-only nodes sync somewhat more slowly and draw from a smaller peer pool, which for a machine you leave running is rarely a problem.

Bandwidth: the cost nobody budgets for

A listening node uploads far more than it downloads. Every peer doing its own initial sync can pull hundreds of gigabytes from you, and a well-connected archival node will happily serve several terabytes a month if you let it. On a metered host that is an overage invoice — it is exactly the traffic profile that "unlimited" hosting plans are written to exclude. Unmetered transfer is standard across the range here, and if you want to seed the chain aggressively for others, the 10 Gbps Unmetered line from $34.99/mo carries a dedicated port for it. If you would rather stay small, cap it deliberately with maxuploadtarget instead of leaving it to chance.

Connecting wallets, an Electrum server or BTCPay

A node on its own is only half the setup — the point is to make your own software talk to it instead of to a stranger's. Wallets such as Sparrow and Specter connect straight to Core's RPC over a tunnel. Electrum-protocol wallets need a server in between: electrs or Fulcrum build their own index from the raw block files, which is one of the concrete reasons to stay unpruned. And if you want to take payments yourself, BTCPay Server running against your node removes the payment processor entirely — the same self-hosting logic as putting a website up without KYC.

One rule holds regardless of the stack: the node verifies, and your keys live somewhere else. Use a hardware wallet or an offline signer and let the rented machine do nothing but validation. A box you do not physically own is not where meaningful funds should sit.

The honest privacy trade-off of a node you do not own

A node on a VPS is not identical to one under your desk, and it is worth being precise about why. It removes the biggest and most common leak: querying public explorers and third-party Electrum servers that log exactly which addresses you asked about. What it cannot remove is the host. Anyone with physical access to a machine can in principle read its disk and its memory, and full-disk encryption on a remote server protects you against a stolen drive, not a running one.

So the useful question is not "can the host see it" but "does the host know who I am". No-KYC hosting answers that one: an email and a password, no verification, nothing on file to leak or to subpoena. Paying from a crypto balance removes the bank. How far you take the payment side is a threat-model choice — Bitcoin is pseudonymous, not anonymous, so coins traced back to a verified exchange still lead somewhere, while topping up in Monero closes that gap at the protocol level. The same reasoning applies to running a Monero node, where it is the wallet-to-node link you are protecting.

Mistakes that leave a node stuck, idle or exposed

• The disk filling mid-sync because pruning was decided after the fact — set it before the first start, not halfway through.
• Port 8333 left closed at the firewall, so the node only makes outbound connections and never serves a single peer.
• RPC bound to 0.0.0.0 "just for testing", which on a public IP is found within hours.
• txindex enabled by reflex on a small disk, then discovered to need a full reindex to remove.
• The node run as root out of a home directory with no systemd unit, so one reboot quietly ends the experiment.

None of these are exotic failures. They are what happens when the machine is chosen on price alone and the details are left for later. Pick the disk for the mode you actually want, keep the peer port open and the RPC closed, and a Bitcoin node is one of the least demanding things you can leave running for years.