Run your own Monero node

When you use someone else's node, they see your IP, when you sync, and the transactions you broadcast. Running your own removes that observer entirely, and helps hold the network up. Here's how to do it without leaving anything dangerously open.

Why run your own node

A remote node can't see your balance, your addresses, or which coins are yours. Monero hides those at the protocol level no matter whose node you use. What a remote node does see is metadata: the IP address you connect from, the timing of your syncs, and the transactions you broadcast through it. Some public nodes exist specifically to collect that. Point your wallet at your own node and there's no third party in the loop at all.

There's a network side too. Monero runs on a web of independent nodes that validate and relay transactions and help newcomers sync. Every node you add makes the network a little more decentralized and harder to disrupt. One caveat: your node still connects to peers, so your ISP can tell you run Monero unless you also use Tor or I2P. The win is that no third-party operator sees your wallet's activity.

What you need

The chain only grows, a few GB a month, so treat those disk numbers as a floor and expect them to be larger by the time you read this.

Full vs pruned

Pruning discards about two-thirds of the storage by dropping seven-eighths of the old ring-signature data. Each pruned node keeps a random slice, so the network as a whole still holds all of it. The important part: a pruned node still downloads and validates every block. It's a full-validation node that just stores less history, and there's no privacy or security downside to using one.

Pick pruned for a Raspberry Pi, a small SSD, or simply because it's lighter. Pick full if you have the disk to spare and want to serve complete blocks to more peers. To prune, set prune-blockchain=1 and sync-pruned-blocks=1 (the second downloads already-pruned blocks so you don't fetch the full chain first).

Install and verify

Get the binaries from the official downloads page (the current release is the 0.18.5.x "Fluorine Fermi" line as of 2026; always take the latest). You can also run it via Docker or a distro package, but whatever route you take, verifying the download is the load-bearing step.

First sync

The initial sync downloads and validates the whole chain, and it takes a while: roughly 12 hours to a few days on a desktop with an SSD, and up to about three weeks on a low-power Raspberry Pi. It's a one-time cost. Leaving the default db-sync-mode (fast:async) is right for most people; it batches writes for speed, with a small risk of a corrupted database if the machine loses power mid-write. If your power is unreliable, use a UPS or set db-sync-mode=safe.

If a sync seems to stall or loops "SYNCHRONIZATION STARTED," it's usually low RAM or a database corrupted by a hard shutdown. Adding swap helps on small machines; the last-resort fix is to delete the data directory and re-sync.

A sane monerod.conf

A minimal, safe config for a home node that also serves wallets on your LAN:

data-dir=/var/lib/monero/bitmonero
prune-blockchain=1
sync-pruned-blocks=1

# P2P: normal to expose
p2p-bind-ip=0.0.0.0
p2p-bind-port=18080

# Restricted RPC only — safe for wallets on your LAN
rpc-restricted-bind-ip=0.0.0.0
rpc-restricted-bind-port=18089

# Hygiene
enable-dns-blocklist=1
out-peers=12
in-peers=48
max-txpool-weight=2684354560

The one line to understand: there are two RPC interfaces. The restricted one (18089) blocks dangerous commands and is what wallets need, so it's safe to bind for your LAN. The unrestricted one (default 18081) can control the daemon and must stay on 127.0.0.1. If the node is only for the machine it runs on, you don't need to bind restricted RPC to the network at all.

Firewall and ports

A reasonable baseline with UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 18080/tcp        # P2P
sudo ufw allow 18089/tcp        # only if serving wallets
sudo ufw enable

Never allow 18081. Run monerod as a dedicated non-root user through systemd, keep SSH key-only, and if you only use the node from its own machine you don't need to open any RPC port, the wallet reaches 127.0.0.1 directly.

Running over Tor

Two common additions. tx-proxy routes your outgoing transactions through Tor so your node's IP isn't the visible origin:

tx-proxy=tor,127.0.0.1:9050,12,disable_noise

anonymous-inbound lets peers reach you over a Tor onion service (inbound on 18084). Note that syncing the daemon itself over Tor is slow, so most people sync over clearnet first, then add tx-proxy and an onion service afterward.

Connect your wallet to your node

• Same machine: point the wallet at 127.0.0.1:18089. In the Monero GUI, that's "connect to a remote node" with localhost; Feather and the CLI take --daemon-address 127.0.0.1:18089.
• Another device on your LAN: use <node-ip>:18089, with restricted RPC bound to the LAN and the firewall scoped to your subnet.
• Over Tor: point the wallet at your onion address on 18089 (Feather and the CLI can proxy through Tor).

Never hand a wallet on an untrusted network your unrestricted (18081) port.

Raspberry Pi and spare-box reality

A Pi makes a fine always-on node once it's synced, but set expectations. Use an external SSD, not the SD card (the card is slow and wears out), add a swap file on older Pis so the initial sync doesn't run out of memory, and budget around three weeks for that first cold sync. A common shortcut is to sync the database on a fast PC and copy the data directory over to skip the wait. Turnkey projects like PiNode-XMR exist if you'd rather not hand-configure. If you have a spare x86 box with an SSD, it'll sync dramatically faster and is the easier starting point.

Keeping it running

Update monerod on each release, network upgrades and hard forks require the current version, and re-verify the binary each time. There's nothing to back up on the chain side; it's public and re-syncable. Back up your wallet keys, never the blockchain.