How to run a Monero node: requirements, setup and hosting in 2026

To run a Monero node you need monerod, an SSD and, to accept peers, TCP port 18080 open. As of October 5, 2026, the Monero docs put the full blockchain at about 265 GiB and a pruned one at 105 GiB, and recommend at least 4 GB of RAM. A public remote node adds restricted RPC on port 18089.

The short version

What hardware does a Monero node need?

Disk comes first. The official systemd guide gives the chain size as of October 5, 2026, about 265 GiB for a full node and 105 GiB for a pruned one, and recommends at least 662.5 GiB and 262.5 GiB of SSD space respectively: two and a half times today’s size, so the chain has room to grow. The project’s FAQ put the full chain at about 225 GB in 2024, so growth runs at tens of gigabytes a year, not hundreds. Mind the units when you compare with drive sizes: 265 GiB is about 285 GB.

The docs recommend SSD storage, and the FAQ warns that the initial sync can take a long time on an old hard drive. NVMe is the comfortable choice for a node that serves wallets, because every wallet that syncs through it makes it read blocks from disk.

Memory. The guide recommends 4 GB of RAM or more. Blocks are verified with RandomX, Monero’s proof-of-work algorithm since November 30, 2019. Its reference implementation has a light mode that needs 256 MiB and is meant for verification, and a fast mode that needs 2,080 MiB and is meant for mining. monerod allocates the full dataset only if you set the MONERO_RANDOMX_FULL_MEM environment variable.

CPU. RandomX is expensive even to verify. That is why monerod, by default, skips the proof-of-work check for older blocks whose hashes ship with the binary (fast-block-sync). It uses every CPU thread for parallel jobs and four threads to hash blocks during sync. The sync is the demanding phase: the reference suggests lowering prep-blocks-threads if you don’t want monerod to monopolize the machine while it catches up. More cores mainly make the first sync shorter.

Full node or pruned node?

Pruning saves about two thirds of the disk without losing the transaction history. A pruned node discards 7/8 of the ring-signature data that is not needed to prevent double spends, keeps a random eighth and makes it available to other nodes. Moneropedia says this has no privacy or security downside for the operator. The cost falls on the network: a pruned node gives syncing nodes up to 1/8 of the help a full node gives, although it relays new blocks and transactions normally.

• Prune from the first sync with prune-blockchain=1. Add sync-pruned-blocks=1 to download blocks that are already pruned, which saves transfer.
• Enabling pruning on an existing chain only marks space as free inside the database file; the file does not shrink. The monero-blockchain-prune tool builds a new, smaller copy from the full one, so you need room for both while it runs.
• The FAQ recommends a full node when storage allows. Run a full node for a public service or to help new nodes sync; run a pruned one for a private node on limited storage.

Monero remote nodes: use one or run one?

A remote node is any node your wallet talks to that is not on the same machine. Moneropedia separates private remote nodes, which you control, typically on a server, from open nodes that anyone can use. A remote node never sees your keys: monerod is decoupled from the wallet and cannot spend your funds. It does see metadata. According to the FAQ, the operator of a remote node can see the IP address a transaction comes from, though not its recipient or amount, and in extreme cases can attempt attacks that reduce your privacy.

That is the case for a node of your own on a server. Your desktop and mobile wallets get a node you control, kept in sync around the clock by systemd, and you never hand your IP address to a stranger’s node. Opening it to others as a public remote node is a service to people who cannot run their own; the docs warn that public RPC may use a sizeable amount of resources.

Monero node on a VPS or a dedicated server?

Both work. What decides is the role of the node.

A node at home works too, with two caveats. Your ISP can see that you run one, as the FAQ points out. And accepting peers behind a router means port forwarding or UPnP, which monerod tries on its own after a while if no inbound connections arrive. A server avoids both: it has a public address, so you can disable UPnP with no-igd, and it stays online when your home connection doesn’t.

Where we fit, and where we don’t: if all you need is a pruned node for one wallet, a machine at home or a small VPS is the cheaper option. A dedicated server pays off for a full or public node, or when the node shares the machine with a Bitcoin node or other services. And if your plan includes mining, look elsewhere: our acceptable use policy does not permit mining on any server. Running a node, private or public, is fine.

Ports and RPC: what to expose

There are two ways to let outside wallets in. The official configuration keeps the full RPC on 127.0.0.1:18081 and adds a second, restricted listener with rpc-restricted-bind-ip=0.0.0.0 and rpc-restricted-bind-port=18089. The restricted API serves view-only calls and leaves out privacy-sensitive data. The alternative restricts the main port with restricted-rpc and binds it publicly with rpc-bind-ip, which monerod accepts only together with confirm-external-bind. Use one or the other: combined, you end up with two restricted APIs.

