Can I run a Bitcoin node on a VPS?

How much disk, memory and bandwidth does Bitcoin Core need?

About 911 GB of disk for a full copy of the chain, far less when pruned, and a one-time download of the whole chain either way. Two official sources give the figures. Bitcoin Core's own code carries the size each release assumes for mainnet, the number its setup screen uses to warn about disk space. The bitcoin.org requirements page gives bandwidth and memory, but it was written for version 31.0, so its disk figure trails the chain. Plan disk from the release's number.

Should I run a full node or a pruned node?

Pruned, on any VPS sold here. A full copy needs about 911 GB, and the largest plan, Tera, is 8 vCPU / 24 GB / 400 GB. A pruned node downloads and verifies every block like a full node, then deletes old block files to stay under its target. What you give up:

• It cannot serve old blocks to peers that are syncing.
• It cannot rescan a wallet's history past the blocks it kept.
• It cannot run -txindex: Bitcoin Core states that pruning is incompatible with it, which rules out tools that need a full transaction index.
• Going back to an unpruned node means downloading the whole chain again.

How do I install Bitcoin Core 32.1 on Linux?

Download the release from bitcoincore.org, check it against SHA256SUMS, check that file's signatures, then install the binaries. The checksum line must end in OK for the tarball you downloaded, and gpg --verify must print several Good signature lines from builder keys you imported from the bitcoin-core/guix.sigs repository and chose to trust. Run the node as an ordinary user, not root. For systemd, the source tree ships a sample unit, contrib/init/bitcoind.service; adjust its paths to /usr/local/bin.

cd /tmp
wget https://bitcoincore.org/bin/bitcoin-core-32.1/bitcoin-32.1-x86_64-linux-gnu.tar.gz
wget https://bitcoincore.org/bin/bitcoin-core-32.1/SHA256SUMS
wget https://bitcoincore.org/bin/bitcoin-core-32.1/SHA256SUMS.asc
sha256sum --ignore-missing --check SHA256SUMS
# import a few builder keys from github.com/bitcoin-core/guix.sigs first
gpg --verify SHA256SUMS.asc SHA256SUMS
tar xzf bitcoin-32.1-x86_64-linux-gnu.tar.gz
sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-32.1/bin/*

What goes in bitcoin.conf on a small VPS?

A prune target, an upload cap, and the defaults for the rest. prune is in MiB. maxuploadtarget is a daily target, not a hard limit: when it is close, the node stops serving blocks older than a week. Below 4,096 MiB of RAM the default dbcache drops to 450 MiB; Bitcoin Core notes that a lower value makes the first sync much longer, so raise it during that sync if the plan has memory to spare.

getblockchaininfo then shows "pruned": true and a verificationprogress that climbs toward 1. Peers reach the node on TCP 8333; open it to serve recent blocks, or set listen=0 to accept no inbound peers. blocksonly=1 cuts traffic further, but it turns off fee estimation, and Bitcoin Core warns that broadcasting your own transactions from such a node stands out.

# keep about 10 GB of recent blocks; every block is still verified
prune=10000
# aim to upload at most about 5 GB a day
maxuploadtarget=5000
# needed by bitcoin-cli and by LND
server=1
# during the first sync, if RAM allows:
# dbcache=2000

bitcoind -daemon
bitcoin-cli getblockchaininfo

How much traffic will the node use?

About 740 GB in, once, then roughly 15 GB in and up to 150 GB out a month with default settings, going by bitcoin.org's figures. A pruned node uploads less, because it can only serve the blocks it kept, and maxuploadtarget caps the rest. Each VPS comes with a dedicated IPv4 address and a routed IPv6 /64. Every plan lists its outbound traffic per month in TB, and going over it never triggers an automatic charge. Kilo includes 2 TB and Mega 6 TB of outbound traffic a month, well above what the node sends. Plans connect through a 1 Gbit/s port that the VPS on the same host share.

Which plan fits a Bitcoin node?

Kilo for a node alone, Mega or Giga when Lightning or other services share the VPS. The prune values below leave room for the chain state, which grows, and for the system. The vCPU of every plan are shared: they are scheduled on physical cores that neighbouring VPS also use. The RAM and NVMe space of your plan are reserved for your VPS only. The first sync checks every block since 2009 and keeps the vCPU busy for a long stretch; it runs slower on shared vCPU than on dedicated cores, and no timing is published here.

What changes if I add Lightning?

You add a hot wallet and channel state that must survive the loss of the server. LND's documentation says it can run on a pruned Bitcoin Core, and that aggressive pruning costs performance because LND then fetches some blocks from peers. It needs RPC and ZMQ on the node: add zmqpubrawblock=tcp://127.0.0.1:28332 and zmqpubrawtx=tcp://127.0.0.1:28333 to bitcoin.conf.

Recovery rests on the 24-word seed and the static channel backup, channel.backup, which lets you ask former peers to force-close your channels. Lightning Labs says to back up channel.db but not to rely on it for recovery. No plan includes backups, so keep your own copy of anything that matters. For Lightning that means the seed, kept offline, and a copy of channel.backup taken off the VPS whenever channels change. Before putting real funds on any server, read what your VPS host can see.