---
title: "How to Run a Bitcoin or Monero Node on a VPS (2026)"
description: "Run a Bitcoin or Monero node on a VPS: disk for pruned and full nodes, the plan that fits, verified installs, a Monero remote node, Tor and bandwidth."
url: https://offshoreserv.com/docs/vps/bitcoin-monero-node
lang: en
updated: 2026-09-26
source: HTML page at the url above (canonical); this is its Markdown version
---

Knowledge base · VPS

# How to run a Bitcoin or Monero node on a VPS

Run a Bitcoin node on a VPS, or a Monero node: disk and RAM per plan, verified Bitcoin Core and monerod installs, pruning, systemd, remote node and Tor.

Updated 26 September 2026 12 min read

In this guide

- A pruned Bitcoin Core node needs about 15 GiB of disk and 2 to 4 GB of RAM, so the Sloop or Cutter plan runs it.
- A pruned Monero node needs about 100 GiB and 4 GB of RAM, from the Schooner plan up; a full Monero node fits the Frigate.
- A full Bitcoin node needs a dedicated server: block data reached 771 GB in September 2026 and grows about 7 GB a month.
- Verify both downloads: the builders' signatures on SHA256SUMS for Bitcoin Core, binaryFate's signature on hashes.txt for Monero.
- Keep RPC on localhost, cap uploads on busy public nodes, and never mine on a VPS: mining is allowed only on dedicated and GPU servers.

VPS9 sections

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](https://offshoreserv.com/offshore-vps) on Ubuntu 24.04 LTS or Debian 12 or 13, with root access as in [getting started](https://offshoreserv.com/docs/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.

> Keep your SSH session open while you change the firewall. If a rule locks you out, the console in the client area still reaches your VPS.

## 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:

| Node | Disk | RAM | Traffic | Plan to start with |
| --- | --- | --- | --- | --- |
| Bitcoin Core, pruned | About 15 GiB | 2 GB; 4 GB syncs faster | Whole chain once, then about 20 GB a month | Sloop (2 GB RAM, 40 GB disk, $3.49 a month) or Cutter (4 GB, 70 GB, $5.49) |
| Bitcoin Core, full | 856 GiB, plus about 7 GB a month | 2 GB; more syncs faster | The same, plus 200 GB or more of uploads a month | Dedicated server |
| Monero, pruned | About 100 GiB (January 2026) | 4 GB or more | About a third of the chain once | Schooner (8 GB, 160 GB, $12.49) |
| Monero, full | About 275 GiB | 4 GB or more | Whole chain once | Frigate (32 GB, 500 GB, $47.99) |
| Both, pruned | About 120 GiB | 8 GB or more | Both of the above | Brigantine (16 GB, 240 GB, $19.99) |

- **Bitcoin:** block data reached 771 GB on 25 September 2026, up 82 GB in a year, on Blockchain.com's [blockchain size chart](https://www.blockchain.com/explorer/charts/blocks-size). [Bitcoin Core 31.1's source](https://github.com/bitcoin/bitcoin/blob/v31.1/src/kernel/chainparams.cpp) 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](https://github.com/bitcoin/bitcoin/blob/v31.1/doc/release-process.md). The bitcoin.org [full node guide](https://bitcoin.org/en/full-node) 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](https://docs.getmonero.org/running-node/monerod-systemd/) 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](https://offshoreserv.com/bitcoin-vps) or Monero.

A full Bitcoin node needs a [dedicated server](https://offshoreserv.com/offshore-dedicated-servers). 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](https://bitcoincore.org/en/download/); its [release notes](https://bitcoincore.org/en/releases/31.1/) 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](https://github.com/bitcoin-core/guix.sigs), 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](https://github.com/bitcoin/bitcoin/blob/v31.1/contrib/init/bitcoind.service) 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](https://offshoreserv.com/docs/security/hardening), 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](https://offshoreserv.com/docs/vps/btcpay-server).

## 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](https://www.getmonero.org/downloads/).

### 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](https://www.getmonero.org/resources/user-guides/verification-allos-advanced.html), 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](https://docs.getmonero.org/interacting/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](https://offshoreserv.com/docs/vps/tor-relay#install-tor); 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](https://github.com/bitcoin/bitcoin/blob/v31.1/doc/tor.md). 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](https://docs.getmonero.org/running-node/monerod-tori2p/) 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](https://www.getmonero.org/resources/moneropedia/remote-node.html) 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](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki), 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](https://offshoreserv.com/privacy-policy) lists. Paying for a [Monero VPS](https://offshoreserv.com/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](https://offshoreserv.com/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](https://github.com/bitcoin/bitcoin/blob/v31.1/doc/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](https://www.getmonero.org/resources/moneropedia/pruning.html).

**Stuck on a step?**

Dedicated and GPU customers can open a ticket from the [client area](https://offshoreserv.com/account/support) with the server’s IP address and what they tried. First reply target: under 12 hours. For every other server, use the Server actions on its page, the [guides](https://offshoreserv.com/docs) and the [network status](https://offshoreserv.com/status) page.

---

OffshoreServ is an offshore hosting provider: VPS, dedicated servers, Windows RDP and GPU servers in seven jurisdictions (Iceland, Switzerland, Moldova, Romania, the Netherlands, Bulgaria and Malaysia), paid only in cryptocurrency (Bitcoin, Ethereum, Monero, Tether (USDT) and Solana), with no identity checks (no KYC).

Prices and plans: https://offshoreserv.com/pricing · Answers: https://offshoreserv.com/faq · Every page: https://offshoreserv.com/llms.txt