public-node advertises your RPC port on the P2P network so that wallets can find it automatically, and monerod rejects it unless RPC is restricted in one of the two ways above. Without it, the node can still be public; it just isn’t advertised.

ZMQ is for software on the same machine. monerod runs a ZMQ RPC server on 127.0.0.1:18082 by default, and with zmq-pub it publishes JSON events for new blocks and new mempool transactions that local services can subscribe to. Keep both on localhost, or switch ZMQ off with no-zmq if nothing uses it.

A monerod.conf for a server

This file follows the configuration in the official systemd guide, trimmed to what a server needs. Two changes: UPnP is disabled, because a server is not behind NAT, and disable-rpc-ban, which the guide enables so that wallets connecting through Tor are not banned, stays commented out until you set up Tor or I2P. Uncomment the pruning lines for a pruned node, and public-node to advertise a public one.

# /etc/monero/monerod.conf
data-dir=/var/lib/monero/bitmonero
log-file=/var/log/monero/monero.log
log-level=0                     # minimal; does not log peers or connecting wallets
max-log-file-size=2147483648    # 2 GB; rotate with logrotate instead

# Pruned node only
#prune-blockchain=1
#sync-pruned-blocks=1

check-updates=disabled          # no update checks over DNS
enable-dns-blocklist=1          # block known malicious nodes

# P2P: all interfaces, port 18080 (the defaults)
no-igd=1                        # no UPnP on a server with a public IP
#p2p-use-ipv6=1                 # also accept peers over IPv6

# Wallets: restricted RPC on 18089; full RPC stays on 127.0.0.1:18081
rpc-restricted-bind-ip=0.0.0.0
rpc-restricted-bind-port=18089
rpc-ssl=autodetect
#public-node=1                  # advertise as a public remote node

zmq-pub=tcp://127.0.0.1:18083   # local subscribers only

max-txpool-weight=2684354560    # about 2.5 GB mempool (default about 618 MB)
out-peers=12
in-peers=48
limit-rate-up=1048576           # kB/s, about 1 GB/s (default 8192)
limit-rate-down=1048576         # kB/s, about 1 GB/s (default 32768)

# Tor and I2P, see below
#tx-proxy=tor,127.0.0.1:9050,12,disable_noise
#anonymous-inbound=YOUR_ONION_ADDRESS.onion:18084,127.0.0.1:18084,24
#disable-rpc-ban=1

Run monerod under systemd as a non-root user

The official guide runs monerod as a system user that owns only its data and log directories, while the binaries stay owned by root. Download the Linux command-line archive from getmonero.org and verify it before you extract it: the site lists SHA-256 hashes and publishes a GPG-signed hashes.txt as the canonical reference.

