How to run a Bitcoin full node on a VPS in 2026

A Bitcoin node you run yourself checks every rule of the network on its own, so your wallet never has to trust somebody else’s server with its balance or its addresses. A VPS is a sensible home for one: it is online around the clock, it has a fixed address other nodes can reach, and it does not eat your home connection’s upload. This guide sizes the server first, because that is where most people go wrong, then installs Bitcoin Core from verified binaries with a configuration and a service that survive reboots and upgrades.

Pruned or full: decide before you order

Bitcoin Core always downloads and verifies the entire history. What changes is what it keeps. A full node stores every block, about 890 GB today, so it can serve blocks to other nodes, rescan any wallet and feed an Electrum server or a block explorer. A pruned node verifies in exactly the same way but deletes old blocks once they are checked, keeping the chainstate and the most recent blocks: about 12 GB on disk with the minimum setting.

Figures as of October 2026: 774 GB of blocks, about 108 GB of undo data and a 12 GB chainstate. The total grows by roughly 94 GB a year, and a transaction index adds about 66 GB. A 1 TB volume holds a full node today but will be tight within about a year; if you want indexes, an Electrum server or years of headroom, start on 5 TB. Many guides still say 600 GB; that figure is out of date.

Memory, CPU, disk and traffic

• Memory matters most during the first sync, because Bitcoin Core keeps unspent outputs in a cache sized by dbcache; the bigger the cache, the fewer writes to disk. Since version 31 the default is 1024 MiB on machines with at least 4 GiB of RAM and 450 MiB below that. On a 4 GB plan, about 1500 MiB is a safe setting for the first sync; with 16 GB, 8000 or more.
• CPU: Bitcoin Core skips signature checks for blocks buried under its built-in assumevalid point, so two vCPU are enough; more cores mainly speed up the most recent part of the sync.
• Disk speed: the chainstate is read and written constantly, the block files mostly appended. Hard disks cope well with the block files and badly with the chainstate’s small random reads and writes. Storage plans put an NVMe write-back cache in front of RAID-10 hard disks, and the chainstate is small enough to live in it.
• Traffic: the first sync downloads the whole chain once, about 0.8 TB. After that, a node that accepts incoming connections uploads blocks to peers that are catching up: bitcoin.org notes that full nodes on fast connections commonly upload 200 GB a month or more. maxuploadtarget caps it. ST-1 includes 8 TB a month; past the allowance the port slows to 100 Mbps and nothing is billed.

Install Bitcoin Core from verified binaries

Download the release, its checksum list and the signatures on that list, then check both: the checksum proves the archive is the one listed, the signatures prove the list comes from the people who build Bitcoin Core.

VER=31.1
cd /tmp
wget https://bitcoincore.org/bin/bitcoin-core-$VER/bitcoin-$VER-x86_64-linux-gnu.tar.gz \
     https://bitcoincore.org/bin/bitcoin-core-$VER/SHA256SUMS \
     https://bitcoincore.org/bin/bitcoin-core-$VER/SHA256SUMS.asc
