How to run a Bitcoin or Monero node on a VPS

To run a Bitcoin node on a VPS, verify and install Bitcoin Core, set prune=550 and start bitcoind with systemd: a pruned node needs about 15 GiB of disk and 2 to 4 GB of RAM. To run a Monero node on a VPS, do the same with monerod and pruning: about 100 GiB and 4 GB of RAM.

The steps use an Offshore VPS on Ubuntu 24.04 LTS or Debian 12 or 13, with root access as in getting started. Versions are current on 26 September 2026: Bitcoin Core 31.1 and Monero 0.18.5.1, both released on 8 July 2026. We tested the install, verification and service steps on Ubuntu 24.04 and Debian 12.

What you need to run a Bitcoin node or a Monero node on a VPS

Bitcoin Core requirements, like Monero's, come down to disk. A pruned node checks every block but keeps only what it still needs; a full node keeps the whole history. Sizes on 26 September 2026:

• Bitcoin: block data reached 771 GB on 25 September 2026, up 82 GB in a year, on Blockchain.com's blockchain size chart. Bitcoin Core 31.1's source budgets 856 GiB for a synced node, undo data and the 14 GiB UTXO set (the chainstate) included, with the 5 to 10% headroom of its release process. The bitcoin.org full node guide asks for 2 GB of RAM and counts about 20 GB of downloads a month, and often 200 GB or more of uploads.
• Monero: the docs' node guide gave about 250 GiB full and 100 GiB pruned on 20 January 2026. It recommends 4 GB of RAM or more and 625 GiB of SSD for a full node, 250 GiB for a pruned one. A public full node reported 275 GiB on 26 September 2026: get_info shows database_size, rounded up to the next 5 GiB on a restricted RPC port.

For a Bitcoin node VPS, the Sloop meets bitcoin.org's 2 GB minimum and the Cutter leaves room for a larger cache. A Monero node VPS starts at the Schooner for a pruned node and at the Frigate for a full one. To follow the docs' advice of 250 GiB pruned and 625 GiB full, take the Frigate for a pruned node and a dedicated server for a full one. Every plan has a dedicated IPv4 address, and you can pay in Bitcoin or Monero.

A full Bitcoin node needs a dedicated server. Two 1 TB NVMe drives in RAID 1 give 931 GiB, only 75 GiB above Bitcoin Core's estimate. Choose RAID 0 on the deploy page of a Ryzen 7 7700 ($97.49 a month) for about 1.8 TiB without redundancy, where a failed drive means a new sync, or a Ryzen 9 7950X or EPYC 7402P, whose 2 × 1.92 TB give about 1.75 TiB in RAID 1.

Run a Bitcoin node on a VPS with Bitcoin Core

Bitcoin Core 31.1 is the current version on the download page; its release notes list fixes for excessive chainstate disk writes and an IP address leak in private broadcast.

Download and verify Bitcoin Core

Set the version once; later commands reuse it:

apt update
apt install -y wget gnupg git
cd /root
VERSION=31.1
wget https://bitcoincore.org/bin/bitcoin-core-$VERSION/bitcoin-$VERSION-x86_64-linux-gnu.tar.gz
wget https://bitcoincore.org/bin/bitcoin-core-$VERSION/SHA256SUMS
wget https://bitcoincore.org/bin/bitcoin-core-$VERSION/SHA256SUMS.asc
sha256sum --ignore-missing --check SHA256SUMS

The check must print bitcoin-31.1-x86_64-linux-gnu.tar.gz: OK. Several builders sign each release; import their keys from the guix.sigs repository, as the download page shows:

