Self-hosted (run your own)

Self-hosted node is the structural answer that obsoletes the rest of the nodes directory — run your own `monerod` and the entire question of "which remote-node operator should I trust?" disappears. Listed at Grade A · editor's pick because the privacy property a remote node can give you is "trust the operator not to log + correlate"; the privacy property a self-hosted node gives you is "there is no operator." Five minutes of setup on any reasonable VPS or home server, ~24 hours of initial chain sync (or 30 minutes with bootstrap), and you're operating Monero with zero node-operator trust assumptions.

Background. `monerod` is the reference Monero daemon, maintained as part of the official Monero project codebase at github.com/monero-project/monero. The same software that powers every public node — Cake's nodes, Feather's nodes, the monero.fail-listed community nodes — is the software you run on your own hardware. There is no "self-hosted edition" vs "public edition"; they are bit-identical binaries. Documentation lives at docs.getmonero.org/running-node/, with extensive community guides covering Raspberry Pi setups, VPS deployments, Tor/I2P hidden-service configurations, and pruned-vs-archival node decisions.

What you trust. You trust your own infrastructure — the hardware you run on, the network you connect through, the operator that you yourself are. What you don't trust: no public-node operator sees your wallet's queries, no remote infrastructure observes which addresses you care about, no third-party "easy mode" service can be compelled to disclose your activity. The trust circle shrinks to: monerod's code (open source, reviewable, multiple-Cure53-audit history at the Monero protocol level), your hardware (your responsibility), your wallet client (your choice — Feather, Monerujo, Cake Wallet, the official Monero GUI). For users who want the maximum-trust-minimisation posture in the Monero ecosystem, this is the answer.

Operational specs. Hardware floor: 4 GB RAM, 100-150 GB disk for pruned node (~half-size archive of the chain), ~500 GB for full archival node. Any modest VPS, Raspberry Pi 4/5, mini-PC, or NUC suffices. Initial sync: ~24 hours from genesis on consumer hardware over a reasonable internet connection; bootstrap (fast-sync from a trusted source) reduces this to ~30 minutes if you accept a higher initial trust assumption (verify chain integrity post-bootstrap to recover that trust). Network: clearnet, Tor hidden service, or I2P — `monerod` supports all three transports natively. Tor hidden-service setup is documented and straightforward. Configuration: a 10-line `monerod.conf` covers the typical setup; advanced configurations for restricted RPC, public sharing, P2P-bandwidth tuning are documented but optional. Wallet pairing: any Monero wallet that accepts a remote node URL can be pointed at your self-hosted instance via SSH tunnel (`ssh -L 18081:localhost:18081 your-server`) or directly if the node is exposed on a Tor hidden service.

Philosophy. Self-hosting's editorial differentiator is the "no operator in the trust circle" architecture. Every other entry in the nodes section of this directory is structurally `[wallet] → [some operator's node] → [Monero network]` — the operator is a real third party with real observability of the wallet's queries (timing, originating IP unless Tor-routed, which addresses the wallet cares about). Self-hosting collapses that to `[wallet] → [your monerod] → [Monero network]` — the only "operator" is you. The trade-off: operational responsibility moves to you. The chain syncs need to complete; the daemon needs to stay up; the hardware needs to be functional; the security of the host machine matters because it now holds your wallet's RPC endpoint. The classic Monero-community framing is right: "if you're not running your own node, you're running someone else's node" — and that someone else has visibility you can decline to grant by running your own.

Grade rationale. Grade A and editor's pick reflect: structural elimination of node-operator trust (the only credible answer to "what's the strongest privacy posture for remote-node use?"); reference Monero project software (no third-party fork, no separate codebase); modest hardware requirements (commodity VPS or Raspberry Pi suffices); native Tor + I2P transport support; documented Tor hidden-service path; pair-with-any-Monero-wallet flexibility (Feather, Monerujo, Cake, Monero GUI); open-source codebase with multiple security audits at the protocol layer; consistent recommendation in every privacy + Monero infrastructure guide. Last verified 2026-05-13.

Useful when. You're using Monero for anything beyond casual amounts and the threat model includes "operator observability of address queries." You're a journalist / lawyer / researcher / merchant whose wallet activity should not be visible to a third-party node operator. You're already running a homelab and adding `monerod` is a small marginal commitment. You want to *contribute* to the Monero network's distributed-node ecosystem by running a public node that others can use (optional — your node can be private-only). You want to verify that the public Monero infrastructure you previously relied on was telling you the truth (run your own node, compare its view of the chain to what the remote nodes returned). You're operating from a region where remote-node access might be unreliable and want sovereign control over your wallet connectivity.

Caveats. Initial sync takes hours-to-a-day — for users who need a Monero wallet *right now*, start with a remote node and migrate to self-hosted in the background. Bandwidth + storage are ongoing commitments — 500 GB disk for archival is permanent storage; ~5-50 GB/day of network traffic depending on P2P-sharing config. Pruning to ~150 GB disk + restricted RPC reduces the footprint but still meaningful for a small VPS. Security of the host machine matters — your `monerod` instance is exposed via RPC on (typically) port 18081; if the host is compromised, the wallet's view of the chain can be tampered with. SSH-tunnel-only access + firewall everything else is the standard hardening. No background-sync magic — if you turn off your node for two weeks, it'll need to catch up on those two weeks of blocks before your wallet can transact. Tor-hidden-service requires correct setup — running `monerod` over Tor + I2P is documented but non-trivial; misconfiguration can leak your real IP. Follow the canonical guides at docs.getmonero.org. You become the operator — for some users this is empowering, for others it's an unwelcome operational tax. There's no shame in using a vetted remote node from monero.fail if self-hosting genuinely doesn't fit your life; the right answer depends on threat model + operational capacity, not ideology.