Allow plenty of time for the first synchronization. Our own pruned node took almost a day to synchronize with the Monero network. Your result may be faster or slower depending on CPU, storage performance, peers and network conditions. Pruning reduces storage requirements; it does not make the initial synchronization instant.
What you will set up
The VPS runsmonerod, the Monero node software, as a background service. It starts automatically after a reboot and accepts connections from other nodes. Your wallet stays on your own computer and connects through an encrypted SSH tunnel.
No wallet seed, private spend key or view key is needed on the VPS. This guide installs a node, not a payment gateway or a wallet service.
Before you begin
Use a fresh Debian 13 x86-64 VPS, with root access and an SSH client on your computer. Keep the VPS console available in the EDIS Global control panel while configuring the firewall. For a pruned node, our suggested starting point is:
These are planning recommendations, not a guarantee of synchronization speed or future capacity. Check the current Monero storage guidance before ordering. Leave space for Debian, logs, updates and blockchain growth; do not size a VPS to the database’s current size alone.
A pruned node retains the information needed for normal wallet use while discarding much of the historical signature data. It still contributes to the network, although an unpruned node can serve more historical data to other peers. For a practical comparison, see Understanding pruning: is it like RAID 5? below, or read Monero’s explanation of pruning.
1. Prepare Debian
Run the server commands below as root, or enter a root shell withsudo -i first. They are intended for a new installation; do not overwrite an existing node configuration.
uname -m should report x86_64 for the download used below. Install Debian security updates before proceeding and reboot first if an update requires it.
2. Download and verify Monero
Use the CLI archive from the official Monero downloads page; it includesmonerod. This example uses v0.18.5.4, the release checked when this guide was written on 27 October 2026. Check for a newer stable release before installing and adjust the version and archive name accordingly.
3. Create the service account and configuration
Give the daemon its own account and writable data directories:/etc/monero/monerod.conf:
max-concurrency=2 limits parallel worker threads; adjust it to suit your VPS. Update checking is disabled here, so you must track new Monero releases yourself.
The upload setting is approximately 1 MiB/s. Sustained at that rate for 30 days, uploads alone would approach 2.7 TB. Actual usage varies, and this setting is not a monthly traffic cap. Monitor your VPS traffic and adjust the rate to your allowance.
4. Configure the firewall
Allow inbound TCP 18080 so other Monero nodes can connect. Keep 18081 and 18089 closed to the internet; the wallet connection in this guide uses SSH. If you already manage the VPS with nftables, iptables or another firewall, add the P2P rule through that existing system. Do not install a second firewall manager or replace an existing ruleset. Include any upstream firewall in your checks. For a fresh VPS with no existing firewall policy, this UFW example permits SSH and P2P:5. Run the node with systemd
Create a service that runs asmonero and stores its data outside the installation directory:
0.0.0.0:18080, 127.0.0.1:18081 and 127.0.0.1:18089. There should be no public RPC listener.
6. Let the initial synchronization finish
The service continues running when you disconnect from SSH. Watch its progress with:status to be OK and synchronized to be true. Check again later if peers have not connected yet. target_height is not always populated once the node is caught up; it is not a fixed target to enter manually.
Plan for a long first sync, even with pruning. Our initial synchronization took almost a day. Progress is not uniform, so an early percentage or estimated completion time may be misleading. Subsequent starts normally catch up from the saved database instead of downloading everything again.
Check free space and memory during synchronization:
7. Connect your wallet privately
On your own computer, open an SSH tunnel to the restricted RPC listener. ReplaceYOUR_SSH_USER and YOUR_VPS_IP with your normal SSH login details:
-p YOUR_SSH_PORT. Leave this terminal running while using the wallet. A successful tunnel usually shows no further output.
In Monero Wallet GUI, use Advanced mode and open Settings → Node. Select a remote node and enter:
Select the node and connect. Here,
127.0.0.1 refers to the local end of the tunnel on your computer. SSH carries the connection to your VPS. After the daemon has synchronized, the wallet still needs to scan its own transaction history.
For a connection check, run this on your computer while the tunnel is open:
"restricted": true. Do not use 18080 in the wallet: that port speaks the P2P protocol, not wallet RPC.
Your wallet files and keys remain on your computer or hardware wallet. The SSH tunnel encrypts the wallet-to-VPS connection; it does not make the VPS anonymous or hide its public IP from Monero peers.
Public P2P versus public wallet access
With TCP 18080 reachable, your node already helps other Monero nodes. You do not need to offer public wallet RPC to contribute. Serving wallets for everyone is a separate operating choice. It requires a public restricted RPC listener, connection limits, bandwidth planning, monitoring and an appropriate TLS configuration. It can generate considerably more load. For a node that also supports business payments, we recommend placing a public wallet service on a separate VPS. Never expose unrestricted daemon RPC ormonero-wallet-rpc to the public internet. This guide deliberately keeps wallet access behind SSH. See the Monero RPC configuration reference if you plan a dedicated public service.
Maintenance and troubleshooting
The wallet cannot connect
The wallet cannot connect
Confirm that the SSH tunnel is running and that the wallet uses
127.0.0.1:18089. Test /get_info from your computer. If SSH reports that the local port is already in use, use a different local port, such as 28089, in the first half of -L and in the wallet; keep the VPS destination at 127.0.0.1:18089.There are no incoming peers
There are no incoming peers
Check
in-peers, hide-my-port, the listening address and both the VPS and upstream firewalls. A newly started node may need time to attract incoming connections. From a different machine, nc -vz YOUR_VPS_IP 18080 can test TCP reachability; this is not a wallet RPC test.The logs show blocked or unblocked hosts
The logs show blocked or unblocked hosts
With
enable-dns-blocklist=1, the daemon uses Monero’s DNS blocklist. Peer bans can also result from peer behavior. These messages alone do not mean your server is failing. Check synchronization and healthy peer connections before treating them as an incident.The service fails with a permissions error
The service fails with a permissions error
Check that
/etc/monero is owned by root:monero with mode 0750, and monerod.conf by root:monero with mode 0640. The monero user must be able to write to /var/lib/monero and /var/log/monero. Read the journal for the exact path; avoid making these directories world-writable.Disk space or traffic usage is growing
Disk space or traffic usage is growing
Pruned databases still grow. Monitor
df, database size and the EDIS Global traffic dashboard. Adding pruning to a previously unpruned database does not immediately shrink its existing file. Do not delete the database as a first troubleshooting step; consult the official pruning documentation and plan additional storage if needed.How do I update the node?
How do I update the node?
Follow official Monero release announcements. Download and verify the new release as in step 2 before stopping anything. Back up the configuration and service file, stop the service with
systemctl stop monerod, replace /opt/monero/monerod with the verified binary, then run systemctl start monerod. Verify the version, service status and synchronization afterward. Keep /var/lib/monero intact and review release-specific upgrade instructions first.Understanding pruning: is it like RAID 5?
A pruned node keeps the essential transaction history while discarding much of the older signature and proof data. It can still support normal wallet use, validate new blocks and relay transactions. An unpruned node retains the complete historical data. The RAID comparison helps explain one aspect: different Monero nodes can retain different portions of the historical data. However, pruning does not use RAID 5’s parity or recovery mechanism.
A useful analogy is a network of libraries: every library keeps the essential records, while different libraries keep different sections of the detailed historical archive. Some libraries, which represent the unpruned nodes, keep the entire archive. A library cannot recreate a missing section merely from the sections it already has.
The 1/8 applies only to the prunable data, not to the whole blockchain. That is why pruning saves roughly two-thirds of total storage rather than seven-eighths. Keeping complementary portions lets pruned nodes help other peers synchronize; it does not turn the network into a storage array or replace backups.
See Monero’s pruning overview and its explanation of how pruned nodes share historical data.