git clone --depth 1 https://github.com/bitcoin-core/guix.sigs
gpg --import guix.sigs/builder-keys/*
gpg --verify SHA256SUMS.asc SHA256SUMS

Each valid signature prints a line starting with gpg: Good signature, 11 for 31.1 in our test, and none may read BAD signature; warnings that a key is "not certified" are expected. Rely on builders you trust: the download page cites the fanquake.gpg key, fingerprint E777 299F C265 DD04 7930 70EB 944D 35F9 AC3D B76A. Then install the two programs a server needs:

tar -xzf bitcoin-$VERSION-x86_64-linux-gnu.tar.gz
install -m 0755 -o root -g root -t /usr/local/bin bitcoin-$VERSION/bin/bitcoind bitcoin-$VERSION/bin/bitcoin-cli
bitcoind -version

Write bitcoin.conf for a pruned node

useradd --system --user-group --shell /usr/sbin/nologin bitcoin
install -d -m 0710 -o root -g bitcoin /etc/bitcoin
cat > /etc/bitcoin/bitcoin.conf <<'EOF'
prune=550
dbcache=1024
maxconnections=40
server=1
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
EOF
chgrp bitcoin /etc/bitcoin/bitcoin.conf
chmod 640 /etc/bitcoin/bitcoin.conf

prune=550

At most 550 MiB of block and undo files, the smallest automatic target. It rules out txindex, and undoing it means downloading the whole chain again. Omit it for a full node.

dbcache=1024

The UTXO cache, in MiB. Since 31.0 the default is 1024 when Bitcoin Core detects at least 4096 MiB of RAM, otherwise 450: set 450 on a 2 GB plan. More cache means a faster first sync.

maxconnections=40

Down from 125: 11 outbound connections plus room for inbound peers, with less memory and traffic.

server, rpcbind, rpcallowip

JSON-RPC for bitcoin-cli on localhost only, with cookie authentication. The help text warns: "Do not expose the RPC server to untrusted networks such as the public internet".

Start bitcoind with systemd

Bitcoin Core keeps its systemd unit in the source tree, not the archive; fetch it and point it at /usr/local/bin:

wget -O /etc/systemd/system/bitcoind.service https://raw.githubusercontent.com/bitcoin/bitcoin/v$VERSION/contrib/init/bitcoind.service
sed -i 's|/usr/bin/bitcoind|/usr/local/bin/bitcoind|' /etc/systemd/system/bitcoind.service
systemctl daemon-reload
systemctl enable --now bitcoind

It runs bitcoind as the bitcoin user with data in /var/lib/bitcoind, restarts it after a failure, allows 10 minutes for a clean stop and mounts /usr and /etc read-only for it. On Debian 12, whose systemd 252 lacks systemd-notify --stopping, bitcoind logs a harmless warning each time it stops.

Open port 8333 for inbound peers (optional)

ufw allow 8333/tcp

The node syncs through outbound connections anyway, but bitcoin.org says you must allow inbound connections to support the network. Allow SSH before you enable UFW, as in the hardening guide, and never open the RPC port, 8332.

Check the sync

bitcoin-cli -datadir=/var/lib/bitcoind getblockchaininfo

blocks climbs toward headers and verificationprogress toward 1. The sync is done when initialblockdownload turns false, and pruned shows true. With -getinfo in place of getblockchaininfo, it prints a summary; /var/lib/bitcoind/debug.log has the details. To take payments through your own server next, see our BTCPay Server guide.

Run a Monero node on a VPS with monerod

Monero 0.18.5.1 "Fluorine Fermi" is the current command-line release on the downloads page.

Download and verify the Monero CLI

Monero lists the hash of each file in hashes.txt, signed with binaryFate's key. As in the project's command-line verification guide, check the key first:

apt update
apt install -y wget gnupg bzip2
cd /root
wget -O binaryfate.asc https://raw.githubusercontent.com/monero-project/monero/master/utils/gpg_keys/binaryfate.asc
gpg --show-keys --with-fingerprint binaryfate.asc

The fingerprint must read 81AC 591F E9C4 B65C 5806 AFC3 F0AF 4D46 2A0B DF92; if not, stop. Import the key and verify the list:

gpg --import binaryfate.asc
wget -O hashes.txt https://www.getmonero.org/downloads/hashes.txt
gpg --verify hashes.txt

Look for Good signature and the same fingerprint, then compare the archive's hash with the list:

XMR=v0.18.5.1
wget https://downloads.getmonero.org/cli/monero-linux-x64-$XMR.tar.bz2
sha256sum monero-linux-x64-$XMR.tar.bz2
grep monero-linux-x64-$XMR.tar.bz2 hashes.txt

Both lines must show the same hash, which for 0.18.5.1 starts with 22a7dda7 and ends with 9958. Install the daemon:

tar -xjf monero-linux-x64-$XMR.tar.bz2
install -m 0755 -o root -g root -t /usr/local/bin monero-x86_64-linux-gnu-$XMR/monerod
monerod --version

Write monerod.conf for a pruned node

As in the docs' node guide, monerod runs as a monero user, with separate directories for configuration, data and logs:

useradd --system --user-group --shell /usr/sbin/nologin monero
install -d -m 0750 -o root -g monero /etc/monero
install -d -m 0750 -o monero -g monero /var/lib/monero /var/log/monero
cat > /etc/monero/monerod.conf <<'EOF'
data-dir=/var/lib/monero
log-file=/var/log/monero/monero.log
log-level=0
prune-blockchain=1
sync-pruned-blocks=1
p2p-bind-port=18080
no-igd=1
in-peers=48
limit-rate-up=4096
enable-dns-blocklist=1
check-updates=disabled
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
EOF
chgrp monero /etc/monero/monerod.conf
chmod 640 /etc/monero/monerod.conf

prune-blockchain, sync-pruned-blocks

Pruning "saves 2/3 of disk space w/o degrading functionality", says the monerod reference; set it before the first sync. The second line accepts blocks that peers already pruned, saving transfer. Omit both for a full node.

p2p-bind-port=18080, no-igd

The default peer-to-peer port, without UPnP, which a server with a public IP address does not need.

in-peers=48, limit-rate-up=4096

Inbound peers are unlimited by default; 48 is the cap in the docs' sample. Upload is in kB/s: 4096 is about 34 Mbit/s, half the default.

enable-dns-blocklist, check-updates=disabled

Refuses peers on a DNS blocklist kept by Monero contributors, and leaves updates to you.

rpc-bind-ip=127.0.0.1

The full RPC on port 18081 "gives full administrative capabilities over the node", so it stays local.

Start monerod with systemd

This unit comes from the Monero docs; --non-interactive runs monerod in the foreground without a terminal:

cat > /etc/systemd/system/monerod.service <<'EOF'
[Unit]
Description=Monero Daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/monerod --config-file /etc/monero/monerod.conf --non-interactive
Restart=always
RestartSec=30
User=monero
Group=monero
StandardOutput=journal
StandardError=journal

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

Open port 18080 for inbound peers (optional)

ufw allow 18080/tcp

As with Bitcoin, the node syncs without it, and the open port lets other nodes connect to yours; keep 18081 closed.

Check the sync

monerod status
monerod sync_info

status prints your height, the network's height, the percentage and your connections; sync_info lists your peers and their speeds. Logs go to /var/log/monero/monero.log and journalctl -u monerod.

Share your node as a Monero remote node

A Monero remote node serves wallets on other machines. The Monero docs give them a restricted RPC port, 18089, and keep the full RPC on localhost. Add three lines to /etc/monero/monerod.conf, then open the port and restart:

rpc-restricted-bind-ip=0.0.0.0
rpc-restricted-bind-port=18089
public-node=1

ufw allow 18089/tcp
systemctl restart monerod

The restricted port answers view-only calls without privacy-sensitive data. public-node=1 advertises it to wallets; omit it to share the address only with wallets you choose. Public RPC "may use a sizeable amount of resources", the docs warn.

The alternative, restricted-rpc=1 with rpc-bind-ip=0.0.0.0, restricts your only RPC port, and monerod refuses to start with it unless you add confirm-external-bind=1, as our test showed. If only your own wallets use the node, an SSH tunnel or an onion address avoids the public port.

Route your node through Tor or I2P (optional)

Install tor from the Tor Project's repository, as in our Tor relay guide; its SOCKS proxy listens on 127.0.0.1:9050 by default.

• Bitcoin Core: proxy=127.0.0.1:9050 routes outbound connections through Tor, and onlynet=onion keeps automatic ones on onion peers. A proxy turns listening off; with listen=1 and access to Tor's control port, Bitcoin Core creates its own onion service. Since 31.0, privatebroadcast=1 sends transactions submitted with sendrawtransaction only over Tor or I2P.
• Monero: tx-proxy=tor,127.0.0.1:9050,disable_noise broadcasts your wallets' transactions over Tor. An onion address needs a HiddenServiceDir line and HiddenServicePort lines for ports 18084 and 18089 in torrc, plus an anonymous-inbound line; the docs' Tor and I2P guide has them all, and I2P works the same way. Tor needs no open ports.

Privacy: a node on a VPS versus a node at home

Peers see your node's IP address. On a VPS, that is the server's address, not your home's, and your internet provider sees connections to one server rather than a node trading data with dozens of peers. Your wallet also stops querying a stranger's node, whose operator "can link transactions to IP addresses", as Moneropedia's remote node entry warns.

A server is not invisible: its host can see traffic metadata, meaning which addresses it talks to, when and how much. Bitcoin Core encrypts connections to peers that support BIP324, which is on by default, and Tor hides your peers as well. We do not log or inspect customer server traffic.

Our records are short: an email address, which can be disposable, your top-ups (coin, amount, deposit address, transaction ID) and your services, never your IP address, as the privacy policy lists. Paying for a Monero VPS keeps the sender, the receiver and the amount off the public record, while a Bitcoin payment stays visible on-chain.

Bandwidth, mining and our rules for nodes

• Nodes are welcome. Our acceptable use policy allows anything legal where the server runs, and Bitcoin, Monero and Lightning nodes are among the uses we list for our VPS.
• No mining on a VPS or RDP. It takes CPU time from the other customers on the host, so the policy forbids it there, monerod's built-in miner included. Dedicated and GPU servers allow it.
• Fair use. Traffic is unmetered on 1 Gbps ports, but cap a busy public node: maxuploadtarget=5G in bitcoin.conf aims for 5 GiB a day, and limit-rate-up caps monerod. If a node causes a problem on a VPS, we tell you in the client area first and suggest a fix, such as a dedicated server, which you can use to its stated capacity.

The Bitcoin target is soft: near it, Bitcoin Core stops serving blocks older than a week, a major part of the traffic, as reduce-traffic.md explains. bitcoin-cli -datadir=/var/lib/bitcoind getnettotals shows what is left of the current 24 hours.

Update Bitcoin Core and monerod

Neither archive updates itself. For a new version, repeat the download and verification steps with the new version number, then stop the service with systemctl stop bitcoind or systemctl stop monerod, install the new binary and start the service again, as Bitcoin Core's release notes advise.

Frequently asked questions

How much disk does a Bitcoin node need?

A full node needs about 856 GiB, the estimate built into Bitcoin Core 31.1, and grows about 7 GB a month; block data alone reached 771 GB on 25 September 2026. A pruned node with prune=550 needs about 15 GiB, mostly for the UTXO set, but still downloads every block once.

Can I run a Monero node on a VPS?

Yes. A pruned Monero node needed about 100 GiB in January 2026, and the Monero docs recommend 4 GB of RAM or more: our Schooner plan (4 vCPU, 8 GB of RAM, 160 GB NVMe, $12.49 a month) fits it. A full node, about 275 GiB in September 2026, fits the Frigate, the Flagship or a dedicated server.

Is it legal to run a Bitcoin or Monero node?

A node downloads, checks and relays public data and holds no one else's money, and most crypto rules target businesses such as exchanges. From 10 July 2027, the EU's Anti-Money Laundering Regulation bars regulated crypto-asset service providers from keeping accounts that use anonymity-enhancing coins such as Monero, which does not affect holding Monero in your own wallet. Check the law where you live and where the server runs.

Can I mine on a VPS?

No. Our acceptable use policy forbids cryptocurrency mining on VPS and RDP plans, because it takes CPU time from the other customers on the host; that includes monerod's built-in miner. Mining is allowed on dedicated and GPU servers, which are provisioned for you alone, and a node that does not mine is welcome on every plan.

What is a pruned node?

A pruned node checks every block like a full node, then deletes data it no longer needs. Bitcoin Core with prune=550 keeps the newest 550 MiB of blocks and the UTXO set, so it cannot serve old blocks or use txindex. Monero's pruning drops 7/8 of the ring signature data, saving about two thirds of the space with no privacy or security downside, per Moneropedia's pruning entry.