एक बिना किसी सेटअप वाले Nordic VPS से लेकर आपके अपने monerod तक के छह चरण — verified binaries, एक hardened config, full या pruned, SSH, WireGuard या v3 onion से पहुँच योग्य। एक remote node आपका balance नहीं पढ़ सकता, लेकिन वह आपके IP को आपका transaction broadcast करते हुए देख सकता है — यह गाइड ठीक उसी एक gap को बंद करती है। v0.18 line के साथ Debian 12 पर टेस्ट किया गया।
Provision
पहले disk, फिर सख्त करें
सत्यापित करें
पहले Signature, फिर install
कॉन्फ़िगर करें
monerod.conf + systemd
Sync
एक या दो दिन, नज़र रखते हुए
Connect करें
SSH, WireGuard या onion
गुमनाम करें
Tor पर broadcast करें
लगभग हर Monero wallet किसी और के daemon की ओर इशारा करते हुए आता है, क्योंकि विकल्प है एक चौथाई terabyte और दो दिन का इंतज़ार। यह default समझ में आने लायक़ है, और इससे होने वाले privacy नुक़सान का वर्णन अक्सर दोनों दिशाओं में ग़लत तरीक़े से किया जाता है — कुछ लोग सोचते हैं कि remote node उनका balance पढ़ लेता है, कुछ सोचते हैं कि उसे कुछ भी पता नहीं चलता। इस leak की असली शक्ल समझना ही बताएगा कि यह गाइड आपकी एक दोपहर के लायक़ है या नहीं।
यह क्या नहीं कर सकता। यह आपका balance, आपके addresses या आपकी keys नहीं देख सकता। एक Monero wallet किसी node को यह नहीं बताता कि उसे क्या ढूँढना है; वह एक block range में पूरे blocks खींचता है और हर output को स्थानीय रूप से private view key से decrypt करने की कोशिश करता है, जो कभी device से बाहर नहीं जाती। node वही bytes सौंपता है जो वह किसी को भी सौंपता। यह नहीं बता सकता कि इनमें से कौन-से outputs, अगर कोई हों, आपके थे — और यही वह असली architectural फ़र्क़ है जो कहीं और इस्तेमाल होने वाले light-wallet model से इसे अलग करता है, जहाँ server को देखने के लिए addresses सौंपे जाते हैं और इसलिए उसे ठीक-ठीक पता होता है कि वह क्या देख रहा है।
यह क्या कर सकता है। यह उस IP address को देखता है जो जुड़ा। यह उस block range को देखता है जो उस IP ने माँगा, जो यह दायरा तय कर देता है कि उसके पीछे वाला wallet कब बनाया गया था। यह आपके refresh की लय देखता है, जो अपने आप में एक usage pattern है। और जब आप ख़र्च करते हैं, तो बाक़ी network से पहले वही आपसे signed transaction पाता है — इसलिए वह यह दर्ज करने की स्थिति में होता है कि यह transaction इस address से, इसी क्षण, network में दाख़िल हुआ। Monero में बाक़ी सब कुछ ठीक इसी तरह की कड़ी को तोड़ने के लिए बनाया गया है। इसे किसी अजनबी को, मुफ़्त में, एक स्थिर IP के साथ सौंप देना ही वह हिस्सा है जिसे ठीक करने लायक़ है।
और वह क्या कर सकता है, जिसका ज़िक्र कोई नहीं करता। यह झूठ बोल सकता है। कोई hostile या बस ख़राब node एक stale chain tip परोस सकता है जिससे आपका wallet ऐसा payment आया हुआ दिखाए जो हुआ ही नहीं, या उस transaction को relay करने में नाकाम रहे जो आपको लगता है आपने भेजा। इनमें से कुछ भी funds नहीं चुराता — wallet जो decrypt करता है उसे verify करता है — लेकिन यह आपको दुनिया की एक झूठी तस्वीर पर अमल करवा देता है, जो किसी confirmation का इंतज़ार कर रहे व्यापारी के लिए अपने आप में एक तरह का नुक़सान है। जो node आप ख़ुद चलाते हैं, उसके जवाबों को तौलना नहीं पड़ता।
| क्या expose होता है | Public remote node | आपका node, clear net | आपका node, Tor पर |
|---|---|---|---|
| आपका balance और addresses | कभी नहीं | कभी नहीं | कभी नहीं |
| आपका IP, node operator के पास | हाँ — एक अजनबी | हाँ — आप | नहीं |
| Wallet creation window | हाँ — एक अजनबी | हाँ — आप | हाँ — आप |
| IP ↔ आपका outgoing transaction | हाँ — एक अजनबी | आपके server का IP, उसके peers के पास | tx proxy से टूटा हुआ |
| आपको एक झूठा chain tip परोस सकता है | हां | नहीं | नहीं |
"Wallet creation window" आपके अपने node पर आपको दिखता रहता है, क्योंकि request तब भी होता है — बस वह किसी और को दिखना बंद हो जाता है। इस पूरी कवायद का उद्देश्य यही है: metadata को ग़ायब करना नहीं, बल्कि सिर्फ़ आपको उसे थामने वाला इकलौता पक्ष बनाना।
एक pruned Monero node पुराने blocks के ring-signature data का आठवाँ हिस्सा रखता है और बाक़ी फेंक देता है। यह फिर भी हर block को ख़ुद download और verify करता है — pruning भरोसा करना नहीं, बल्कि जाँचने के बाद भूल जाना है — और यह वह सब कुछ पूरा रखता है जो कोई wallet माँगे या कोई दूसरा pruned peer माँगे। बचत disk का क़रीब दो-तिहाई हिस्सा है। जिस node का काम सिर्फ़ आपके अपने wallets को सँभालना है, उसके लिए आपको कभी कोई फ़र्क़ महसूस नहीं होगा।
full node के पक्ष में दलील संकरी है, पर सच्ची है: सिर्फ़ एक full node ही किसी बिल्कुल नए node को वह पूरा ऐतिहासिक data दे सकता है जो उसे शुरू से chain verify करने के लिए चाहिए, इसलिए पूरी तरह pruned nodes से बना network काम नहीं करेगा। अगर आपके पास disk है, तो full चलाना एक योगदान है। अगर नहीं है, तो pruned चलाना भागीदारी का कमतर रूप नहीं है — यही वह configuration है जो ज़्यादातर self-hosters को चुननी चाहिए।
daemon शुरू करने से पहले तय कर लें। पहली बार चलाते समय --prune-blockchain देना sync के साथ-साथ prune कर देता है, जो तेज़ और मुफ़्त है। बाद में एक full database को बदलना पड़े तो daemon रोकना होगा और उस पर अलग से monero-blockchain-prune tool चलाना होगा, जिसमें घंटों लगते हैं और काम करने के लिए खाली जगह चाहिए होती है। शुरुआत में इसे सही करने की क़ीमत है config file में एक लाइन; इसे ग़लत करने की क़ीमत है एक पूरी शाम।
| स्वरूप | Disk, mid-2026 | फ़िट बैठने वाला Tier | इसे चुनें जब |
|---|---|---|---|
| Pruned · तंग | ~90 GB | Sentinel · 2 vCPU / 4 GB / 120 GB · $3.90 | आपको सबसे सस्ता चलने लायक़ node चाहिए और disk पर दोबारा लौटना मंज़ूर है |
| Pruned · आरामदायक | ~90 GB | Garrison · 4 vCPU / 8 GB / 240 GB · $7.90 | default सुझाव — वर्षों की गुंजाइश, warm database cache |
| पूर्ण | 240 GB+ | Ravelin · 8 vCPU / 16 GB / 480 GB · $16.90 | आपको एक archival copy चाहिए, या नए nodes को उनका initial sync परोसना है |
| Full + public सेवा | 240 GB+ | Bulwark · 16 vCPU / 32 GB / 960 GB · $32.90 | आपका इरादा असली peer traffic ढोने का है — यहाँ unmetered bandwidth मायने रखता है |
chain का size mid-2026 के लिए एक अनुमान है और यह सिर्फ़ एक दिशा में बढ़ता है। किसी tier को चुनने से पहले मौजूदा आँकड़ा verify करें — हर NordBastion plan में unmetered bandwidth मिलता है, और खुले peer slots वाला node असल में यही खपत करता है।
एक चीज़ जो इस table में नहीं है: RAM। daemon ख़ुद बहुत मामूली है, और 4 GB सचमुच एक node चला देती है। अतिरिक्त memory जो ख़रीदती है वह है database के आगे page cache, जिसका असर initial sync के दौरान और wallet के पहले पूरे rescan के दौरान महसूस होता है, न कि रोज़मर्रा के operation में। अगर एक ही budget में आप ज़्यादा RAM और ज़्यादा NVMe के बीच चुन रहे हैं, तो NVMe लें — और फ़ैसला लेने से पहले tier list पर एक नज़र डाल लें।
panel में: Order → VPS → pruned node के लिए Garrison, पूरी chain चाहिए तो Ravelin, image Debian 12। account खोलने के लिए कोई email address नहीं चाहिए, किसी भी पड़ाव पर कोई पहचान दस्तावेज़ नहीं माँगा जाता, और invoice Monero में चुकता होता है — जो एक सुखद समरूपता है, और साथ ही हमारी जानकारी में wallet से चलते हुए server तक का सबसे छोटा रास्ता भी। bastion को अपने-आप से latency के हिसाब से चुनें, network से नहीं: peer connections asynchronous होते हैं और उन्हें फ़र्क़ नहीं पड़ता, लेकिन आपके wallet के refresh को पड़ेगा।
फिर पहला घंटा दीवार पर ख़र्च करें। एक Monero node स्वभाव से एक public service है — यह P2P port पर सुनता है और अजनबियों से बात करता है — इसलिए baseline वैकल्पिक नहीं है: किसी non-default port पर सिर्फ़-key वाला SSH, default से मना करने वाला एक firewall, unattended security upgrades, fail2ban। first-hour hardening चेकलिस्ट इसकी साथी कड़ी है, और daemon के अस्तित्व में आने से पहले इसे शुरू से आख़िर तक चला लेना ही सही है।
इस node के लिए firewall का स्वरूप असामान्य रूप से सादा है। बाहर से ठीक दो चीज़ें पहुँच योग्य होनी चाहिए: आपका SSH port, और Monero का P2P port। और कुछ नहीं — ख़ासकर RPC port नहीं, जिस तक चरण 05 इसके बजाय एक tunnel से पहुँचता है।
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
एक चौथाई terabyte उस पर sync करने से पहले पक्का कर लें कि आपको असल में कितना disk मिला है, क्योंकि initial sync के चालीस घंटे बाद कमी का पता चलना एक ख़ास तरह का अप्रिय अनुभव है:
df -h /
# → the "Avail" column is your real budget, not the tier name
आप एक ऐसा program install करने जा रहे हैं जो वह network view रखेगा जिस पर आपके wallets भरोसा करते हैं। एक छेड़छाड़ किया गया monerod किसी wallet से झूठ बोलने के लिए सबसे मुफ़ीद जगह है, इसलिए यहाँ verification वाला क़दम कोई रस्म नहीं है — यही वजह है कि Monero project एक signed hashes file प्रकाशित करता ही है। इसे एक बार, ठीक से करें।
आधिकारिक download page से Linux x86-64 CLI archive और signed hashes file लें, साथ ही वहाँ प्रकाशित maintainer की public key भी। यह key किसी forum post में मिले third-party keyserver mirror से न लें — इसे project से लें, TLS पर, उसी page से जो इसका नाम लेता है।
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.
signature verify होने के बाद ही checksum का कोई मतलब बनता है। जो archive आपने download किया है उसे hash करें और वही exact string उस file में ढूँढें जिसे आपने अभी verify किया:
sha256sum linux64
grep -F "$(sha256sum linux64 | cut -d' ' -f1)" hashes.txt
# → one matching line. No output means no match: do not install it.
फिर आपको चाहिए दोनों binaries unpack करके सही जगह रखें। archive के भीतर एक versioned directory होती है; monerod वह daemon है और monero-blockchain-prune वह offline tool है जिसके होने की आपको ख़ुशी होगी अगर आपने कभी pruning को लेकर अपना मन बदला।
tar -xjf linux64
cd monero-x86_64-linux-gnu-*/
install -m 0755 monerod monero-blockchain-prune /usr/local/bin/
monerod --version
वह command जो version string print करता है उसे कहीं ऐसी जगह pin कर लें जहाँ आप उसे दोबारा ढूँढ सकें। जब कोई network upgrade घोषित हो तो आप ठीक-ठीक जानना चाहेंगे कि आप किस version से upgrade कर रहे हैं, और "latest" कोई जवाब नहीं है।
daemon को उसका अपना unprivileged user और अपनी directory दें। एक बार चलने के बाद Monero node को कहीं भी root की ज़रूरत नहीं होती, और जो service दिन भर खुले internet से बात करती है, वही असल में वह service है जिसे आप 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 — वही options जो monerod command line पर लेता है, बिना आगे वाले dashes के लिखे हुए। अगर आपने full node तय किया है तो prune-blockchain वाली लाइन हटा दें; यही इकलौती लाइन है जो अपरिवर्तनीय है।
# ── 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
दो RPC listeners ही वह हिस्सा हैं जिन्हें समझना ज़रूरी है। Port 18081 हर चीज़ का जवाब देता है, administrative calls समेत, और यह वहीं loopback से बँधा है जहाँ इसे होना चाहिए। Port 18089 restricted interface है: सिर्फ़ view-only calls, कोई privacy-sensitive internals नहीं, और यही वह चीज़ है जो network पर हर public node उजागर करता है। यहाँ दोनों जान-बूझकर 127.0.0.1 पर हैं — चरण 05 इसे खोलने के बजाय एक tunnel के ज़रिए 18089 तक पहुँचता है।
/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 और TimeoutStopSec सजावट नहीं हैं। database साफ़-सुथरे तरीक़े से बंद होना चाहता है, और किसी write के बीचोंबीच ज़बरदस्ती मार दिया गया daemon वापस आने पर या तो repair माँगता है — या फिर एक resync। SIGINT उसे ठीक से बंद होने के लिए कहता है, और पाँच मिनट वह मोहलत है जो उसे काम पूरा करने देती है। जो भी गाइड इन दो लाइनों को छोड़ देती है, वह बस एक बदक़िस्मत reboot की दूरी पर है एक बर्बाद weekend से।
systemctl daemon-reload
systemctl enable --now monerod
systemctl status monerod --no-pager
daemon अब genesis block से chain पर चल रहा है, हर मिलने वाले ring signature और हर range proof की जाँच कर रहा है। कुछ cores वाले NVMe पर यह एक या दो दिन का काम है; यह bandwidth से नहीं बल्कि CPU और disk से बंधा है, इसलिए एक तेज़ uplink इसे छोटा नहीं करेगा। यही काम असली product है। जो node इसे छोड़ देता, वह बस किसी और पर भरोसा करने का एक धीमा तरीक़ा भर होता।
इसे एक दूसरी shell से देखें। status line आपको height, peer count और अनुमानित बचा हुआ समय बताती है, और ज़्यादातर nodes को बस इतनी ही monitoring चाहिए होती है:
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
डाउनलोड किया गया blockchain import न करें। internet पर ऐसे archives मौजूद हैं जो इंतज़ार छोड़ने का वादा करते हैं, और इनमें से किसी एक को import करना आपके verify किए हुए node को ऐसे node में बदल देता है जो किसी अजनबी द्वारा दी गई एक file पर भरोसा करता है। यह उसी एक चीज़ को हरा देता है जिसके लिए आप यहाँ आए थे। अगर sync का समय सचमुच नामुमकिन लगे, तो ईमानदार हल है ज़्यादा cores वाला box, न कि verification को दरकिनार करने का शॉर्टकट।
bootstrap-daemon का trap। monerod अपने ही sync के पूरा होने का इंतज़ार करते हुए भी किसी public node से wallet queries का जवाब दे सकता है, जो एक ऐसी सुविधा है जिसकी धार तेज़ है: जब तक यह सक्रिय है, आपका wallet traffic ठीक उसी तरह के third party से सर्व हो रहा होता है जिसे हटाने के लिए यह गाइड मौजूद है। अगर आप पहले घंटे में काम चलाने के लिए इसे enable करते हैं, तो calendar में एक reminder लगा दें और जिस पल आपकी अपनी height tip तक पहुँचे, इसे बंद कर दें। एक अस्थायी समझौता जिसे बंद करना किसी को याद ही नहीं रहता, वह बस पुराने setup का नया नाम भर है।
जब height हिलना बंद कर दे और आपके भरोसे वाले किसी block explorer से मेल खाने लगे, तो node live है। इस बिंदु से daemon आपको रोज़ बस कुछ gigabytes traffic, थोड़ा-सा CPU ख़र्च करवाता है, और upgrades के अलावा किसी और ध्यान की ज़रूरत नहीं होती।
restricted RPC interface loopback से बँधा है, जिसका मतलब है कि अभी इसे कोई नहीं पहुँच सकता। यही सही default है, और इस चरण का बाक़ी हिस्सा इस बारे में है कि उस gap को कैसे पार किया जाए। एक चुनें — ये आपस में मिलकर ठीक से काम नहीं करते, और आपको बस एक की ज़रूरत है।
Option A · SSH tunnel — एक मशीन, शून्य setup। अगर आप एक ही laptop इस्तेमाल करते हैं, तो यह सही जवाब है। न कुछ नया install होता है, न कुछ नया सुनना शुरू करता है, और session ख़त्म होते ही tunnel भी ख़त्म हो जाता है। इसके बाद आपका wallet 127.0.0.1:18089 की ओर इस तरह इशारा करता है जैसे node स्थानीय हो।
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 — कई devices, हमेशा on। फ़ोन plus desktop plus laptop के लिए सही जवाब। node आपके private network से जुड़ जाता है और wallets उसे उसके tunnel IP से address करते हैं, बिना internet पर कोई भी port खोले। WireGuard गाइड tunnel बनाती है; यहाँ बस इतना अतिरिक्त क़दम है कि daemon को उस पर जवाब देने दें।
# 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 — कहीं से भी, कोई port नहीं, कोई स्थिर IP नहीं। अगर आप यात्रा करते हैं, या node को बिना कहीं भी inbound port के पहुँच योग्य रखना चाहते हैं, तो यह सही जवाब है। Tor ख़ुद service publish करता है; न कुछ forward करना है, न कुछ scan करना है। hidden-service गाइड पूरा torrc बताती है; node से जुड़ा हिस्सा बस तीन लाइनों का है।
# /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
आपने चाहे जो भी दरवाज़ा बनाया हो, wallet वाला पक्ष हमेशा वही तीन fields हैं। Feather में: Settings → Node → एक custom node जोड़ें, host और port, और अगर आपने onion चुना है तो Tor proxy enable करें। आधिकारिक Monero GUI में: Settings → Node → Remote node, जिसमें "connect to a remote node" चुना हो। Cake Wallet में: Settings → Nodes → add node, जो एक onion address सीधे स्वीकार करता है। अगर आपने RPC interface पर username और password सेट किया है, तो तीनों में इसके लिए fields मौजूद हैं।
फिर जाँच लें कि यह काम कर गया। wallet को आपके node जितनी ही height दिखानी चाहिए, और node को एक RPC client ज़्यादा दिखाना चाहिए। अगर wallet अब भी ठीक एक सेकंड में refresh हो जाता है, तो वह शायद अब भी default public node से बात कर रहा है — ज़्यादातर wallets पुराने वाले को list में रखे रहते हैं और चुपचाप उसी पर वापस चले जाते हैं।
आपका wallet अब transactions किसी अजनबी को नहीं सौंपता — वह उन्हें आपके अपने daemon को सौंपता है। लेकिन वह daemon फिर उन्हें आपके server के IP address से अपने peers को घोषित करता है, और peers नोट्स रखते हैं। Monero पहले ही किसी नए transaction को फैलने से पहले एक randomised relay phase से गुज़ारता है, जिससे पहला hop पहचानना मुश्किल हो जाता है; इसके बजाय इसे Tor पर भेज देना इस सवाल को पूरी तरह मिटा देता है।
एक लाइन ही काफ़ी है। daemon clear net पर blocks sync करता रहता है — यही sync को तेज़ रखता है — और सिर्फ़ आपके outgoing transaction broadcasts को स्थानीय Tor SOCKS port से route करता है:
# in /etc/monerod.conf, with tor running locally
tx-proxy=tor,127.0.0.1:9050,16
अगर आप और आगे जाकर Tor पर भी peers स्वीकार करना चाहते हैं, तो P2P पक्ष के लिए एक दूसरी hidden service publish करें और daemon को बताएँ कि कौन-सा onion address advertise करना है। port number आपकी मर्ज़ी है, बस दोनों हिस्से आपस में सहमत हों और box पर पहले से कोई और चीज़ उसे इस्तेमाल न कर रही हो:
# /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
वह चरण आपसे ज़्यादा network की मदद करता है, जो इसे अपनाने की एक पूरी तरह वाजिब वजह है। इसमें थोड़ी latency और कुछ peer slots की क़ीमत चुकानी पड़ती है, और इसका मतलब है कि सिर्फ़-Tor nodes के पास जुड़ने के लिए कोई जगह होती है।
वैकल्पिक रूप से: एक public node दान करें। अगर आपके पास bandwidth और disk दोनों हैं, तो आप अपना restricted RPC endpoint advertise कर सकते हैं ताकि दूसरे लोगों के wallets उसे इस्तेमाल कर सकें। यह उस network के लिए एक सच्चा योगदान है जिसका सबसे कमज़ोर पक्ष यही है कि कितने कम लोग अपना daemon ख़ुद चलाते हैं — और इसके साथ किसी भी public service की ज़िम्मेदारियाँ भी आती हैं: आप दूसरों का traffic ढोएँगे, और एक node operator के तौर पर दिखेंगे। यहाँ हर plan में unmetered bandwidth मिलता है, इसलिए इनमें से पहली बात बिल का नहीं, बस एक फ़ैसले का मामला है।
# 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
एक node को दूसरे self-hosted infrastructure के साथ रखना भी अच्छा विचार है — मसलन, एक Lightning node उसी rack में। अगर budget इजाज़त दे तो इन्हें अलग-अलग boxes पर रखें: दोनों की uptime ज़रूरतें अलग हैं और recovery की कहानियाँ भी बिल्कुल अलग हैं।
daemon रुक जाता है, और दोबारा खुलने से पहले database को शायद एक repair pass की ज़रूरत पड़े। sync के दौरान रोज़ ख़ाली जगह जाँचें और tier का size आज की नहीं, तीन साल बाद वाली chain के हिसाब से रखें।
Port 18081 administrative calls का जवाब देता है। यह हमेशा के लिए 127.0.0.1 पर ही रहता है। अगर बाहर की किसी चीज़ को node तक पहुँचना ही है, तो वह एक tunnel के ज़रिए 18089 पर मौजूद restricted listener तक पहुँचती है।
अपने node को list में जोड़ देने भर से वह चुना नहीं जाता, और ज़्यादातर wallets जब node तक नहीं पहुँच पातीं तो चुपचाप वापस पुराने node पर चली जाती हैं। heights की तुलना करें, और पुष्टि करें कि node एक connected RPC client रिपोर्ट कर रहा है।
इसे बाद में जोड़ने से मौजूदा database छोटा नहीं होता। बदलने के लिए daemon को रोकना और monero-blockchain-prune चलाना पड़ता है, जिसमें घंटों का समय और काम करने की जगह चाहिए। पहली शुरुआत से पहले ही तय कर लें।
एक network upgrade आया और daemon कभी update नहीं हुआ। यह चिल्लाकर नहीं बताता — height बस reality से मेल खाना बंद कर देती है। release announcements पर नज़र रखें और fork height से पहले upgrade कर लें।
किसी write के बीचोंबीच SIGKILL, आमतौर पर बिना KillSignal और छोटे stop timeout वाली किसी systemd unit से। SIGINT इस्तेमाल करें और इसे पाँच मिनट दें, और daemon को अपना database ख़ुद बंद करने दें।
दस प्रश्न जो किसी wallet को अपने ख़ुद के चलाए daemon पर ले जाने से पहले, उसके दौरान और बाद में उठते हैं।
नहीं। Monero wallets client-side scan करते हैं: wallet node से blocks की एक range माँगता है, उन्हें पूरा download करता है, और हर output को स्थानीय रूप से आपकी private view key से decrypt करने की कोशिश करता है। node को कभी आपकी view key, आपकी spend key या आपका address नहीं मिलता, और यह नहीं बता सकता कि अभी सौंपे गए outputs में से कौन-से आपके हैं। यह Bitcoin के light wallets से एक असली architectural फ़र्क़ है, जहाँ server को आमतौर पर बताया जाता है कि किन addresses या scripts पर नज़र रखनी है। एक remote node जो सीखता है वह है network layer: आपका IP address, यह तथ्य कि उस IP पर कोई wallet sync हो रहा है, वह block range जो उसने माँगा — जो आपके wallet की restore height का दायरा बताता है — और, सबसे अहम, कोई भी transaction जो आप उसे broadcast करने के लिए सौंपते हैं। बंद करने लायक़ leak यही आख़िरी वाला है।
जब तक कोई ठोस वजह न हो, pruned चलाएँ। एक pruned node पुराने blocks के ring-signature data का आठ में से सात हिस्सा फेंक देता है, वह सब कुछ रखता है जो किसी wallet या नए peer को आपसे असल में चाहिए, फिर भी पूरी chain ख़ुद validate करता है, और एक full node के disk का लगभग एक-तिहाई हिस्सा घेरता है। एक निजी wallet backend के लिए व्यवहार में कोई फ़र्क़ नज़र नहीं आता। full node तब चलाएँ जब आप किसी नए node को शुरू से अपना initial sync करने में मदद देना चाहते हों, जब आप block-explorer जैसा tooling चलाते हों जो मनमाना ऐतिहासिक transaction data पढ़ता है, या जब आपको बस एक पूरी archival copy चाहिए। पहले sync से पहले तय कर लें: --prune-blockchain sync के साथ-साथ prune करता है, जबकि पहले से sync हो चुके एक full database को बदलने के लिए daemon रोकना और उस पर अलग से monero-blockchain-prune tool चलाना पड़ता है।
mid-2026 में एक full node 240 GB से ऊपर है और हर साल दसियों gigabytes की दर से बढ़ता है, इसलिए disk का size उस chain के हिसाब से तय करें जो तीन साल बाद आपके पास होगी, आज वाली के हिसाब से नहीं। एक pruned node मोटे तौर पर उसका एक-तिहाई है — अभी के लिए इसे 85 से 95 GB मान लें। व्यवहार में इसका मतलब है कि एक Garrison (240 GB NVMe) pruned node के लिए वर्षों की गुंजाइश के साथ आरामदायक घर है, और एक Ravelin (480 GB) full node के लिए सही box है। 120 GB वाला एक Sentinel आज एक pruned node को समा लेगा, लेकिन आपकी पसंद से जल्दी आपको इस पर दोबारा सोचने पर मजबूर कर देगा। disk ख़रीदने से पहले मौजूदा chain size जाँच लें — इस गाइड में यही एक आँकड़ा है जिसका पुराना पड़ जाना तय है।
पहले sync के लिए NVMe पर एक या दो दिन लगते हैं, और यह आपके connection से नहीं बल्कि CPU और disk से बंधा होता है। daemon genesis block से आगे हर ring signature और हर range proof को सत्यापित कर रहा होता है; यही असली काम है, और यही वजह है कि node चलाना सार्थक है। दो चीज़ें इसे बहुत बुरा बना देती हैं: NVMe की जगह घूमने वाली hard disk, जो दो दिन को एक हफ़्ते में बदल सकती है, और आधे रास्ते में disk का ख़त्म हो जाना। दो चीज़ें जो लोगों की उम्मीद जितनी मदद नहीं करतीं: ज़्यादा bandwidth, और database के pages को warm रखने से ज़्यादा RAM। समय बचाने के लिए किसी तीसरे पक्ष से डाउनलोड किया गया blockchain archive import न करें — ऐसा करने पर आप ठीक उसी पक्ष पर भरोसा कर रहे होंगे जिस पर भरोसा करना आप बंद करना चाहते थे।
unrestricted वाला कभी नहीं। unrestricted RPC interface administrative calls को expose करता है, और उसे node के पूरे जीवनकाल तक 127.0.0.1 से बँधा रहना चाहिए। restricted interface एक अलग चीज़ है: यह सिर्फ़ वे view-only calls जवाब देता है जिनकी किसी wallet को ज़रूरत होती है, और यही वह चीज़ है जो network पर हर public node उजागर करता है। फिर भी, इसे किसी clear-net port पर publish करना हर उस व्यक्ति को "यहाँ एक Monero user है" का ऐलान कर देता है जो address space scan कर रहा हो। इस गाइड में पसंद का क्रम है: पहले एक v3 onion service, दूसरे नंबर पर एक WireGuard tunnel, तीसरे नंबर पर अकेली मशीन के लिए एक SSH tunnel, और एक खुला public port सिर्फ़ तभी जब आपने जान-बूझकर network को एक public node दान करने का फ़ैसला किया हो।
एक node न कोई key रखता है, न किसी funds का custody करता है, और न किसी का पैसा हिला सकता है। यह सिर्फ़ blocks को validate करता है और उन transactions को relay करता है जिन पर दूसरे लोग पहले ही sign कर चुके हैं — बिल्कुल उस mail relay जैसी स्थिति जो ऐसे संदेश ढोता है जिन्हें वह पढ़ नहीं सकता। यह तकनीकी हक़ीक़त है; क़ानूनी हक़ीक़त jurisdiction पर निर्भर करती है, और यह गाइड क़ानूनी सलाह नहीं है। jurisdiction जो चीज़ बदलती है वह यह है कि किससे क्या करवाया जा सकता है: चार Nordic jurisdictions पर बनी गाइड उन क़ानूनों को विस्तार से बताती है जो स्टॉकहोम, हेलसिंकी, ओस्लो या रेक्जाविक में बैठे किसी server पर लागू होते हैं।
सिर्फ़ तभी जब आप इसे update करें। Monero तय समय पर network upgrades करता है, और पुराने consensus rule set पर चल रहा daemon fork height पर main chain का पीछा करना बंद कर देता है — यह आपको ज़ोर से चेतावनी नहीं देता, बस रुक जाता है या अलग हो जाता है, और आपका wallet चुपचाप एक ऐसी height रिपोर्ट करता रहता है जो अब reality से मेल नहीं खाती। release announcements को subscribe करें, कोई बदलता हुआ tag ट्रैक करने के बजाय जो version आपने install किया है उसे pin करें, और घोषित upgrade height के लिए calendar में reminder लगा दें। एक self-hosted node के बेकार हो जाने का सबसे आम तरीक़ा यही है: कोई crash नहीं, बस एक ऐसा मालिक जिसने पढ़ना बंद कर दिया।
अपने outbound transaction broadcasts को Tor पर route करें — यह वह इकलौती setting है जिसका privacy फ़ायदा साफ़ और सस्ता है, क्योंकि यह "यह transaction network में दाख़िल हुआ" को "यह IP address मौजूद है" से अलग कर देती है। inbound Tor peers को भी स्वीकार करना एक अतिरिक्त क़दम है जो आपसे ज़्यादा network की मदद करता है, और इसमें थोड़ी latency की क़ीमत चुकानी पड़ती है। पूरे peer traffic को Tor पर route करना ज़्यादा आक्रामक विकल्प है: यह काम करता है, लेकिन आपके initial sync को काफ़ी धीमा कर देगा, इसलिए ज़्यादातर लोग clear net पर sync करते हैं और फिर transaction का रास्ता Tor पर बदल देते हैं। Tor hidden service गाइड torrc वाला पक्ष ज़्यादा गहराई से बताती है।
लगभग हमेशा restore height। बिना restore height वाला, या शून्य पर सेट, wallet हर बार restore होने पर genesis block से पूरी chain को दोबारा scan करता है, जो बेकार में घंटों का local काम है। restore height को उस block पर सेट करें जो wallet बनने के समय मौजूद था। दूसरी वजह है network का रास्ता: किसी दूसरे देश में बैठा wallet जब आपके node से किसी भरे हुए onion circuit के ज़रिए बात करता है तो वह पड़ोस के किसी public node पर चल रहे उसी wallet से धीमा होगा — यही privacy की क़ीमत है, और एक WireGuard tunnel आमतौर पर ज़्यादातर रफ़्तार वापस दिला देता है। तीसरी वजह, जिसे लोग अक्सर चूक जाते हैं, यह है कि आपके node का अपना initial sync अभी पूरा नहीं हुआ और वह अब भी किसी bootstrap daemon से जवाब दे रहा है।
क्योंकि एक node लंबे समय तक जीवित रहने वाली, publicly पहुँच योग्य चीज़ है जिससे होकर आपके transactions गुज़रते हैं। एक full node आपके wallet और किसी अजनबी के node के बीच का leak बंद कर देता है — और फिर एक छोटा leak खोल देता है, आपके node और उस व्यक्ति के बीच जिसने आपको मशीन किराए पर दी। अगर उस मशीन के signup में passport scan और आपके क़ानूनी नाम वाला card शामिल था, तो आपने correlation को हटाया नहीं, बस खिसका दिया है। अपने Monero node को चलाने वाले server के लिए Monero में भुगतान करना कोई नारा नहीं है; यह setup का इकलौता रूप है जहाँ दोनों परतें आपस में मेल खाती हैं। anonymous VPS hosting पर बनी मुख्य गाइड तीनों परतों को शुरू से आख़िर तक समझाती है।
Garrison (4 vCPU, 8 GB, 240 GB NVMe, $7.90/mo) एक pruned node को वर्षों की गुंजाइश के साथ थाम लेता है; Ravelin (480 GB) पूरी chain सँभालता है। हर plan में unmetered bandwidth, signup पर कोई email नहीं, कभी कोई पहचान दस्तावेज़ नहीं।
अंतिम review · 2026-10-12 · स्रोत · getmonero.org की user guides (node चलाना, pruning, Tor और I2P), v0.18 line पर monerod --help, Debian 12 और Tor Project documentation · आवृत्ति · वार्षिक
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.
निजी होस्टिंग, उत्तर में निर्मित।