sha256sum --ignore-missing --check SHA256SUMS
git clone --depth 1 https://github.com/bitcoin-core/guix.sigs
gpg --import guix.sigs/builder-keys/*
gpg --verify SHA256SUMS.asc SHA256SUMS

The first check must print OK next to the archive name. The second prints one result per builder: you want several Good signature lines; the warning that the keys are not certified with a trusted signature is expected unless you have signed them yourself. Then install the two binaries you need and create a system user:

tar xzf bitcoin-$VER-x86_64-linux-gnu.tar.gz
install -m 0755 -o root -g root -t /usr/local/bin bitcoin-$VER/bin/bitcoind bitcoin-$VER/bin/bitcoin-cli
adduser --system --group --home /var/lib/bitcoind bitcoin

Configure the node

mkdir -p /etc/bitcoin
cat > /etc/bitcoin/bitcoin.conf <<'EOF'
server=1
# RPC on the server only; reach it through SSH or WireGuard.
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
# UTXO cache in MiB: large for the first sync, smaller afterwards.
dbcache=1500
maxconnections=40
# Upload served to peers, in MiB per 24 hours (0 = no limit).
maxuploadtarget=5000
# Pruned node: uncomment to keep only about 550 MB of recent blocks.
#prune=550
# Transaction index, needed by Fulcrum and some explorers (full node only).
#txindex=1
EOF
chown -R root:bitcoin /etc/bitcoin
chmod 0640 /etc/bitcoin/bitcoin.conf

RPC authenticates with a cookie file that bitcoind writes into its data directory at every start, so there is no password to choose, store or leak. Tools that need RPC, such as an Electrum server or a Lightning node, run on the same server and read that cookie.

Run it as a service

cat > /etc/systemd/system/bitcoind.service <<'EOF'
[Unit]
Description=Bitcoin Core
After=network-online.target
Wants=network-online.target

[Service]
User=bitcoin
Group=bitcoin
ExecStart=/usr/local/bin/bitcoind -conf=/etc/bitcoin/bitcoin.conf -datadir=/var/lib/bitcoind
Restart=on-failure
TimeoutStopSec=600
PrivateTmp=true
ProtectSystem=full
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now bitcoind

TimeoutStopSec gives bitcoind time to write its cache to disk when it stops. A node killed in the middle of that flush has to rebuild its chainstate at the next start, which can take hours.

Firewall and RPC

ufw allow 22/tcp
ufw allow 8333/tcp comment bitcoin-p2p
ufw enable

Port 8333 lets other nodes connect to yours, which is how a node helps the network; with it closed, the node still works on outbound connections only. Never open 8332: RPC controls the node and any wallet loaded in it. To use RPC from your laptop, tunnel it over SSH with ssh -L 8332:127.0.0.1:8332 followed by your user and the server address, or put both machines on a WireGuard network.

The initial sync

Follow the progress with:

sudo -u bitcoin bitcoin-cli -datadir=/var/lib/bitcoind getblockchaininfo \
  | grep -E '"blocks"|"headers"|verificationprogress|size_on_disk'

Expect anything from many hours to several days: about 0.8 TB has to be downloaded and checked, and memory, disk speed and peers set the pace. Published benchmarks on large NVMe machines with a big cache finish in 7 to 12 hours; a 4 GB plan with hard disks takes longer. When blocks equals headers and verificationprogress is above 0.9999, lower dbcache to 450 on a 4 GB plan and restart the service: from then on the memory is more useful to the operating system’s page cache. Since version 28, Bitcoin Core can also start from a UTXO snapshot with loadtxoutset and check the history in the background, but you have to obtain the snapshot file yourself; most people simply let the normal sync run.

Electrum server, Lightning and Tor

• Electrum server. electrs adds about 7% of the block data, around 56 GB today, and needs no transaction index; Fulcrum serves wallets with long histories faster but needs txindex=1 and well over 100 GB of its own. Neither works on a pruned node. Either one lets Sparrow or Electrum query your server instead of a public one; keep their ports behind SSH, WireGuard or Tor.
• Lightning. LND and Core Lightning both run beside bitcoind on the same server and listen on port 9735. LND supports a pruned backend at some cost in speed and bandwidth; Core Lightning supports it only partially and can get stuck if it falls behind blocks that were already pruned, so a full node is the comfortable base.
• Tor. With tor installed, its control port enabled (ControlPort 9051 and CookieAuthentication 1 in torrc) and the bitcoin user added to the debian-tor group, Bitcoin Core creates its own onion service through that port; add proxy=127.0.0.1:9050 to send outgoing connections through Tor as well. Tor relays are welcome on our network; exit nodes are not.

Keeping it healthy

• Upgrades: repeat the download and both checks with the new version, replace the two binaries and restart the service. The data directory carries over.
• Disk: check df -h /var/lib/bitcoind once a month and move to a larger plan before the volume passes 85%.
• Snapshots: take one right after the first sync. If an upgrade or a crash ever corrupts the data, rolling back takes a minute instead of a new sync.
• Keys: keep spending keys in a hardware wallet and use the node as its backend. If you do load a wallet on the server, back up its descriptors and encrypt it.
• Mining is not allowed on VPS plans; a node is. Mining is fine on dedicated and GPU servers, where you have the whole machine.