Monero Pruned Node Setup Guide: Save 60GB in 2026

By May 2026 the Monero blockchain has grown to roughly 215 GB on disk, a figure that climbed sharply after the November 2025 hard fork brought FCMP++ into production and pushed daily transaction counts past the 60,000 mark for several consecutive weeks. For anyone running a node on a 256 GB laptop SSD, a Raspberry Pi 5 with a budget NVMe hat, or a metered VPS, a full archival sync is no longer a casual commitment. A pruned node solves this elegantly: it discards roughly two-thirds of the historical ring signature data while keeping every block header, every transaction output, and your ability to verify the entire chain locally and trustlessly. The result is a fully sovereign Monero daemon that occupies about 85–95 GB instead of 215 GB, still serves wallets over RPC, still participates in the peer-to-peer swarm, and still broadcasts your own transactions through Dandelion++ without leaking metadata to a stranger's remote daemon. This guide walks through exactly how to deploy one on Linux, Windows, macOS, and a headless Raspberry Pi — including the systemd unit file that survives reboots, the firewall rules that protect the RPC port, and the resync recovery steps for when something inevitably gets corrupted. Whether you found this article after using MoneroSwapper for a no-KYC swap or you are wiring up your first independent node, the destination is identical: less disk consumed, no privacy lost.

Why Run a Pruned Node Instead of a Remote One

It is tempting, especially on a constrained device, to skip running a node entirely and point your wallet at a community node like node.moneroworld.com or one of the .onion endpoints listed on the Monero forums. That works, technically. It also hands the operator of that node a precise log of which transactions your wallet scans, what time you come online, and — through traffic correlation — a reasonable guess at which outputs belong to you. Remote nodes cannot see your view key or your spend key, but they can absolutely build a behavioral fingerprint, and several academic papers published in 2024 and 2025 demonstrated practical decloaking attacks against wallets that relied exclusively on third-party infrastructure.

A pruned node closes that gap without forcing you to find a spare terabyte. The privacy guarantees are identical to a full node from a wallet's perspective, because the pruning logic discards only redundant ring signature data — never any output, never any key image, never any block header. Your wallet scans the chain against locally held data, your transactions enter the mempool through your own peer connections, and your RPC traffic never leaves localhost.

• No remote operator sees your wallet activity: every refresh, every output scan, every fee estimate happens on your own machine.
• You still help the network: a pruned node serves about one-third of the historical blocks to other peers, which collectively means the swarm does not need every node to be archival.
• Hardware floor is reasonable: 4 GB RAM, a modern quad-core ARM or x86 CPU, and 120 GB of free SSD space is enough through at least 2027 even with conservative growth assumptions.
• Recovery is straightforward: if the database ever corrupts you can resync from scratch in roughly six to twelve hours on a residential fiber line, versus eighteen to thirty for a full archival node.

Pruned vs Full Node: What Actually Differs

The Monero pruning algorithm, introduced in v0.15 and refined steadily through v0.18.4 in 2025, splits the chain into 8 "pruning stripes" of 4096 blocks each. A pruned node keeps the full data for exactly one of those stripes (chosen pseudo-randomly per peer when the node is initialized) plus the most recent 5500 blocks in full, and it keeps headers, key images, output amounts, and miner data for all other blocks. The ring signature data — which is the bulk of the on-disk weight — is discarded for the seven stripes the node does not host.

Because every node hosts a different stripe, the swarm collectively retains the entire historical blockchain even if every node prunes. A wallet doing a fresh sync that needs ring signature data for an old block simply downloads it from whichever pruned peer happens to host that stripe, transparently and without user intervention. From a verification standpoint nothing is sacrificed: each pruned node validates the chain in full when first synced, and continues to validate every new block as it arrives.

The only meaningful tradeoff a pruned node makes is that it cannot serve as the data source for a block explorer or for academic chain analysis tools that need full historical ring signatures. If those are not on your roadmap — and for the vast majority of self-hosted users they are not — pruning is strictly better than archival on a constrained machine.

Hardware and System Requirements in 2026

The hardware floor for a comfortable pruned Monero node has crept up modestly since the FCMP++ activation, primarily because membership proof verification on incoming blocks is roughly 18% more CPU-intensive than the pre-fork CLSAG verification. The good news is that any device built after roughly 2021 sails through it. The bad news is that older single-board computers — original Raspberry Pi 4 with 2 GB RAM, low-power Atom-based mini-PCs — will struggle to keep up with the chain tip during heavy transaction days.

Recommended baseline

• CPU: Quad-core ARM Cortex-A76 (Raspberry Pi 5) or any modern x86-64 with AES-NI. Avoid 32-bit hosts entirely; LMDB performance degrades and several wallet RPCs misbehave.
• RAM: 4 GB minimum, 8 GB comfortable. The LMDB memory map benefits from headroom; if RAM is constrained, monerod will still run but block verification slows noticeably.
• Storage: 120 GB free on an SSD or NVMe. Spinning rust technically works but a HDD will turn a 6-hour sync into a 36-hour ordeal — the random-access pattern of LMDB is brutal on platters.
• Network: 25 Mbps symmetric is plenty for steady-state operation. Initial sync will saturate whatever you have; budget 90–110 GB of download for the pruned bootstrap.
• Operating system: Ubuntu 24.04 LTS, Debian 12, Fedora 41, macOS 14+, or Windows 11. NixOS users have a maintained service module; Arch users have monero-bin in the AUR.

