Home / Servers / MONERO NODE VPS

Run a Monero node on a VPS that asks for nothing

monerod, pruned or full, on NVMe in 8 locations or on a Blackbox in Montreal. Disk is the constraint: about 90 GB pruned, about 230 GB full. Signup asks for no email, no name and no ID. Node yes, mining no.

Deploy a node VPS from $9.99 / month / disk decides the plan

Size the disk first, everything else is easy

Chain sizes are mid-2026 figures. They only go up.
Pruned: about 90 GB01

Pruning removes 7/8 of the ring signature data and saves two thirds of the space, keeping the full transaction history. Roughly 75 to 95 GB of chain today (Monerica). This is the default choice for a VPS.

Full: about 230 GB02

Roughly 215 to 235 GB in mid-2026, growing a few gigabytes a month. Worth it if you serve the whole chain to other people or run a block explorer.

Headroom, not a fit03

A disk that exactly fits the chain today runs out mid-year. Doubling the current size is the sane compromise.

4 GiB RAM is enough04

The minimum is 4 GiB and extra RAM mostly buys a faster first sync. Two to four cores covers validation.

NVMe, not spinning disk05

Initial sync is bound by CPU and disk, not by bandwidth. Blackbox NVMe sits on a ZFS mirror; check the storage column on the pricing page for the standard line.

A few GB of traffic a day06

A synced node relays blocks and transactions continuously. Blackbox is 10 Gbps unmetered; cap the node with limit-rate-up and limit-rate-down if you want to.

Quick start: pruned monerod node under systemd

Debian 13, run as root. Version and layout follow the official Monero docs; check getmonero.org/downloads for the current release before copying the version string.
# Monero CLI 0.18.5.1 "Fluorine Fermi". Sources for every step:
#   https://www.getmonero.org/downloads/
#   https://docs.getmonero.org/running-node/monerod-systemd/

apt update && apt install -y curl bzip2 ufw

# 1. Download the binaries and the signed hash list, then compare.
cd /tmp
curl -LO https://downloads.getmonero.org/cli/linux64
curl -LO https://www.getmonero.org/downloads/hashes.txt
sha256sum linux64
# curl -LO on /cli/linux64 saves the tarball under the name "linux64", so the
# filename differs from the manifest. Compare the hash you just printed against
# the monero-linux-x64-v0.18.5.1.tar.bz2 line in hashes.txt.
# hashes.txt is canonical only once its GPG signature checks out against
# binaryfate's key in the source tree:
# https://github.com/monero-project/monero/blob/master/utils/gpg_keys/binaryfate.asc