sudo useradd --system monero
sudo mkdir -pm 750 /etc/monero /var/lib/monero /var/log/monero
sudo chown root:monero /etc/monero
sudo chown monero:monero /var/lib/monero /var/log/monero
tar -xvf monero-linux-x64-v*.tar.bz2
sudo mv monero-x86_64-linux-gnu-v*/* /usr/local/bin/
sudo chown root:root /usr/local/bin/monero*

Then create the unit file. It is the one published in the docs and in the Monero repository:

# /etc/systemd/system/monerod.service
[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

sudo systemctl daemon-reload
sudo systemctl enable monerod
sudo systemctl restart monerod
systemctl status monerod
tail -n 100 /var/log/monero/monero.log
monerod status       # height, sync progress and connections
monerod sync_info    # peers, with download and upload stats

--non-interactive lets monerod run in the foreground without a terminal, which is what systemd expects, and Restart=always brings it back 30 seconds after a crash.

Firewall and security

• Open only what you serve. TCP 18080 for peers and, for a public node or your own remote wallets, TCP 18089. Tor and I2P need no open port. With ufw, as in the docs, run ufw allow 18080/tcp and ufw allow 18089/tcp. With nftables, add tcp dport { 18080, 18089 } accept to the ruleset in our first-hour hardening checklist, which also covers key-only SSH and automatic updates.
• Keep the admin interfaces local. The full RPC on port 18081 binds to 127.0.0.1 by default because it gives full administrative control of the node. ZMQ on 18082 and 18083 stays local as well.
• Let monerod limit abuse. By default it allows 3 RPC connections per public IP address and 100 in total, and one P2P connection per IPv4 address or IPv6 /64. Keep the DNS blocklist on. The docs advise against static IP ban lists unless you really need one, because they tend to shut out users who can only connect through anonymity networks.
• Expect hostile traffic. The ban-list option was introduced as an emergency measure during large DDoS attacks on the Monero P2P network in December 2020 and January 2021. Every PowerDedi server includes always-on network DDoS mitigation.
• Use TLS for remote wallets. The reference recommends RPC TLS when a remote wallet connects; rpc-ssl=autodetect uses it whenever the wallet supports it.

Tor and I2P

monerod uses Tor and I2P for transactions, not for syncing: it cannot download the blockchain over onion or I2P services. tx-proxy sends the transactions of your own wallets through a local SOCKS proxy, Tor on 127.0.0.1:9050 or I2P on 127.0.0.1:4447, while blocks and transactions relayed from other peers stay on clearnet. anonymous-inbound announces your onion or I2P address so that other nodes can send you transactions. It needs its own port, 18084 for Tor and 18085 for I2P in the docs, never 18080. The project still describes this integration as experimental.

# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monerod
HiddenServicePort 18089 127.0.0.1:18089    # wallets (restricted RPC)
HiddenServicePort 18084 127.0.0.1:18084    # P2P over Tor

The same onion service forwards port 18089, so your wallets can reach the node over an end-to-end encrypted onion connection, which the docs point out avoids the man-in-the-middle risks of clearnet and Tor exit nodes. Restart Tor, read the address from /var/lib/tor/monerod/hostname, set anonymous-inbound and tx-proxy in monerod.conf, and back up /var/lib/tor/monerod: it holds the keys to your onion address. A Tor client and an onion service are not a Tor relay; our acceptable use policy asks for prior written approval for Tor exit relays only.

How much bandwidth does a Monero node use?

There is no official figure for a public node’s monthly traffic: it depends on how many peers and wallets use it. The documentation gives you the caps instead. By default, monerod limits upload to 8,192 kB/s, about 67 Mbit/s or roughly 21.7 TB in a 30-day month if saturated, and download to 32,768 kB/s, about 268 Mbit/s. The official configuration raises both to 1,048,576 kB/s, about 1 GB/s, so that the node contributes more to the network and syncs faster. With those settings, your port is the limit, not monerod.

Add the initial sync: a full node downloads the whole chain once, and a pruned node that syncs pruned blocks downloads about a third of it. On a metered plan, cap upload with limit-rate-up, or with the limit_up command at runtime, and watch sync_info. On an unmetered 10 Gbps port, the docs’ limits can stay as they are.

Which server for which Monero node

Capacities are before the operating system and filesystem overhead. Striping doubles the space, but losing either drive loses the whole volume and means a full resync. The chain can always be downloaded again; your configuration and onion keys cannot, so back those up elsewhere. A middle path is to partition both drives: a small mirror for the operating system and a stripe for the chains. For the Bitcoin side of a shared machine, see our Bitcoin node hardware guide.

All three are instant configurations, provisioned about 15 minutes after your payment confirms on-chain; the Ryzen 5 7600 and Ryzen 7 7700 are available in Amsterdam, Frankfurt, London, Paris, New York, Miami, Los Angeles and Singapore. Each comes with its own 10 Gbps unmetered port, always-on DDoS mitigation, IPMI/KVM in the browser, and a fixed IPv4 address plus a routed /64 of IPv6, which monerod uses for peers once you set p2p-use-ipv6. Billing is month-to-month, with no setup fee.

Paying for the node in Monero

You can pay for the server in XMR. Prices are set in US dollars, and the XMR amount is locked for 45 minutes once you open the payment. Sign-up takes an email address only, with no ID, phone number or card, and you can top up an account balance so that renewals are paid automatically. The steps are in Pay with crypto, and our page on paying with Monero covers the XMR specifics.

Sources

• Running a Monero Node via Systemd — Monero Docs (chain sizes as of October 5, 2026)
• monerod - Reference — Monero Docs
• Tor and I2P — Monero Docs
• FAQ — getmonero.org
• Pruning — Moneropedia, getmonero.org
• Remote Node — Moneropedia, getmonero.org
• Downloads — getmonero.org
• Anonymity Networks with Monero — monero-project, GitHub
• The Current/Future Status of ZMQ in Monero — monero-project, GitHub
• src/daemon/main.cpp (public-node checks) — monero-project, GitHub
• RandomX — tevador, GitHub
• Running A Full Node — Bitcoin.org