If you are deploying on a Raspberry Pi 5, use the official NVMe Base from Pimoroni or an equivalent M.2 hat; the SD card slot is acceptable for the OS but should never host the blockchain. SD cards die from the write pattern within months, and the I/O latency makes the daemon look perpetually behind tip even when it has fully synced.

Step-by-Step Setup on Linux

The reference path is Linux because it is the simplest to reproduce, the most common production target, and the easiest to keep running unattended. Adaptations for macOS and Windows follow at the end.

1. Create a dedicated user and directory. As root, run useradd -r -s /bin/false monero and then mkdir -p /var/lib/monero/blockchain /var/log/monero followed by chown -R monero:monero /var/lib/monero /var/log/monero. Running monerod under a service account, not your login user, is the single biggest hardening win and costs nothing.
2. Download the official binary. Visit getmonero.org/downloads and grab the Linux 64-bit tarball — at time of writing the current release is v0.18.4.2. Critically, also download the matching hashes.txt and verify the SHA256 with shasum -a 256 monero-linux-x64-v0.18.4.2.tar.bz2, then confirm the signature on hashes.txt with gpg --verify hashes.txt using binaryFate's PGP key. Skipping verification is how malware gets onto your machine.
3. Extract and install. Untar with tar xjf monero-linux-x64-v0.18.4.2.tar.bz2, then move the binaries: install -m 755 monero-x86_64-linux-gnu-v0.18.4.2/monero* /usr/local/bin/. This places monerod, monero-wallet-cli, and monero-wallet-rpc on your PATH.
4. Write the configuration file. Create /etc/monero/monerod.conf with the following minimum content: data-dir=/var/lib/monero/blockchain, log-file=/var/log/monero/monerod.log, log-level=0, prune-blockchain=1, sync-pruned-blocks=1, rpc-bind-ip=127.0.0.1, rpc-bind-port=18081, p2p-bind-port=18080, out-peers=32, in-peers=64, limit-rate-up=1048576, no-igd=1, enable-dns-blocklist=1. The sync-pruned-blocks=1 flag is critical: without it, monerod downloads the full chain and prunes locally, which wastes both bandwidth and time.
5. Create the systemd unit. Save the following as /etc/systemd/system/monerod.service: a single [Unit] block with Description=Monero Full Node (pruned) and After=network-online.target; a [Service] block with User=monero, Group=monero, Type=simple, ExecStart=/usr/local/bin/monerod --config-file=/etc/monero/monerod.conf --non-interactive, Restart=on-failure, RestartSec=30, MemoryHigh=3G, and MemoryMax=5G; and a [Install] block with WantedBy=multi-user.target.
6. Enable and start the service. Run systemctl daemon-reload, then systemctl enable --now monerod. Monitor progress with journalctl -u monerod -f or by tailing the log file directly. Initial sync of a pruned node from scratch on a 1 Gbps residential line typically completes in 6–10 hours; on a Pi 5 with NVMe expect 14–20 hours because verification, not download, is the bottleneck.
7. Open the P2P port, not the RPC port. If you want inbound peer connections (which helps the network and improves your own peer diversity), open TCP 18080 on your router or firewall. Never expose 18081 to the public internet — that is your wallet's RPC endpoint and should remain bound to localhost. If you need remote wallet access, tunnel it through SSH or Tor, never through a raw port forward.
8. Point your wallet at the local daemon. In the official GUI wallet, choose "Connect to a local node" and use 127.0.0.1:18081. In CLI, pass --daemon-address=127.0.0.1:18081 to monero-wallet-cli. In Feather Wallet, the local node toggle is in Settings → Node, and Cake Wallet on desktop supports it through Settings → Privacy → Custom node.

Never run monerod with --restricted-rpc=0 on a public interface. Within forty-eight hours of being indexed by Shodan, an unrestricted RPC endpoint will be hammered by mining-pool scrapers, wallet-scanning bots, and worse. Localhost-only binding is the default for a reason.

Adapting the Setup for Other Platforms

Raspberry Pi 5 with NVMe

The configuration above works essentially unchanged on a Pi 5. The two adjustments worth making: set db-sync-mode=fast:async:250000000 in monerod.conf to reduce write amplification on the NVMe (default is safe but slower), and consider lowering out-peers to 16 and in-peers to 32 if you are on a domestic connection that throttles on sustained upload. The Pi 5's quad Cortex-A76 verifies blocks at roughly 0.6× the speed of a modern desktop, so initial sync takes longer, but steady-state operation tracks the chain tip without issue.

macOS

Install via Homebrew with brew install monero, which puts monerod at /opt/homebrew/bin/monerod on Apple Silicon. Use a launchd plist in ~/Library/LaunchAgents/io.getmonero.monerod.plist instead of systemd. The same config file content applies — just point data-dir at somewhere under your home directory, such as ~/Library/Application Support/monero. macOS firewall prompts will appear on first run; allow inbound on the P2P port if you want to serve peers.