# 2. Unpack and install the binaries.
tar -xjf linux64
mv monero-x86_64-linux-gnu-v0.18.5.1/* /usr/local/bin/.

# 3. Service account, data directory, log directory.
useradd --system monero
mkdir -pm 750 /var/lib/monero
mkdir -pm 750 /var/log/monero
chown monero:monero /var/lib/monero /var/log/monero

# 4. Configuration. prune-blockchain must be set BEFORE the first sync: added
#    later it prunes the old data only logically, without shrinking the file.
mkdir -p /etc/monero
cat > /etc/monero/monerod.conf <<'EOF'
data-dir=/var/lib/monero/bitmonero

prune-blockchain=1
sync-pruned-blocks=1

log-file=/var/log/monero/monero.log
log-level=0
max-log-file-size=2147483648

check-updates=disabled
enable-dns-blocklist=1

p2p-bind-ip=0.0.0.0
p2p-bind-port=18080
no-igd=1

# Admin RPC stays on localhost. Reach it over an SSH tunnel.
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081

out-peers=12
in-peers=48
limit-rate-up=1048576
limit-rate-down=1048576
EOF
chown monero:monero /etc/monero/monerod.conf

# 5. systemd unit, taken from the Monero docs.
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 monerod
systemctl restart monerod

# 6. Firewall: SSH plus the P2P port. Nothing else.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 18080/tcp
ufw enable

# 7. Watch the first sync. It is bound by validation and disk speed, not by
#    the network link; a spinning disk costs 4 to 8 days (ditatompel).
journalctl -u monerod -f
/usr/local/bin/monerod status

Reaching the node: SSH tunnel, restricted RPC, Tor

In order of how much of the internet you invite in.
# A. PRIVATE (recommended). RPC never leaves the box.
#    From your own machine, tunnel 18081 and point a wallet at it:
ssh -N -L 18081:127.0.0.1:18081 root@YOUR_SERVER_IP
monero-wallet-cli --daemon-address 127.0.0.1:18081 --trusted-daemon
#    --trusted-daemon is automatic for localhost and enables commands that
#    rely on the daemon being yours. Reference:
#    https://docs.getmonero.org/interacting/monero-wallet-cli-reference/

# B. PUBLIC. Serve the RESTRICTED RPC only. Never expose 18081.
#    Add to /etc/monero/monerod.conf, then restart monerod:
#      rpc-restricted-bind-ip=0.0.0.0
#      rpc-restricted-bind-port=18089
#      public-node=1     # optional: advertise the node to wallets
ufw allow 18089/tcp
#    Restricted RPC is view-only and "do not return privacy sensitive data":
#    https://docs.getmonero.org/interacting/monerod-reference/

# C. TOR. Broadcast your own transactions over a hidden service.
apt install -y tor
cat >> /etc/tor/torrc <<'EOF'
HiddenServiceDir /var/lib/tor/monero/
HiddenServicePort 18084 127.0.0.1:18084
EOF
systemctl restart tor
cat /var/lib/tor/monero/hostname     # this is YOUR_ONION

#    Then add to /etc/monero/monerod.conf and restart monerod:
#      tx-proxy=tor,127.0.0.1:9050,16
#      anonymous-inbound=YOUR_ONION:18084,127.0.0.1:18084,24
#    Config shape from the official example and from:
#    https://github.com/monero-project/monero/blob/master/docs/ANONYMITY_NETWORKS.md

Which Servury plan fits a node

Pick by disk. Prices are per month, any term from 7 to 365 days.
Blackbox Max, $39.9901

6 vCPU, 16 GB, 200 GB NVMe on a ZFS mirror, 10 Gbps unmetered, Montreal. The comfortable pruned node: about twice the current pruned chain, so it stays comfortable. AMD SEV-SNP encrypted memory and no guest agent.

Blackbox Ultra, $79.9902

8 vCPU, 32 GB, 400 GB NVMe. The full-node tier, with room for a couple of years of chain growth on top of a 230 GB chain. Same encrypted memory, same 10 Gbps unmetered port, 1 IPv4 plus a routed /64.

Standard VPS and VDS03

New York, Montreal, London, Paris, Frankfurt, Eygelshoven, Singapore (currently sold out) and Hong Kong. Check the disk column on the pricing page against the chain sizes above: several plans are sized for web workloads, not for a chain. IPv4 only on this line.

What running a Monero node on a VPS actually takes

A Monero node is monerod: the daemon that downloads every block, validates it and relays transactions to peers. Running your own is the surest way to transact without telling somebody else which transactions you care about. The project puts it plainly: "A remote node operator is able to see from what IP address a transaction comes from (even if cannot see the recipient nor the amount)" (getmonero.org FAQ). A VPS is a reasonable home for one: a node wants to be online continuously, and a laptop is not.

Disk is the whole decision. A full chain sat at roughly 215 to 235 GB in mid-2026 and grows a few gigabytes a month (Monerica, updated 16 July 2026). Pruning "allows node operators to save 2/3 of storage space while keeping the full transaction history" by removing 7/8 of the ring signature data, and the documentation is explicit that "there are no privacy or security downsides when using a pruned node" (Moneropedia: pruning). That lands a pruned chain around 75 to 95 GB today (Monerica, above). Size for growth: one requirements guide recommends about 237 GiB free for a pruned node and about 575 GiB for a full one (Monerica requirements). Set prune-blockchain=1 before the first start: added later, "the past data will only be pruned logically w/o shrinking the file size", so you gain nothing on disk unless you rebuild the database with monero-blockchain-prune (monerod reference).

Everything else is modest. 4 GiB of RAM is the working minimum and more mostly buys a faster first sync; two to four cores is plenty (Monerica, above). Disk speed matters more than core count: the initial sync is bound by validation work and disk speed rather than by the network link, which is why "downloading and verifying the entire blockchains to the spinning hard disk can take 4 - 8 days" (ditatompel).

Exposure is a choice you make twice. Open TCP 18080 so peers reach you inbound. Then decide what to do with the RPC. Port 18081 is an admin interface and belongs on 127.0.0.1 behind an SSH tunnel. The restricted RPC, limited to view-only commands that "do not return privacy sensitive data" (monerod reference) and conventionally bound to port 18089 (systemd guide), is the only one to open if you want to serve other people's wallets. Understand what that turns the box into: a listed, scanned, publicly hit service on a host with no DDoS protection.

Mining is prohibited. Running monerod is an ordinary workload here. P2Pool is not: it is a "decentralized pool for Monero mining" and exists to have a miner such as XMRig pointed at it (P2Pool README). Cryptocurrency mining of any kind is prohibited under the terms. Node yes, hashrate no.

Where the node lives matters most when a wallet lives beside it. A node holds public data, so any plain VPS will do for monerod alone. A wallet holds spend keys in RAM, and on ordinary virtualisation the host can read guest RAM. The Blackbox line runs each guest under AMD SEV-SNP with debug disabled in the launch policy, carries no guest agent, and hands you a CPU-signed attestation report to check before you type a disk passphrase (measured boot guide). Pay for the node in XMR on the Monero VPS page; the Tor relay page and the Bitcoin node page cover the neighbouring cases.

Pick the disk, deploy, start syncing.

No email, no name, no ID. Pay in Monero if you like. A 32-character credential is the whole account.

Deploy a node VPS

Fair questions

How much disk does a Monero node need?

A full node held roughly 215 to 235 GB of chain in mid-2026 and adds a few gigabytes a month; a pruned node holds about a third of that, roughly 75 to 95 GB. Size for growth, not for today. On Servury that means Blackbox Max (200 GB NVMe) for a pruned node and Ultra (400 GB) for a full one. Core (50 GB) and Plus (100 GB) are too small to stay healthy for long.

Pruned or full: which should I run?

Pruned, unless you have a reason not to. Pruning drops 7 of every 8 parts of the ring signature data and saves two thirds of the space while keeping the full transaction history, and the Monero documentation states there are no privacy or security downsides to using one. A pruned node still relays new transactions and blocks; what it gives up is helping new nodes sync. Run a full node to serve the whole chain to others.

How long does the initial sync take?

The sync is bound by validation work and disk speed rather than by the network link, which is why a spinning disk turns it into 4 to 8 days. Set prune-blockchain=1 before the first start. Adding it later prunes the old data only logically, without shrinking the file, unless you rebuild the database with the monero-blockchain-prune tool.

How much RAM and CPU does monerod want?

4 GiB of RAM is the working minimum and more mainly buys a faster first sync. Two to four cores is enough. Disk size and disk speed decide the plan; RAM and CPU rarely do.

Can I run P2Pool or mine Monero on a Servury server?

No. Cryptocurrency mining of any kind is prohibited by the terms, and P2Pool is a decentralised pool for Monero mining that you point a miner such as XMRig at. Running monerod is an ordinary workload and is welcome. Mining on top of it leads to suspension.

Which ports do I need to open?

TCP 18080 for the peer-to-peer port, so other nodes can connect inbound. Leave the unrestricted RPC on 18081 bound to 127.0.0.1 and reach it over an SSH tunnel. Open 18089, the restricted RPC, only if you deliberately want to serve other people's wallets.

Is it safe to expose the RPC port?

Only the restricted one. The daemon reference describes restricted RPC as view-only commands that do not return privacy sensitive data; that is what port 18089 serves. Port 18081 is an admin interface and should never face the internet. A public node gets listed, scanned and hit, and Servury has no DDoS protection on any line.

Does encrypted memory matter for a node?

It matters if a wallet lives on the same machine. A node holds public data, so a plain VPS is fine for monerod alone. A wallet holds spend keys in RAM, and on ordinary virtualisation the host can read guest RAM. Blackbox machines run under AMD SEV-SNP with debug disabled, so the host cannot read guest memory.

Guides on this

Related use cases