Six steps from a bare Nordic VPS to your own monerod — verified binaries, a hardened config, full or pruned, reachable over SSH, WireGuard or a v3 onion. A remote node cannot read your balance, but it can see your IP broadcast your transaction — this guide closes that one gap. Tested on Debian 12 with the v0.18 line.
Provision
Disk first, then harden
Verify
Signature, then install
Configure
monerod.conf + systemd
Sync
A day or two, watched
Connect
SSH, WireGuard or onion
Anonymise
Broadcast over Tor
Almost every Monero wallet ships pointed at somebody else's daemon, because the alternative is a quarter of a terabyte and a two-day wait. That default is defensible and the resulting privacy loss is routinely described wrongly in both directions — by people who think a remote node reads their balance, and by people who think it learns nothing at all. Getting the shape of the leak right is what tells you whether this guide is worth an afternoon of your time.
What it cannot do. It cannot see your balance, your addresses or your keys. A Monero wallet does not tell a node what to look for; it pulls whole blocks over a block range and tries to decrypt each output locally with the private view key, which never leaves the device. The node hands over the same bytes it would hand to anyone. It cannot tell which outputs, if any, were yours — and that is a genuine architectural difference from the light-wallet model used elsewhere, where a server is handed the addresses to watch and therefore knows exactly what it is watching.
What it can do. It sees the IP address that connected. It sees the block range that IP requested, which brackets when the wallet behind it was created. It sees the rhythm of your refreshes, which is a usage pattern. And when you spend, it receives the signed transaction from you first, before the rest of the network has it — so it is in a position to record that this transaction entered the network from this address, at this second. Everything else in Monero is designed to break exactly that kind of link. Handing it to a stranger, for free, alongside a stable IP, is the part worth fixing.
And what it can do that nobody mentions. It can lie. A hostile or merely broken node can serve a stale chain tip so your wallet reports an incoming payment that has not happened, or fail to relay a transaction you believe you sent. None of that steals funds — the wallet verifies what it decrypts — but it does make you act on a false view of the world, which for a merchant waiting on a confirmation is its own kind of loss. A node you run is a node whose answers you do not have to weigh.
| What is exposed | Public remote node | Your node, clear net | Your node, over Tor |
|---|---|---|---|
| Your balance and addresses | Never | Never | Never |
| Your IP, to the node operator | Yes — a stranger | Yes — you | No |
| Wallet creation window | Yes — a stranger | Yes — you | Yes — you |
| IP ↔ your outgoing transaction | Yes — a stranger | Your server IP, to its peers | Broken by the tx proxy |
| Can serve you a false chain tip | Yes | No | No |
"Wallet creation window" stays visible to you on your own node because the request still happens — it simply stops being visible to anyone else. That is the whole point of the exercise: not to make the metadata disappear, but to make you the only party holding it.
A pruned Monero node keeps one eighth of the ring-signature data for old blocks and throws away the rest. It still downloads and verifies every block itself — pruning is not trusting, it is forgetting after checking — and it keeps in full everything a wallet asks for and everything another pruned peer needs. The saving is about two thirds of the disk. For a node whose job is to back your own wallets, there is no functional difference you will ever notice.
The case for a full node is narrow and real: only a full node can hand a brand-new node the complete historical data it needs to verify the chain from scratch, so a network made entirely of pruned nodes would not work. If you have the disk, running full is a contribution. If you do not, running pruned is not a lesser form of participation — it is the configuration most self-hosters should pick.
Decide before you start the daemon. Passing --prune-blockchain on the first run prunes as it syncs, which is fast and free. Converting a full database afterwards means stopping the daemon and running the separate monero-blockchain-prune tool over it, which takes hours and needs the free space to work in. Getting this right at the start costs one line in a config file; getting it wrong costs an evening.
| Shape | Disk, mid-2026 | Tier that fits | Pick it when |
|---|---|---|---|
| Pruned · tight | ~90 GB | Sentinel · 2 vCPU / 4 GB / 120 GB · $3.90 | You want the cheapest working node and accept revisiting the disk |
| Pruned · comfortable | ~90 GB | Garrison · 4 vCPU / 8 GB / 240 GB · $7.90 | The default recommendation — years of headroom, warm database cache |
| Full | 240 GB+ | Ravelin · 8 vCPU / 16 GB / 480 GB · $16.90 | You want an archival copy, or to serve new nodes their initial sync |
| Full + public service | 240 GB+ | Bulwark · 16 vCPU / 32 GB / 960 GB · $32.90 | You intend to carry real peer traffic — unmetered bandwidth matters here |
Chain sizes are an estimate for mid-2026 and they only move in one direction. Verify the current figure before you commit to a tier — every NordBastion plan ships unmetered bandwidth, which is what a node with open peer slots actually consumes.
One thing that is not on this table: RAM. The daemon itself is modest, and 4 GB genuinely runs a node. What the extra memory buys is page cache in front of the database, which is felt during the initial sync and during a wallet's first full rescan rather than in day-to-day operation. If you are choosing between more RAM and more NVMe on the same budget, take the NVMe — and take a look at the tier list before you decide.
In the panel: Order → VPS → Garrison for a pruned node, Ravelin if you want the full chain, image Debian 12. No email address is required to open the account, no identity document is requested at any point, and the invoice settles in Monero — which is a pleasing symmetry, and also the shortest path from a wallet to a booted server we know of. Pick the bastion by latency to yourself, not to the network: peer connections are asynchronous and do not care, but your wallet refreshes will.
Then spend the first hour on the wall. A Monero node is a public service by nature — it listens on a P2P port and talks to strangers — so the baseline is not optional: key-only SSH on a non-default port, a firewall that denies by default, unattended security upgrades, fail2ban. The first-hour hardening checklist is the companion piece and it is worth running end to end before the daemon exists.
The firewall shape for this node is unusually simple. Exactly two things should be reachable from the outside: your SSH port, and the Monero P2P port. Nothing else — in particular not the RPC port, which step 05 reaches through a tunnel instead.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp # or your relocated SSH port
ufw allow 18080/tcp # Monero P2P — the only service port
ufw enable
ufw status numbered
Confirm the disk you actually got before you sync a quarter of a terabyte onto it, because discovering the shortfall forty hours into an initial sync is a specific kind of unpleasant:
df -h /
# → the "Avail" column is your real budget, not the tier name
You are about to install a program that will hold the network view your wallets trust. A tampered monerod is the ideal position from which to lie to a wallet, so the verification step here is not a ritual — it is the reason the Monero project publishes a signed hashes file at all. Do it, once, properly.
Fetch the Linux x86-64 CLI archive and the signed hashes file from the official download page, along with the maintainer's public key as published there. Do not take the key from a third-party keyserver mirror you found in a forum post — take it from the project, over TLS, from the same page that names it.
apt update && apt install -y gnupg curl bzip2
cd /tmp
curl -LO https://downloads.getmonero.org/cli/linux64 # the release archive
curl -LO https://www.getmonero.org/downloads/hashes.txt # the signed hash list
# Import the signing key named on getmonero.org, then:
gpg --verify hashes.txt
# → "Good signature from ..." — anything else, stop here.
Only once the signature verifies does the checksum mean anything. Hash the archive you downloaded and find that exact string inside the file you just verified:
sha256sum linux64
grep -F "$(sha256sum linux64 | cut -d' ' -f1)" hashes.txt
# → one matching line. No output means no match: do not install it.
Then unpack and place the two binaries you need. The archive carries a versioned directory; monerod is the daemon and monero-blockchain-prune is the offline tool you will be glad to have if you ever change your mind about pruning.
tar -xjf linux64
cd monero-x86_64-linux-gnu-*/
install -m 0755 monerod monero-blockchain-prune /usr/local/bin/
monerod --version
Pin the version string that command prints somewhere you will find it again. When a network upgrade is announced you will want to know exactly what you are upgrading from, and "latest" is not an answer.
Give the daemon its own unprivileged user and its own directory. Nothing about a Monero node needs root once it is running, and a service that talks to the open internet all day is precisely the service you do not want running as root.
useradd --system --home /var/lib/monero --shell /usr/sbin/nologin monero
mkdir -p /var/lib/monero /var/log/monero
chown -R monero:monero /var/lib/monero /var/log/monero
/etc/monerod.conf — the same options monerod takes on the command line, written without the leading dashes. Remove the prune-blockchain line if you decided on a full node; that is the only line that is irreversible.
# ── storage ────────────────────────────────────────────────
data-dir=/var/lib/monero
log-file=/var/log/monero/monerod.log
log-level=0
max-log-file-size=104857600
prune-blockchain=1
sync-pruned-blocks=1
# ── P2P: the only port the firewall opens ─────────────────
p2p-bind-ip=0.0.0.0
p2p-bind-port=18080
out-peers=32
in-peers=48
no-igd=1
# ── RPC A: unrestricted, loopback only, for you ───────────
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
# ── RPC B: restricted, what a wallet is allowed to ask ────
rpc-restricted-bind-ip=127.0.0.1
rpc-restricted-bind-port=18089
# ── misc ──────────────────────────────────────────────────
zmq-pub=tcp://127.0.0.1:18083
db-sync-mode=safe
Two RPC listeners is the part worth understanding. Port 18081 answers everything, including administrative calls, and it is bound to loopback where it belongs. Port 18089 is the restricted interface: view-only calls, no privacy-sensitive internals, and it is what every public node on the network exposes. Both are on 127.0.0.1 here on purpose — step 05 reaches 18089 through a tunnel rather than by opening it.
/etc/systemd/system/monerod.service
[Unit]
Description=Monero full node
After=network-online.target
Wants=network-online.target
[Service]
User=monero
Group=monero
Type=simple
ExecStart=/usr/local/bin/monerod --config-file /etc/monerod.conf \
--non-interactive
Restart=on-failure
RestartSec=30
TimeoutStopSec=300
KillSignal=SIGINT
StandardOutput=journal
StandardError=journal
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
[Install]
WantedBy=multi-user.target
KillSignal and TimeoutStopSec are not decoration. The database wants to close cleanly, and a daemon killed hard in the middle of a write can come back needing a repair — or a resync. SIGINT asks it to shut down properly, and five minutes is the grace period to let it finish. Every guide that omits these two lines is one unlucky reboot away from a lost weekend.
systemctl daemon-reload
systemctl enable --now monerod
systemctl status monerod --no-pager
The daemon is now walking the chain from the genesis block, checking every ring signature and every range proof it meets. On NVMe with a few cores that is a day or two; it is bound by CPU and disk, not by bandwidth, so a faster uplink will not shorten it. This work is the entire product. A node that skipped it would just be a slower way of trusting somebody else.
Watch it from a second shell. The status line tells you the height, the peer count and the estimated remaining time, and it is the only monitoring most nodes ever need:
monerod --rpc-bind-port 18081 status
journalctl -u monerod -f --no-pager
df -h /var/lib/monero # check this one more often than you think you need to
Do not import a downloaded blockchain. There are archives on the internet that promise to skip the wait, and importing one converts a node you verified into a node that believes a file a stranger gave you. It defeats the one thing you came here for. If the sync time is genuinely unacceptable, the honest fix is a box with more cores, not a shortcut around the verification.
The bootstrap-daemon trap. monerod can answer wallet queries from a public node while its own sync catches up, which is a convenience with a sharp edge: for as long as it is active, your wallet traffic is being served by exactly the kind of third party this guide exists to remove. If you enable it to get working in the first hour, put a reminder in your calendar and turn it off the moment your own height reaches the tip. A temporary compromise that nobody remembers to end is just the old setup wearing a new name.
When the height stops moving and matches a block explorer you trust, the node is live. From this point the daemon costs you a few gigabytes of traffic a day, a little CPU, and no further attention beyond upgrades.
The restricted RPC interface is bound to loopback, which means it is currently reachable by nothing. That is the correct default and the rest of this step is about choosing how to cross that gap. Pick one — they compose badly and you only need one.
Option A · SSH tunnel — one machine, zero setup. The right answer if you use one laptop. Nothing new is installed, nothing new listens, and the tunnel dies with the session. Your wallet then points at 127.0.0.1:18089 as if the node were local.
ssh -N -L 18089:127.0.0.1:18089 monero-vps
# leave it running; point the wallet at 127.0.0.1:18089
Option B · WireGuard — several devices, always on. The right answer for a phone plus a desktop plus a laptop. The node joins your private network and the wallets address it by its tunnel IP, with no port exposed to the internet at all. The WireGuard guide builds the tunnel; the only extra step here is to let the daemon answer on it.
# in /etc/monerod.conf
rpc-restricted-bind-ip=10.8.0.1 # the node's WireGuard address
confirm-external-bind=1
# and in the firewall, only on the tunnel interface
ufw allow in on wg0 to any port 18089 proto tcp
Option C · v3 onion — anywhere, no port, no fixed IP. The right answer if you travel, or if you want the node reachable without any inbound port anywhere. Tor publishes the service; there is nothing to forward and nothing to scan. The hidden-service guide covers the full torrc; the node-specific part is three lines.
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-rpc/
HiddenServiceVersion 3
HiddenServicePort 18089 127.0.0.1:18089
# then read the address Tor generated for you
cat /var/lib/tor/monero-rpc/hostname
Whichever door you built, the wallet side is the same three fields. In Feather: Settings → Node → add a custom node, host and port, and enable the Tor proxy if you chose the onion. In the official Monero GUI: Settings → Node → Remote node, with "connect to a remote node" selected. In Cake Wallet: Settings → Nodes → add node, which accepts an onion address directly. If you set a username and password on the RPC interface, all three have fields for it.
Then check that it worked. The wallet should show the same height as your node, and the node should show one more RPC client. If the wallet still refreshes in a second flat, it is probably still talking to the default public node — most wallets keep the old one in the list and fall back to it silently.
Your wallet no longer hands transactions to a stranger — it hands them to your own daemon. But that daemon then announces them to its peers from your server's IP address, and peers keep notes. Monero already spreads a new transaction through a randomised relay phase before it fans out, which makes the first hop hard to identify; sending it out over Tor instead removes the question entirely.
One line does it. The daemon keeps syncing blocks over clear net — which is what keeps the sync fast — and routes only your outgoing transaction broadcasts through the local Tor SOCKS port:
# in /etc/monerod.conf, with tor running locally
tx-proxy=tor,127.0.0.1:9050,16
If you want to go further and also accept peers over Tor, publish a second hidden service for the P2P side and tell the daemon which onion address to advertise. The port number is your choice as long as both halves agree and nothing else on the box already uses it:
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-p2p/
HiddenServiceVersion 3
HiddenServicePort 18084 127.0.0.1:18084
# /etc/monerod.conf
anonymous-inbound=YOUR_ONION_ADDRESS.onion:18084,127.0.0.1:18084
That step helps the network more than it helps you, which is a perfectly good reason to take it. It costs a little latency and some peer slots, and it means Tor-only nodes have somewhere to connect.
Optionally: donate a public node. If you have the bandwidth and the disk, you can advertise your restricted RPC endpoint so other people's wallets can use it. It is a genuine contribution to a network whose weakest point is how few people run their own daemon — and it comes with the obligations of any public service: you will carry other people's traffic, and you will be visible as a node operator. Every plan here ships unmetered bandwidth, so the first of those is a decision rather than a bill.
# only if you mean it: expose the RESTRICTED port, never 18081
rpc-restricted-bind-ip=0.0.0.0
confirm-external-bind=1
public-node=1
# and open it: ufw allow 18089/tcp
A node is also a nice thing to put beside other self-hosted infrastructure — a Lightning node on the same rack, for instance. Keep them on separate boxes if the budget allows: they have different uptime requirements and very different recovery stories.
The daemon stops, and the database may need a repair pass before it will open again. Check free space daily during the sync and size the tier for the chain three years from now, not today.
Port 18081 answers administrative calls. It belongs on 127.0.0.1 forever. If something outside must reach the node, it reaches the restricted listener on 18089, through a tunnel.
Adding your node to the list does not select it, and most wallets fall back silently when it is unreachable. Compare heights, and confirm the node reports a connected RPC client.
Adding it later does not shrink an existing database. Converting means stopping the daemon and running monero-blockchain-prune, which needs hours and working space. Decide before the first start.
A network upgrade passed and the daemon was never updated. It does not shout — the height simply stops matching reality. Track the release announcements and upgrade before the fork height.
SIGKILL in the middle of a write, usually from a systemd unit with no KillSignal and a short stop timeout. Use SIGINT and give it five minutes, and let the daemon close its own database.
Ten questions that come up before, during and after moving a wallet onto a daemon you run yourself.
No. Monero wallets scan client-side: the wallet asks the node for a range of blocks, downloads them whole, and tries to decrypt each output locally with your private view key. The node never receives your view key, your spend key or your address, and it cannot tell which of the outputs it just handed you belong to you. This is a real architectural difference from Bitcoin light wallets, where the server is typically told which addresses or scripts to watch. What a remote node does learn is the network layer: your IP address, the fact that a wallet at that IP is syncing, the block range it asked for — which brackets your wallet's restore height — and, most importantly, any transaction you hand it to broadcast. That last one is the leak worth closing.
Run pruned unless you have a reason not to. A pruned node discards seven eighths of the ring-signature data for old blocks, keeps everything a wallet or a new peer actually needs from you, still validates the whole chain itself, and lands at roughly a third of the disk of a full node. For a personal wallet backend the behaviour is indistinguishable. Run a full node if you want to be able to serve a fresh node doing its own initial sync from scratch, if you run block-explorer-style tooling that reads arbitrary historical transaction data, or if you simply want a complete archival copy. Decide before the first sync: --prune-blockchain prunes as it syncs, whereas converting an already-synced full database means stopping the daemon and running the separate monero-blockchain-prune tool over it.
A full node is north of 240 GB in mid-2026 and grows on the order of tens of gigabytes a year, so size for the chain you will have in three years, not the one you have today. A pruned node is roughly a third of that — call it 85 to 95 GB now. In practice that means a Garrison (240 GB NVMe) is the comfortable home for a pruned node with years of headroom, and a Ravelin (480 GB) is the right box for a full one. A Sentinel at 120 GB will hold a pruned node today and will make you think about it again sooner than you would like. Check the current chain size before you buy the disk — this is the one number in this guide that is guaranteed to be out of date.
A day or two on NVMe for a first sync, and it is bound by CPU and disk rather than by your connection. The daemon is verifying every ring signature and every range proof from the genesis block forward; that is the work, and it is the reason the node is worth running at all. Two things make it dramatically worse: spinning rust instead of NVMe, which can turn two days into a week, and running out of disk halfway. Two things that do not help as much as people expect: more bandwidth, and more RAM beyond what keeps the database pages warm. Do not import a downloaded blockchain archive from a third party to skip the wait — you would be trusting exactly the party you set out to stop trusting.
Not the unrestricted one, ever. The unrestricted RPC interface exposes administrative calls, and it should stay bound to 127.0.0.1 for the lifetime of the node. The restricted interface is a different object: it answers only the view-only calls a wallet needs and is what every public node on the network exposes. Even so, publishing it on a clear-net port announces "a Monero user is here" to anyone scanning the address space. The order of preference in this guide is a v3 onion service first, a WireGuard tunnel second, an SSH tunnel for a single machine third, and a bare public port only if you have deliberately decided to donate a public node to the network.
A node holds no keys, custodies no funds and cannot move anyone's money. It validates blocks and relays transactions that other people already signed — the same posture as a mail relay that carries messages it cannot read. That is the technical reality; the legal reality is jurisdictional, and this guide is not legal advice. What the jurisdiction does change is who can compel what: the guide on the four Nordic jurisdictions walks through the statutes that apply to a server sitting in Stockholm, Helsinki, Oslo or Reykjavík.
Only if you update it. Monero performs scheduled network upgrades, and a daemon running an older consensus rule set stops following the main chain at the fork height — it does not warn you loudly, it simply stalls or forks off, and your wallet quietly reports a height that no longer matches reality. Subscribe to the release announcements, pin the version you installed rather than tracking a moving tag, and put a calendar reminder against the announced upgrade height. This is the single most common way a self-hosted node stops being useful: not a crash, just an owner who stopped reading.
Route your outbound transaction broadcasts over Tor — that is the one setting with a clear, cheap privacy return, because it separates "this transaction entered the network" from "this IP address exists". Accepting inbound Tor peers as well is a further step that helps the network more than it helps you, and costs a little latency. Routing all peer traffic over Tor is the aggressive option: it works, and it will make your initial sync considerably slower, so most people sync over clear net and then switch the transaction path to Tor. The Tor hidden service guide covers the torrc side in more depth.
Almost always the restore height. A wallet with no restore height, or one set to zero, rescans the chain from the genesis block every time it is restored, which is hours of local work for nothing. Set the restore height to the block that existed when the wallet was created. The second cause is the network path: a wallet in another country talking to your node over a saturated onion circuit will be slower than the same wallet on a public node next door — that is the price of the privacy, and a WireGuard tunnel usually buys most of the speed back. The third, and the one people miss, is that your node has not finished its own initial sync and is still answering from a bootstrap daemon.
Because a node is a long-lived, publicly reachable object with your transactions passing through it. A full node closes the leak between your wallet and a stranger's node — and then opens a smaller one, between your node and whoever rented you the machine. If the signup for that machine carried a passport scan and a card in your legal name, you have moved the correlation rather than removed it. Paying in Monero for the server that runs your Monero node is not a slogan; it is the only version of the setup where the two layers agree with each other. The pillar guide on anonymous VPS hosting walks the three layers end to end.
Garrison (4 vCPU, 8 GB, 240 GB NVMe, $7.90/mo) holds a pruned node with years of headroom; Ravelin (480 GB) takes the full chain. Unmetered bandwidth on every plan, no email at signup, no identity document, ever.
Last reviewed · 2026-10-12 · Sources · getmonero.org user guides (running a node, pruning, Tor and I2P), monerod --help on the v0.18 line, Debian 12 and Tor Project documentation · Cadence · yearly
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own LN node — bitcoind + LND or Core Lightning, on a VPS.
Accept Bitcoin and Lightning with no processor — non-custodial, no fees.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Private hosting, built in the North.