Windows 11

Download the Windows 64-bit installer from getmonero.org, run it, and let it create the data directory under C:\ProgramData\bitmonero. To run monerod as a service rather than a foreground process, use NSSM (the Non-Sucking Service Manager) and point it at monerod.exe with the same --config-file argument. Windows Defender occasionally flags monerod for "coin mining" — it does not mine, but the heuristic is dumb, so add an exclusion for the binary directory.

Maintenance, Monitoring, and Recovery

A correctly configured pruned node is close to set-and-forget, but three operational habits prevent 90% of pain.

First, check disk space monthly. The pruned chain grows roughly 4–6 GB per month at current transaction volumes, and an unexpected fill can corrupt LMDB in ugly ways. Set a simple monit or systemd timer that alerts when /var/lib/monero drops below 15 GB free.

Second, keep monerod updated. Network upgrades (hard forks) happen roughly every 6–9 months, and a node running the previous protocol version stops accepting blocks the moment the fork activates. The Monero release schedule is published on the GitHub releases page and announced on r/Monero and the official mailing list typically four to six weeks ahead. Update at least two weeks before the fork height to give yourself a margin.

Third, know how to resync. If LMDB ever throws "MDB_CORRUPTED" or the daemon refuses to start after a power loss, the recovery is brutal but reliable: stop the service, delete the contents of /var/lib/monero/blockchain, and restart. The node will resync from scratch in 6–12 hours. There is no incremental repair tool because LMDB does not have one; a clean resync is the canonical fix and it has worked since 2017.

For a real-world example: a contributor to the MoneroSwapper backend runs a fleet of seven pruned nodes across three countries to provide diversified daemon endpoints for our anonymous swap service. Each node is provisioned identically — Debian 12, the systemd unit shown above, NVMe storage, and Tor hidden-service exposure for the P2P port. In thirty-eight months of cumulative uptime across the fleet, the only intervention required has been three resyncs after unscheduled datacenter reboots and the standard fork-day binary swap. That is the steady state you should expect from a properly hardened deployment.

FAQ

Can I convert an existing full node into a pruned one without resyncing?

Yes. Stop monerod, run monerod --prune-blockchain as a one-shot command (not as a service), and wait. The pruning operation takes 30–90 minutes depending on disk speed and rewrites the database in place. When it finishes, restart your service with the pruned configuration. No data loss, no resync, but make a backup of the wallet keys first as a precaution — never the blockchain itself, which is reproducible from any peer.

Will a pruned node work for mining or for running a Monero merchant gateway?

For solo mining or pool mining, yes — the miner only needs the chain tip, not historical ring signatures. P2Pool also works with a pruned node and is in fact the recommended pairing for self-sovereign solo-style mining since 2023. For a merchant gateway processing incoming payments via monero-wallet-rpc, a pruned node is equally fine. The only roles that require an archival node are block explorers and academic chain analysis tooling.

Does a pruned node hurt my own wallet's privacy?

No. Wallet scans use the output index and key image database, both of which are kept in full on a pruned node. The data that gets discarded — historical ring signatures — does not factor into your wallet's view-key scanning or into any decoy selection done by your wallet when constructing a new transaction. From the wallet's perspective the local daemon is indistinguishable from an archival one, and it is dramatically more private than any remote node regardless of how trustworthy that remote operator claims to be.

How does pruning interact with FCMP++ now that membership proofs are live?

The November 2025 hard fork introduced full chain membership proofs alongside the existing ring signature scheme, and pruning treats both consistently: it keeps every proof and every key image required to validate the chain, and discards only the redundant ring signature payload bytes that older transactions still carry. Post-FCMP++ transactions are slightly smaller than legacy CLSAG transactions, so the pruning ratio is actually marginally more favorable on recent blocks than on historical ones.

Can I run a pruned node entirely over Tor?

Yes, and this is a common deployment for users who want both disk efficiency and network-level privacy. Add tx-proxy=tor,127.0.0.1:9050,32 and anonymous-inbound=YOURONIONADDRESS.onion,127.0.0.1:18083,16 to monerod.conf, with the matching hidden service configured in /etc/tor/torrc. The initial sync over Tor is slower — 24–48 hours rather than 6–12 — but steady-state operation is fine, and you gain the additional property that none of your transactions or wallet scans ever touch the clearnet.

Conclusion

A pruned Monero node delivers the full privacy and verification guarantees of an archival node at roughly 40% of the disk footprint, which is the difference between "I cannot fit this on my laptop" and "this runs comfortably alongside everything else." The setup is a one-evening project on any modern machine, the maintenance burden is roughly one hour every six months, and the result is a self-sovereign foundation for every Monero transaction you will ever send or receive. Combine a local pruned node with a no-KYC swap service like MoneroSwapper, and you have the full stack: privacy at the protocol layer through RingCT and FCMP++, privacy at the network layer through your own daemon, and privacy at the on-ramp through fixed-rate atomic swaps that never see your identity. The disk space you save is incidental; the operational independence is the real win.