[होम](https://servhidden.com/hi) /
[गोपनीयता होस्टिंग Guides](https://servhidden.com/hi/guides) /
खुद का Matrix Server Self-Host करें: Federation, Metadata और E2EE की सीमाएँ






परिचालन


# खुद का Matrix Server Self-Host करना



एक homeserver सिर्फ़ चैट करने वाला निजी डिब्बा नहीं है — यह एक सार्वजनिक नेटवर्क में replication node है। Matrix को self-host करने से असल में क्या ठीक होता है, end-to-end encryption क्या खुला छोड़ देती है, कौन सा implementation चलाएँ, और कौन-से ऑपरेशनल फ़ैसले अपरिवर्तनीय हैं — यह सब यहाँ है।


[गाइड पढ़ें](#guide-body)
[FAQ](#guide-faq)






## इस पेज पर




- [गाइड](#guide-body)

- [FAQ](#guide-faq)

- [संबंधित गाइड्स](#guide-related)

- [सुझाए गए पेज](#guide-cta)






KYC नहीं
केवल क्रिप्टो
लॉग नहीं
DMCA अनदेखा
पूर्ण रूट
NVMe SSD





17 मिनट पढ़ें
Aug 2026 को अपडेट किया

इस पेज पर

[01अपना खुद का homeserver चलाने से असल में क्या बदलता है](#अपन-खद-क-homeserver-चलन-स-असल-म-कय-बदलत-ह)
[02Federation एक replication protocol है जिसने चैट प्रोटोकॉल का चोला पहन रखा है](#federation-एक-replication-protocol-ह-जसन-चट-परटकल-क-चल-पहन-र)
[03Encryption क्या कवर करता है, और क्या साफ़ रह जाता है](#encryption-कय-कवर-करत-ह-और-कय-सफ-रह-जत-ह)
[04Synapse, Dendrite या Conduit — असल में क्या चलाएँ](#synapse-dendrite-य-conduit-असल-म-कय-चलए)
[05वह delegation सेटअप जिसे सब ग़लत करते हैं](#वह-delegation-सटअप-जस-सब-गलत-करत-ह)
[06इसे ईमानदारी से sizing करना](#इस-ईमनदर-स-sizing-करन)
[07Media store एक धीमी रफ़्तार वाला disk बम है](#media-store-एक-धम-रफतर-वल-disk-बम-ह)
[08Registration, spam, और वह प्रतिष्ठा जो आपको विरासत में मिलती है](#registration-spam-और-वह-परतषठ-ज-आपक-वरसत-म-मलत-ह)
[09Bridges, और उनके साथ आने वाला metadata का बिल](#bridges-और-उनक-सथ-आन-वल-metadata-क-बल)
[10इसे ज़िंदा रखना: keys, backups और upgrades](#इस-जद-रखन-keys-backups-और-upgrades)
[11सर्वर कहाँ रहता है, यही अब भी नतीजा तय करता है](#सरवर-कह-रहत-ह-यह-अब-भ-नतज-तय-करत-ह)
[12संक्षिप्त संस्करण](#सकषपत-ससकरण)
[FAQCommon प्रश्न](#guide-faq)
[→सुझाए गए पेज](#guide-cta)







लोग अपनी बातचीत किसी कंपनी के हाथ में जाने से रोकने के लिए Matrix को self-host करते हैं, और यह हिस्सा ठीक वैसे ही काम करता है जैसा दावा किया जाता है। बाद में जो बात उन्हें चौंकाती है वह है उस चीज़ की असली बनावट जो उन्होंने इंस्टॉल की: एक homeserver कोई निजी डिब्बा नहीं है जो संयोग से चैट भी कर लेता है। यह एक सार्वजनिक नेटवर्क में एक replication node है, और federation ज़्यादातर नए एडमिन की उम्मीद से कहीं अधिक एक publishing protocol की तरह बर्ताव करता है।

इसमें से कुछ भी इसे चलाने के ख़िलाफ़ तर्क नहीं है — यह इसे *सोच-समझकर* चलाने के पक्ष में तर्क है। जो प्राइवेसी आपको मिलती है वह असली है पर सीमित है: custody अब आपके पास आ जाती है, कोई और आपका अकाउंट बंद नहीं कर सकता, और कानूनी सवाल उस jurisdiction में पहुँचते हैं जो आपने चुनी है, न कि जो किसी कंपनी ने चुनी थी। जो प्राइवेसी आपको नहीं मिलती वह भी उतनी ही सीमित है, और उसका लगभग पूरा हिस्सा "मैसेज एन्क्रिप्टेड हैं" और "कोई नहीं बता सकता कि कौन किससे बात कर रहा है" के बीच के फ़र्क़ में छिपा है। यह गाइड दोनों पहलू कवर करती है, फिर वे ऑपरेशनल फ़ैसले जो तय करते हैं कि सर्वर एक साल बाद भी स्वस्थ रहेगा या नहीं।

## अपना खुद का homeserver चलाने से असल में क्या बदलता है

सबसे पहले खतरों को अलग-अलग करके देखिए, क्योंकि एक homeserver इनमें से कुछ का पूरी तरह जवाब देता है, कुछ का आंशिक रूप से, और कुछ का बिल्कुल नहीं। नीचे दी गई तालिका इस पूरे प्रस्ताव का ईमानदार संस्करण है, और इसे हार्डवेयर चुनने से पहले पढ़ना बेहतर है, बाद में नहीं।

| आपको किस बात की चिंता है | क्या आपका अपना homeserver इसे ठीक करता है? |
| --- | --- |
| कोई कंपनी आपके मैसेज की सामग्री पढ़ रही हो | प्राइवेट रूम में end-to-end encryption पहले से ही इसे कवर करती है — और हाँ, self-hosting उस कंपनी को भी हटा देती है |
| कोई कंपनी यह प्रोफ़ाइल बना रही हो कि आप किससे और कब बात करते हैं | **आंशिक रूप से।** आप एक केंद्रीय ऑपरेटर को डेटा देना बंद कर देते हैं, और अब वह रिकॉर्ड आपके अपने सर्वर पर रहता है |
| किसी और द्वारा आपका अकाउंट बंद या सस्पेंड कर दिया जाना | **हाँ।** यह पूरी कवायद का सबसे स्पष्ट फ़ायदा है, और सबसे कम चर्चा में रहता है |
| आपके डेटा के लिए कोई कानूनी अनुरोध | **यह गायब नहीं होता, बस जगह बदल देता है।** अब वह अनुरोध आप तक पहुँचता है, उस देश के कानून के तहत जो आपने चुना है |
| किसी और पक्ष का आपका सोशल ग्राफ़ जान लेना | **नहीं।** जिस भी सर्वर का कोई सदस्य उस रूम में है, उसे वही membership डेटा मिलता है जो आपको मिलता है |
| सर्वर के अस्तित्व को ही छुपाना | **नहीं।** Federation को एक सार्वजनिक नाम और एक पहुँच योग्य पोर्ट चाहिए; यह छिपे होने के बिल्कुल उलट है |

आख़िरी दो पंक्तियों को ध्यान से पढ़िए, क्योंकि यहीं पर उम्मीदें टूटती हैं। अगर आपका मक़सद यह है कि किसी सेवा का अस्तित्व ही कोई साबित न कर पाए, तो Matrix ग़लत औज़ार है और एक [onion service](https://servhidden.com/hi/guides/how-to-host-a-tor-hidden-service) उसके ज़्यादा क़रीब है। अगर आपका मक़सद custody, नियंत्रण और jurisdiction है, तो एक homeserver एक बेहतरीन औज़ार है, और इस गाइड का बाक़ी हिस्सा उसे अच्छी तरह चलाने के बारे में है।

एक homeserver एक सार्वजनिक नेटवर्क का participant है, कोई निजी डिब्बा नहीं: आपके रूम में जिस भी सर्वर का कोई सदस्य है, वह अपने पास इसकी अपनी कॉपी रखता है कि कौन कब शामिल हुआ और कितनी बार बोलता है।

## Federation एक replication protocol है जिसने चैट प्रोटोकॉल का चोला पहन रखा है

यही वह तंत्र है जो ज़्यादातर हैरानियों की वजह बताता है। जब आपका कोई यूज़र कहीं और होस्ट किए गए रूम में शामिल होता है, तो आपका सर्वर मेल क्लाइंट की तरह डिमांड पर मैसेज नहीं मंगाता। वह एक distributed event graph में एक participant के रूप में उस रूम में शामिल होता है, फिर रूम के events, उसकी membership, और आगे के events को वैलिडेट करने लायक़ पर्याप्त state history की **एक कॉपी खींचकर उसे स्टोर कर लेता है**। उस पल से आपकी मशीन एक replica रखती है, और हर दूसरा भाग लेने वाला सर्वर भी एक रखता है।

इसके नतीजे दोनों दिशाओं में जाते हैं, और कोई भी सहज-बोध वाला नहीं है। आपके यूज़र जो डेटा बनाते हैं — display name, avatar, joins और leaves, timestamps, reactions — वह उस रूम के हर सदस्य वाले सर्वर पर कॉपी हो जाता है, और आप बाद में अपने यहाँ से जो भी डिलीट करें, वह उनके डेटाबेस में बना रहता है। Redaction साथी सर्वरों को भेजी गई एक गुज़ारिश है, कोई हुक्म नहीं। स्वतंत्र रूप से चलाए जा रहे सर्वरों के federation में कोई "unsend" नहीं होता, और इसकी उम्मीद रखना इस प्रोटोकॉल को लेकर सबसे आम ग़लतफ़हमी है।

दूसरी दिशा में, बड़े पब्लिक रूम में शामिल होने का मतलब है दूसरे लोगों की history को अपनी डिस्क पर इम्पोर्ट करना। यही वजह है कि तीन यूज़र वाला बिल्कुल नया homeserver भी दसियों गीगाबाइट का डेटाबेस ढो सकता है: इसलिए नहीं कि आपके तीन यूज़र ने बहुत कुछ लिखा, बल्कि इसलिए कि वे पचास हज़ार सदस्यों और सालों की state वाले रूम में शामिल हो गए। सोच-समझकर रूम चुनना जितना एक प्राइवेसी का फ़ैसला है, उतना ही एक capacity का फ़ैसला भी है।

## Encryption क्या कवर करता है, और क्या साफ़ रह जाता है

Matrix मैसेज की सामग्री को Megolm से एन्क्रिप्ट करता है, और प्राइवेट रूम में यह डिफ़ॉल्ट रूप से ऑन रहता है। यह उस हिस्से की हिफ़ाज़त करता है जिसकी लोगों को सबसे ज़्यादा फ़िक्र होती है, और यह सचमुच काम करता है — आपका सर्वर सिर्फ़ ciphertext स्टोर करता है जिसे वह पढ़ नहीं सकता, जो एक असली और काम की खूबी है जब सर्वर किराए के हार्डवेयर पर हो। मैसेज के चारों तरफ़ का लिफ़ाफ़ा एक अलग ही कहानी है, और यह फ़र्क़ ज़्यादातर सारांशों के मुक़ाबले कहीं बड़ा है।

| सिग्नल | एन्क्रिप्टेड? | किसे दिखता है |
| --- | --- | --- |
| मैसेज टेक्स्ट और फ़ाइल की सामग्री | **हाँ** | सिर्फ़ रूम के सदस्यों की वेरिफ़ाइड डिवाइसों को |
| रूम में कौन है, और हर join या leave | नहीं | उस रूम में सदस्य रखने वाला हर homeserver |
| Timestamps, मैसेज की फ़्रीक्वेंसी, एक्टिविटी के घंटे | नहीं | भाग लेने वाला हर homeserver |
| Display names, avatars, presence और typing | नहीं | भाग लेने वाला हर homeserver |
| रूम का नाम, topic और avatar | नहीं | भाग लेने वाला हर homeserver |
| अटैचमेंट का साइज़ और ट्रांसफ़र का समय | नहीं | भाग लेने वाला हर homeserver |
| आपके सर्वर का डोमेन और उसका IP एड्रेस | नहीं | पूरा federation — यह जान-बूझकर ऐसा डिज़ाइन किया गया है |

व्यावहारिक मतलब यह है: encryption *क्या* की हिफ़ाज़त करता है, federation *कौन, कब और कितनी बार* को उजागर करता है। ज़्यादातर समुदायों के लिए यह सौदा पूरी तरह स्वीकार्य है, और यही ईमानदारी असल मुद्दा है। जिस threat model में सोशल ग्राफ़ ख़ुद ही संवेदनशील हिस्सा है, उसके लिए एक federated प्रोटोकॉल संरचनात्मक रूप से ग़लत शक्ल है, और कोई भी configuration फ़्लैग इसे नहीं बदलता।

## Synapse, Dendrite या Conduit — असल में क्या चलाएँ

व्यवहार में तीन implementations मायने रखते हैं, और यह चुनाव ज़्यादातर एक resource का फ़ैसला है, न कि कोई दार्शनिक फ़ैसला।

- **Synapse** reference सर्वर है, Python में लिखा गया, और अकेला ऐसा जिसमें हर फ़ीचर पहले ही दिन से काम करता है। यह सबसे ज़्यादा भूखा भी है: आपके यूज़र जिन रूम में शामिल होते हैं उनकी संख्या और साइज़ के साथ memory बढ़ती जाती है, और व्यस्त सर्वर को आख़िरकार worker processes में बाँटना पड़ता है। इसे चुनिए जब आपको spaces, moderation tooling, bridges और admin APIs को ठीक वैसे ही चलते देखना हो जैसा डॉक्युमेंटेशन में लिखा है।

- **Dendrite** इसका Go में लिखा गया संस्करण है। Synapse से साफ़ तौर पर हल्का और एक छोटे सर्वर के लिए पूरी तरह उपयोगी, बस कुछ फ़ीचर देर से आते हैं। जब Synapse आपके असली यूज़र्स की संख्या के लिए भारी लगे, तो यह एक ठीक-ठाक बीच का विकल्प है।

- **Conduit** और इसका सक्रिय रूप से विकसित हो रहा fork conduwuit Rust में लिखे गए हैं और एक embedded database के साथ एक ही binary के रूप में मिलते हैं। ये हमारे सबसे छोटे प्लान पर भी बिना शिकायत एक परिवार या छोटे समुदाय का सर्वर चला लेते हैं। बदले में इनका ecosystem छोटा है: कुछ admin tooling और चंद bridges Synapse को मानकर बनाए गए हैं।

मुट्ठी भर यूज़र वाले पहले सर्वर के लिए, एक छोटे [VPS](https://servhidden.com/hi/vps) पर Conduit-परिवार का सॉफ़्टवेयर काम करने वाली और सस्ती चीज़ पाने का सबसे कम तकलीफ़देह रास्ता है। जिसके बढ़ने की उम्मीद है — एक पब्लिक समुदाय, कोई कंपनी, bridges वाला कोई प्रोजेक्ट — उसके लिए Synapse से शुरू कीजिए और माइग्रेशन को टालिए, क्योंकि बाद में implementations के बीच जाना कोई config बदलाव नहीं बल्कि export-and-rebuild की पूरी कवायद है।

## वह delegation सेटअप जिसे सब ग़लत करते हैं

Matrix आपके user ID में मौजूद नाम को उस मशीन से अलग रखता है जो ट्रैफ़िक परोसती है, और इसे उल्टा समझ लेना self-hosting में सबसे आम और स्थायी ग़लती है। आपका server_name वह डोमेन है जो आपके सर्वर पर हर user ID में कोलन के बाद आता है। पहला event साइन होते ही यह federation में आपकी पहचान का हिस्सा बन जाता है, और मशीन के हर अकाउंट और रूम को छोड़े बिना इसे **बाद में बदला नहीं जा सकता**।

वह सेटअप जो आपको लगभग हमेशा चाहिए होता है: server_name आपका bare डोमेन होता है, जबकि सॉफ़्टवेयर एक सबडोमेन पर चलता है। आप इन दोनों को delegation के ज़रिए जोड़ते हैं, दो तरीक़ों में से किसी एक से। आसान तरीक़ा है bare डोमेन पर /.well-known/matrix/server पर परोसी गई एक स्टैटिक JSON फ़ाइल, जो असली host और port बताती है। दूसरा विकल्प है एक DNS रिकॉर्ड, _matrix._tcp, जो उसी जगह की ओर इशारा करता है। client-side वाली फ़ाइल भी /.well-known/matrix/client पर परोसिए, ताकि ऐप्स सिर्फ़ एक एड्रेस से homeserver ढूँढ सकें।

**कुछ भी इंस्टॉल करने से पहले नाम तय कर लीजिए।** server_name को सबडोमेन पर सेट कर देना सिर्फ़ इसलिए कि सॉफ़्टवेयर वहीं चल रहा है, सबसे क्लासिक ग़लती है, और यह अपरिवर्तनीय है: हर user ID, room ID और साइन किया गया event इसे हमेशा के लिए साथ ले जाता है। वह डोमेन चुनिए जो आप किसी बिज़नेस कार्ड पर छपा देखना चाहेंगे, जहाँ भी प्रोसेस असल में सुन रहा हो वहाँ delegate कीजिए, और दोनों नामों पर वैध TLS बनाए रखिए — delegated host पर एक सर्टिफ़िकेट की ख़राबी federation को गिरा देती है, भले ही ऐप लोकली ठीक दिखे।

## इसे ईमानदारी से sizing करना

सामान्य ऑपरेशन में Matrix CPU-bound नहीं है; यह memory और डेटाबेस के बर्ताव से बंधा है। Synapse के लिए प्रकाशित आँकड़े एक काम के न्यूनतम स्तर हैं: शुरुआत में लगभग 2 GB RAM, दस से पचास एक्टिव यूज़र होने पर लगभग 4 GB, और सौ से ज़्यादा होने पर 8 GB या इससे अधिक। Conduit-परिवार के सर्वर इससे कहीं नीचे रहते हैं। ये आँकड़े जो नहीं बताते वह यह है कि खपत *जॉइन किए गए रूम* के हिसाब से बढ़ती है, न कि रजिस्टर किए गए लोगों के हिसाब से — सौ बड़े पब्लिक रूम में पाँच यूज़र, मुट्ठी भर प्राइवेट रूम में पचास यूज़र से कहीं ज़्यादा महँगे पड़ते हैं।

इससे दो व्यावहारिक नियम निकलते हैं। डेटाबेस को तेज़ स्टोरेज पर रखिए और उसे बढ़ने की जगह दीजिए, क्योंकि write पैटर्न फूटकर नहीं बल्कि छोटा और लगातार होता है। और आज की यूज़र संख्या के हिसाब से sizing मत कीजिए: उन रूम के हिसाब से sizing कीजिए जिनमें ये यूज़र पहले महीने में शामिल होंगे — हैरानी अक्सर वहीं छिपी होती है। हमारा एंट्री प्लान एक छोटे Conduit या Dendrite सर्वर को आराम से संभाल लेता है, जबकि किसी असली समुदाय के लिए Synapse इंस्टेंस को mid-tier प्लान या उससे ऊपर होना चाहिए — [chat hosting पेज](https://servhidden.com/hi/use-cases/matrix-xmpp-hosting) पर इन दोनों तरह के मामलों के लिए हमारी सुझाई हुई टीयर सूची है।

यहाँ uptime ज़्यादातर workloads के मुक़ाबले कहीं ज़्यादा मायने रखता है, क्योंकि जो चैट सर्वर डाउन है वह सिर्फ़ उपलब्ध नहीं है — वह चुपचाप वे events भी खो रहा है जिन्हें साथी सर्वर कुछ देर कोशिश करने के बाद देना बंद कर देंगे। Federation मिनटों को माफ़ कर देता है, दिनों को नहीं।

## Media store एक धीमी रफ़्तार वाला disk बम है

जिस भी रूम में आपके यूज़र मौजूद हैं, उससे गुज़रने वाली हर इमेज, वीडियो और फ़ाइल आपकी डिस्क पर कैश हो सकती है, यहाँ तक कि वह remote media भी जिसे आपके अपने यूज़र ने कभी खोला ही नहीं। Synapse की डिफ़ॉल्ट retention उसे अनिश्चित काल तक रखती है। नतीजा अनुमानित है और फिर भी लोगों को चौंका देता है: एक ऐसा सर्वर जिसका डेटाबेस स्थिर है पर जिसकी media डायरेक्टरी चुपचाप तब तक बढ़ती रहती है जब तक वॉल्यूम भर न जाए, और उस वक़्त लक्षण "डिस्क भर गई" नहीं बल्कि "सर्वर अजीब बर्ताव कर रहा है" होता है।

पहले दिन ही remote media के लिए एक retention policy तय कीजिए, न कि पहली outage के बाद। Synapse homeserver.yaml में retention सेटिंग्स देता है, साथ ही पुरानी history और कैश्ड फ़ाइलें हटाने के लिए admin endpoints भी; synapse-compress-state किसी पुराने सर्वर की state tables से हैरान कर देने वाली मात्रा वापस पा लेता है। डेटाबेस और media पाथ दोनों पर नज़र रखिए, और service के डाउन होने पर नहीं बल्कि खाली जगह पर अलर्ट लगाइए — दूसरा लक्षण पहले के कई दिन बाद आता है।

एक सेटिंग को डिफ़ॉल्ट पर नहीं बल्कि सोच-समझकर तय किए जाने की ज़रूरत है। URL previews आपके सर्वर से रूम में पोस्ट किया गया कोई भी लिंक फ़ेच करवाते हैं, जिसका मतलब है कि **किसी के लिंक पेस्ट करते ही आपके सर्वर का IP एड्रेस किसी तीसरे पक्ष को एक आउटबाउंड रिक्वेस्ट भेजता है** — यहाँ तक कि ऐसा लिंक भी जो सिर्फ़ यह देखने के लिए चुना गया हो कि कौन चारा लेता है। अगर आपका homeserver किसी front के पीछे बैठा है और उसका असली एड्रेस मायने रखता है, तो इसे ध्यान से तौलिए; origin एड्रेस [छुपाने पर हमारी गाइड](https://servhidden.com/hi/guides/hiding-your-origin-server-ip) इसी तरह के leak को और तफ़सील से कवर करती है।

## Registration, spam, और वह प्रतिष्ठा जो आपको विरासत में मिलती है

किसी पब्लिक homeserver पर खुला registration एक न्यौता है, और वह क़िस्म का नहीं जो आप चाहते हैं। Automated signups कुछ ही दिनों में एक छोटे सर्वर को spam का स्रोत बना देते हैं, और इसका असर सिर्फ़ आपके यहाँ तक सीमित नहीं रहता: दूसरे homeserver आपके डोमेन को अपनी access-control lists में जोड़ देते हैं, और एक बार आपका नाम इनमें से पर्याप्त सूचियों में आ जाए, तो आपके असली यूज़र कहीं और के रूम में भाग नहीं ले पाते। जली हुई domain प्रतिष्ठा को सुधारना उसे टालने से कहीं ज़्यादा मुश्क़िल है, बिल्कुल वैसे ही जैसे [mail deliverability](https://servhidden.com/hi/guides/offshore-mail-server-setup) के साथ होता है।

बचाव लायक़ डिफ़ॉल्ट सीधे हैं। एक प्राइवेट सर्वर के लिए enable_registration बंद रखिए और अकाउंट खुद बाँटिए। अगर आप दरवाज़ा खुला रखना चाहते हैं, तो उस पर गेट लगाइए: registration_requires_token registration को बिना किसी third-party सेवा के एक invite सिस्टम में बदल देता है, और एक captcha समस्या के मोटे हिस्से के ख़िलाफ़ मदद करता है। जिन रूम को आप एडमिनिस्टर करते हैं, उनके लिए Mjolnir और Draupnir परिवार के moderation bots आपको एक बार में एक रूम की बजाय पूरे समुदाय पर ban lists और room ACLs लागू करने देते हैं।

दूसरी दिशा में जानने लायक़ बात: हमारी address रेंज उन Matrix ACL blocklists में शामिल नहीं हैं जो homeserver के बीच घूमती रहती हैं, इसलिए एक नया सर्वर साफ़ प्रतिष्ठा से शुरू होता है। उसके बाद उस प्रतिष्ठा का क्या होता है, यह इस बात से तय होता है कि आप registration कैसे चलाते हैं, न कि मशीन कहाँ है इससे।

## Bridges, और उनके साथ आने वाला metadata का बिल

Bridges वह ईमानदार वजह हैं जिसकी वजह से बहुत से लोग Matrix पर टिके रहते हैं: दूसरे नेटवर्क पर मौजूद रूम के लिए एक ही क्लाइंट। ये आपके सर्वर की सुरक्षा स्थिति को भी एक ऐसे तरीक़े से बदल देते हैं जिसे नज़रअंदाज़ करना आसान है। एक bridge रिमोट अकाउंट के लिए credentials रखता है, और जहाँ दो प्रोटोकॉल मिलते हैं उस सीमा पर, उसे मैसेज को ऐसे रूप में हैंडल करना ही पड़ता है जिसे वह बदल सके — जिसका मतलब है कि bridge प्रोसेस उस ट्रैफ़िक का plaintext देखता है जो अपने दोनों तरफ़ end-to-end एन्क्रिप्टेड है।

यह bridges से बचने की वजह नहीं है। यह bridge host को संवेदनशील इंफ़्रास्ट्रक्चर की तरह बरतने की वजह है: यह वह मशीन है जो, अगर compromise हो जाए, तो उन अकाउंट को उजागर कर देती है जिनकी वह नुमाइंदगी करती है। हर bridge किसी छोटे सर्वर के memory footprint को लगभग दोगुना कर देता है, इसलिए capacity की योजना उसी हिसाब से बनाइए, और यह कहाँ चलता है इस पर उतना ही सोचिए जितना आपने ख़ुद homeserver के लिए सोचा था — हमारी [jurisdiction गाइड](https://servhidden.com/hi/guides/choosing-an-offshore-jurisdiction) का तर्क उस बॉक्स पर और भी ज़्यादा ज़ोर से लागू होता है जो एक साथ कई नेटवर्क के credentials रखता है।

## इसे ज़िंदा रखना: keys, backups और upgrades

एक Matrix सर्वर में एक ऐसी फ़ाइल होती है जिसका खोना डेटा की मात्रा से बिल्कुल अलग तरह से अपूरणीय है। Signing key — Synapse में signing.key — इसी से आपका सर्वर साबित करता है कि जो events आपके डोमेन से आने का दावा करते हैं वे सच में वहीं से आए हैं। इसे खो दीजिए तो आप विश्वसनीय ढंग से अपना सर्वर नहीं रह जाते; साथी सर्वर उन events को ख़ारिज कर देंगे जो आपका नाम रखने वाले किसी अजनबी ने साइन किए हों। इसे बाक़ी सब चीज़ों से अलग बैकअप कीजिए, और उस कॉपी को मशीन से दूर रखिए।

**key और डेटाबेस दोनों का बैकअप लीजिए, और समझिए कि दूसरे के बिना एक को restore करना ख़तरनाक क्यों है।** Matrix डेटाबेस को किसी पुराने snapshot पर वापस ले जाने से आपका सर्वर उस state में पहुँच जाता है जिसे उसके साथी सर्वर पहले ही पीछे छोड़ चुके होते हैं, और इससे बना divergence एक साफ़-सुथरे rebuild से कहीं ज़्यादा मुश्क़िल से ठीक होता है। pg_dump से लगातार dumps लीजिए, उन्हें मशीन से बाहर रखिए, और याद रखिए कि इस प्लेटफ़ॉर्म पर वापस गिरने के लिए कोई प्रोवाइडर कॉपी नहीं है — termination के बाद कुछ भी नहीं बचता, और यही इस पूरे इंतज़ाम की मूल बात है, जिसे हमारी [backup गाइड](https://servhidden.com/hi/guides/vps-backup-strategy) में कवर किया गया है।

Upgrades आम बात हैं पर वैकल्पिक नहीं। Homeserver रिलीज़ schema migrations लेकर आती हैं, और कई वर्ज़न छोड़ देने से पाँच मिनट का upgrade एक पूरी दोपहर का काम बन जाता है। छलांग लगाने से पहले release notes पढ़िए, इतनी नियमितता से upgrade कीजिए कि हर क़दम छोटा रहे, और [पहले घंटे की hardening checklist](https://servhidden.com/hi/guides/first-hour-vps-hardening-checklist) वाली बुनियादी host हाइजीन कीजिए — एक चैट सर्वर एक डेटाबेस से जुड़ी लंबे समय तक चलने वाली इंटरनेट-फ़ेसिंग सेवा है, और इसके साथ वैसा ही बर्ताव होना चाहिए।

## सर्वर कहाँ रहता है, यही अब भी नतीजा तय करता है

ऊपर लिखा सब कुछ configuration है। जिस हिस्से को configuration छू नहीं सकता वह यह है कि आपके यूज़र के बारे में अनुरोध किस कानूनी व्यवस्था तक पहुँचता है, और एक कम्युनिकेशन सर्वर के लिए यह सवाल किसी वेबसाइट के मुक़ाबले कहीं ज़्यादा वज़न रखता है। एक homeserver membership records, timestamps और social-graph डेटा को साफ़ रखता है, भले ही मैसेज बॉडी एन्क्रिप्टेड हो — इसलिए जो jurisdiction इसे होस्ट करती है, वही यह भी तय करती है कि उस रिकॉर्ड तक पहुँच किसे मिलेगी।

यही वजह है कि सिर्फ़ latency से नहीं बल्कि जान-बूझकर लोकेशन चुननी चाहिए। हम सात जगह चलाते हैं, और उनके बीच के trade-offs हमारी [jurisdiction गाइड](https://servhidden.com/hi/guides/choosing-an-offshore-jurisdiction) और [locations पेज](https://servhidden.com/hi/locations) पर बताए गए हैं। इसी सवाल का दूसरा आधा हिस्सा यह है कि प्रोवाइडर आपको कौन जानता है: जिस अकाउंट से कोई पहचान जुड़ी ही नहीं, वह ऐसे पहचान दस्तावेज़ पेश नहीं कर सकता जो उसने कभी इकट्ठे ही नहीं किए — यही सीधी वजह है कि [no-KYC hosting](https://servhidden.com/hi/no-kyc-hosting) और self-hosted communications बार-बार एक ही बातचीत में साथ आते हैं। इनमें से कोई भी उस अदालत के सामने बचाव नहीं है जिसके पास आपका नाम पहले से है, और हमारी [OpSec गाइड](https://servhidden.com/hi/guides/server-opsec-staying-anonymous) इस बारे में साफ़-साफ़ बताती है कि यह रेखा कहाँ है।

## संक्षिप्त संस्करण

अगर आप इस पेज से सिर्फ़ छह बातें लेकर जाना चाहते हैं, तो ये लीजिए:

- कुछ भी इंस्टॉल करने से पहले server_name चुन लीजिए — यह वह इकलौता फ़ैसला है जिसे आप कभी बदल नहीं सकते।

- /.well-known/matrix/server या किसी SRV रिकॉर्ड से delegate कीजिए, और दोनों नामों पर वैध TLS बनाए रखिए।

- उन रूम के हिसाब से sizing कीजिए जिनमें आपके यूज़र शामिल होंगे, न कि इस हिसाब से कि आपके पास कितने यूज़र हैं।

- पहले दिन ही media retention तय कीजिए, और URL previews के बारे में डिफ़ॉल्ट को यूँ ही अपनाने की बजाय ख़ुद फ़ैसला लीजिए।

- Registration बंद रखिए या token से गेट कीजिए; जली हुई domain प्रतिष्ठा को वापस पाना महँगा पड़ता है।

- signing.key का बैकअप अलग से लीजिए, और डेटाबेस को कभी भी अपने साथी सर्वरों से पीछे मत ले जाइए।

यह सब कीजिए तो सर्वर बेहद सामान्य रहेगा, और एक चैट सर्वर को यही होना चाहिए। बदले में आपको जो मिलता है, उसे साफ़ नज़र से देखने लायक़ है: न कि अदृश्यता, और न ही ऐसा प्रोटोकॉल जो छुपा दे कि कौन किससे बात कर रहा है, बल्कि ऐसी बातचीत जिसकी सामग्री आपकी अपनी है, ऐसा अकाउंट जिसे कोई और बंद नहीं कर सकता, और एक मशीन जो उस कानूनी व्यवस्था के नीचे बैठी है जो आपने ख़ुद सोच-समझकर चुनी है। [homeserver को वहाँ रखिए जहाँ आपने चुना](https://servhidden.com/hi/use-cases/matrix-xmpp-hosting), और federation को उस तक आने दीजिए।





FAQ

## Self-hosted Matrix — अक्सर पूछे जाने वाले सवाल





### 01
क्या Matrix को self-host करने से मेरे मैसेज ज़्यादा प्राइवेट हो जाते हैं?



यह cryptography नहीं बल्कि custody बदलता है। प्राइवेट रूम में मैसेज की सामग्री किसी भी सर्वर तक पहुँचने से पहले ही end-to-end एन्क्रिप्टेड होती है, चाहे वह कोई कमर्शियल सर्वर ही क्यों न हो, इसलिए self-hosting ऐसा कुछ भी एन्क्रिप्ट नहीं करती जो पहले से एन्क्रिप्टेड न हो। जो बदलता है वह है कि metadata किसके पास है, आपका अकाउंट कौन बंद कर सकता है, और उसके बारे में अनुरोध किस कानूनी व्यवस्था तक पहुँचता है। ये असली फ़ायदे हैं, पर वे उस फ़ायदे से अलग हैं जो लोग आमतौर पर मान लेते हैं।





### 02
क्या दूसरे homeserver के एडमिन मेरे रूम पढ़ सकते हैं?



वे एन्क्रिप्टेड मैसेज की सामग्री नहीं पढ़ सकते, पर बाक़ी बहुत कुछ देख सकते हैं। आपके रूम में जिस भी homeserver का कोई यूज़र है, उसे room state मिलता है और वह इसे स्टोर करता है: कौन सदस्य है, लोग कब शामिल हुए या निकले, display names, timestamps, reactions, और फ़ाइल ट्रांसफ़र का साइज़ व समय। यह डेटा उनके डेटाबेस में उनकी शर्तों पर रहता है, और आप अपनी तरफ़ से इसे डिलीट कर दें तो भी यह उनकी तरफ़ से नहीं हटता।





### 03
Synapse या Conduit — मुझे कौन सा चलाना चाहिए?



एक छोटे प्राइवेट सर्वर के लिए Conduit या conduwuit चुनिए, क्योंकि embedded database वाला एक अकेला Rust binary किसी एंट्री-लेवल प्लान पर आराम से चलता है और बहुत कम ध्यान माँगता है। जिस भी चीज़ के बढ़ने, bridges चलाने या पब्लिक रूप से moderate करने की उम्मीद हो, उसके लिए Synapse चुनिए, क्योंकि यह reference implementation है और हर फ़ीचर व admin tool सबसे पहले इसी के लिए बनता है। बाद में implementations के बीच माइग्रेट करने का मतलब है export करना और फिर से बनाना, इसलिए दूसरे साल को ध्यान में रखकर चुनिए।





### 04
Matrix सर्वर को कितनी RAM चाहिए?



Synapse के लिए, शुरुआत में लगभग 2 GB, दस से पचास एक्टिव यूज़र के लिए क़रीब 4 GB, और सौ से ज़्यादा होने पर 8 GB या इससे अधिक। Conduit-परिवार के सर्वर इन आँकड़ों से काफ़ी नीचे रहते हैं। ज़रूरी बात यह समझ लीजिए कि memory आपके होस्ट किए गए अकाउंट की संख्या से नहीं, बल्कि आपके यूज़र जिन रूम में शामिल होते हैं उनकी संख्या और साइज़ से तय होती है — बहुत सारे बड़े पब्लिक रूम में मुट्ठी भर यूज़र, छोटे प्राइवेट रूम में बहुत सारे यूज़र से ज़्यादा महँगे पड़ते हैं।





### 05
मेरा homeserver इतनी डिस्क क्यों खा रहा है?



आमतौर पर दो वजहें साथ मिलकर काम करती हैं। बड़े federated रूम में शामिल होने से दूसरे सर्वरों की history और state आपकी डिस्क पर आ जाती है, इसलिए एक छोटा सर्वर भी ईमानदारी से एक बड़ा डेटाबेस ढो सकता है। और remote media डिफ़ॉल्ट रूप से अनिश्चित काल तक कैश होता रहता है, इसलिए जिन रूम में आपके यूज़र बस मौजूद भर हैं, उनकी इमेज और फ़ाइलें हमेशा के लिए जमा होती जाती हैं। remote media के लिए जल्दी एक retention policy तय कीजिए, पुरानी history को समय-समय पर हटाइए, और लक्षण दिखने का इंतज़ार करने की बजाय खाली जगह पर नज़र रखिए।





### 06
क्या मुझे registration खुला रखना चाहिए?



जिस सर्वर की आपको परवाह है, उस पर नहीं। खुला registration ऐसे automated signups खींचता है जो आपके डोमेन को spam का स्रोत बना देते हैं, और जवाब में दूसरे homeserver इसे साझा access-control lists में जोड़ देते हैं — और तब आपके असली यूज़र कहीं और के रूम से ब्लॉक हो जाते हैं। Registration को बंद रखिए और अकाउंट खुद बनाइए, या इसे registration tokens के पीछे गेट कीजिए ताकि दरवाज़ा सिर्फ़ आपके बुलाए लोगों के लिए खुले।





### 07
क्या bridge चलाने से end-to-end encryption टूट जाती है?



यह सीमा को खिसका देता है। एक bridge को दो प्रोटोकॉल के बीच convert करना पड़ता है, इसलिए उस बिंदु पर उसे मैसेज को पढ़े जा सकने वाले रूप में हैंडल करना ही पड़ता है, और वह रिमोट अकाउंट के credentials भी रखता है। ट्रैफ़िक Matrix की तरफ़ और दूसरे नेटवर्क दोनों तरफ़ एन्क्रिप्टेड रहता है, पर bridge ख़ुद वह जगह है जहाँ दोनों पढ़े जा सकते हैं। इसे चलाने वाली मशीन को संवेदनशील इंफ़्रास्ट्रक्चर की तरह बरतिए, और ध्यान रखिए कि हर bridge किसी छोटे सर्वर के memory footprint को लगभग दोगुना कर देता है।





### 08
क्या मैं बाद में अपना server_name बदल सकता हूँ?



नहीं, और इंस्टॉल करने से पहले इसे दो बार पढ़ना समझदारी है। server_name आपके सर्वर द्वारा बनाए गए हर user ID, room ID और साइन किए गए event में हमेशा के लिए बैठा होता है, इसलिए इसे बदलने का मतलब अकाउंट और रूम का नाम बदलना नहीं बल्कि उन्हें छोड़ देना है। वह bare डोमेन चुनिए जो आप असल में चाहते हैं, फिर .well-known delegation या एक SRV रिकॉर्ड का इस्तेमाल करके इसे उस host की तरफ़ इशारा कीजिए जहाँ सॉफ़्टवेयर चल रहा है।




संबंधित गाइड्स

## पढ़ते रहें


[### How to चुनें an ऑफशोर होस्टिंग न्यायक्षेत्र in 2026

खरीदारी


ऑफशोर न्यायक्षेत्र चुनने के लिए एक व्यावहारिक decision framework: data-retention कानून, MLAT exposure, DMCA stance, अदालत की speed, और real-world प्रवर्तन — देश दर देश।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/choosing-an-offshore-jurisdiction)
[### Privacy-Critical Workloads के लिए VPS बनाम Dedicated सर्वर

खरीदारी


कब VPS पर्याप्त है, कब shared tenancy liability बन जाती है, और कब bare metal ही ईमानदार जवाब है। Hardware isolation, हाइपरवाइज़र risk, और cost बनाम जोखिम मॉडल।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/vps-vs-dedicated-for-privacy)
[### No-KYC VPS पर Self-Hosted VPN: WireGuard बनाम OpenVPN

परिचालन


स्व-होस्टेड VPN व्यावसायिक प्रदाताओं को क्यों मात देता है, और 2026 में WireGuard और OpenVPN गोपनीयता, प्रदर्शन और परिचालन जोखिम पर वास्तव में कैसे तुलना करते हैं।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### AI Inference के लिए RTX 4090 बनाम H100 SXM5 (और RTX 5090 कहाँ फिट होता है)

खरीदारी


2026 में self-होस्टेड LLM, image, video, voice और finetuning वर्कलोड के लिए कौन सा NVIDIA GPU चुनें: RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token और कब कौन जीतता है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/rtx-4090-vs-h100-for-ai-inference)
[### MT4 / MT5 / cTrader Forex Trading के लिए ऑफशोर Windows RDP

परिचालन


पूर्ण guide: forex trading के लिए Windows RDP क्यों, low-latency offshore क्षेत्राधिकार कैसे चुनें, MT4/MT5/cTrader/Expert Advisor सेटअप, broker servers पर latency, और no-KYC checkout path।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/offshore-windows-rdp-for-forex-trading)
[### DMCA-Ignored Hosting समझाया गया: 2026 में इसका असली मतलब क्या है

खरीदारी


"DMCA ignored" hosting वास्तव में आपको क्या देती है, कौन-सी jurisdictions इसे सच में back करती हैं, किन workloads को इसकी ज़रूरत है, और कौन-से copyright जाल इस शब्द के दायरे में नहीं आते।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/dmca-ignored-hosting-explained)
[### Crypto से Anonymous Domain Registration: 2026 में WHOIS Privacy

गोपनीयता


2026 की practical guide: बिना identity reveal किए domains register करने का तरीका — TLD के अनुसार WHOIS regimes, registrar चुनाव, crypto payment options, और वे operational गलतियाँ जो आपको leak करती हैं।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/anonymous-domain-registration-with-crypto)
[### क्रिप्टो Payments for होस्टिंग: Monero vs Bitcoin vs USDT

गोपनीयता


भुगतान कॉइन आपके होस्ट को आपके बारे में क्या पता चलता है इसे कैसे प्रभावित करता है। XMR, BTC और USDT के लिए गोपनीयता, शुल्क, finality और चेन विश्लेषण जोखिम — स्पष्ट सिफारिश के साथ।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### क्या Offshore Hosting सच में Anonymous है? एक ईमानदार जवाब

गोपनीयता


Offshore, no-KYC hosting वह identity हटा देती है जो एक normal host collect करता है — लेकिन "anonymous" होना payment, provider logging और आपकी अपनी opsec पर निर्भर करता है। यहाँ बताया गया है कि असल में क्या traceable है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/is-offshore-hosting-truly-anonymous)
[### VPS Hardening का पहला घंटा: एक Checklist

परिचालन


एक नए VPS को एक घंटे से कम में secure करने के लिए एक concrete, ordered checklist: SSH keys, एक firewall, fail2ban, automatic updates, और वह attack-surface reduction जो ज़्यादातर opportunistic attacks को रोकती है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/first-hour-vps-hardening-checklist)
[### No-KYC होस्टिंग क्या है? परिभाषा, वैधता और यह कैसे काम करती है

गोपनीयता


No-KYC होस्टिंग आपको बिना किसी पहचान सत्यापन के सर्वर किराये पर लेने देती है — न नाम, न ईमेल, न ID। यहाँ जानें इसका अर्थ, यह तकनीकी रूप से कैसे काम करता है, क्या यह कानूनी है, और असली प्रदाता को कैसे पहचानें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/what-is-no-kyc-hosting)
[### क्या ऑफशोर होस्टिंग कानूनी है? 2026 का स्पष्ट जवाब

खरीदारी


ऑफशोर होस्टिंग कानूनी है — आपके लिए भी और सेवा प्रदाता के लिए भी। यहाँ जानिए इस शब्द का वास्तविक अर्थ, कानूनी सीमा कहाँ है, कौन-सी भ्रांतियाँ छोड़ने योग्य हैं, और इसे जिम्मेदारी से कैसे उपयोग करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/is-offshore-hosting-legal)
[### Monero (XMR) से होस्टिंग का भुगतान कैसे करें — चरण-दर-चरण मार्गदर्शिका

गोपनीयता


VPS या डेडिकेटेड सर्वर के लिए Monero (XMR) से भुगतान की चरण-दर-चरण मार्गदर्शिका: XMR सबसे निजी विकल्प क्यों है, इसे कैसे प्राप्त करें, और चेकआउट प्रक्रिया कैसे काम करती है — इनवॉइस से लेकर कुछ ही मिनटों में चालू सर्वर तक।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-pay-for-hosting-with-monero)
[### गुमनाम तरीके से वेबसाइट होस्ट कैसे करें — एक व्यावहारिक 2026 गाइड

गोपनीयता


एक व्यावहारिक, बहु-स्तरीय गाइड जो बताती है कि बिना किसी पहचान के वेबसाइट कैसे होस्ट की जाए — अकाउंट, भुगतान, डोमेन, अधिकार क्षेत्र, कनेक्शन और कंटेंट — हर परत को विस्तार से समझाया गया है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-host-a-website-anonymously)
[### VPS पर WireGuard VPN कैसे सेटअप करें — चरण-दर-चरण गाइड

परिचालन


WireGuard से अपना निजी VPN बनाएं एक VPS पर: यह जानें कि self-hosted VPN किसी व्यावसायिक VPN से बेहतर क्यों है, इंस्टॉलेशन से लेकर कनेक्टेड क्लाइंट तक का पूरा सेटअप, और इसे कैसे सुरक्षित करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### GPU सर्वर पर LLM को स्व-होस्ट कैसे करें — 2026 गाइड

परिचालन


किराये के GPU सर्वर पर अपना खुद का लार्ज लैंग्वेज मॉडल चलाएँ: API की तुलना में स्व-होस्टिंग क्यों बेहतर है, कौन-सा GPU और मॉडल चुनें, Ollama या vLLM के साथ सेटअप कैसे करें, और इसकी लागत क्या है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting बनाम Offshore Hosting — क्या है अंतर?

खरीदारी


Bulletproof hosting और offshore hosting को अक्सर एक-दूसरे का पर्याय मान लिया जाता है — लेकिन ये एक नहीं हैं। यहाँ जानें असली अंतर, यह क्यों मायने रखता है, और आपको वास्तव में किसकी जरूरत है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/bulletproof-vs-offshore-hosting)
[### Bitcoin से VPS कैसे खरीदें — चरण-दर-चरण गाइड (2026)

खरीदारी


Bitcoin से VPS खरीदने की शुरुआती-अनुकूल मार्गदर्शिका: BTC प्राप्त करना, प्लान चुनना, इनवॉइस का भुगतान करना और क्या मिलता है — बिना कार्ड और बिना नाम के एक चालू सर्वर।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-buy-a-vps-with-bitcoin)
[### 2026 में DMCA-ignored होस्टिंग के लिए सर्वश्रेष्ठ देश

खरीदारी


जब आप ऐसे सर्वर चाहते हैं जो US-शैली के टेकडाउन से परे हों — तो कहाँ होस्ट करें: वे क्षेत्राधिकार जो काम करते हैं, DMCA-ignored का वास्तविक अर्थ, और सही चुनाव कैसे करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/best-countries-for-dmca-ignored-hosting)
[### Tor हिडन सर्विस (.onion साइट) कैसे होस्ट करें — 2026 गाइड

परिचालन


VPS पर Tor onion सर्विस सेट करें: हिडन सर्विस क्या है, यह अनाम होस्टिंग का सबसे मज़बूत रूप क्यों है, पूरा सेटअप, और इसे वास्तव में अनाम कैसे रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-host-a-tor-hidden-service)
[### ऑफशोर मेल सर्वर सेटअप — 2026 में खुद का प्राइवेट ईमेल होस्ट करें

परिचालन


एक ऑफशोर VPS पर अपना खुद का प्राइवेट ईमेल सर्वर चलाएं: सेल्फ-होस्ट ईमेल क्यों करें, इसके लिए क्या चाहिए, ऑल-इन-वन मेल स्टैक के साथ व्यावहारिक सेटअप, और डिलीवरेबिलिटी कैसे सही रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/offshore-mail-server-setup)
[### क्रिप्टो नोड होस्टिंग गाइड — VPS पर ब्लॉकचेन नोड चलाएं

परिचालन


सर्वर पर ब्लॉकचेन नोड कैसे होस्ट करें: अपना नोड चलाने के फायदे, Bitcoin, Ethereum, Monero आदि के लिए सर्वर का आकार, सेटअप प्रक्रिया और इसे निजी रखने के तरीके।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/crypto-node-hosting-guide)
[### Stable Diffusion के लिए GPU होस्टिंग — अपना खुद का इमेज सर्वर चलाएं

परिचालन


अपने खुद के GPU सर्वर पर Stable Diffusion चलाएं: इमेज जनरेशन को सेल्फ-होस्ट क्यों करें, कौन सा GPU चुनें, वेब UI के साथ सेटअप कैसे करें, और होस्टेड सेवा की तुलना में इसकी लागत क्या है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/gpu-hosting-for-stable-diffusion)
[### सर्वर OpSec — सर्वर चलाते समय गुमनाम कैसे रहें

गोपनीयता


गुमनाम सर्वर चलाने वाले किसी भी व्यक्ति के लिए परिचालन सुरक्षा: वे गलतियाँ जो पहचान उजागर करती हैं, वे आदतें जो उन्हें रोकती हैं, और पहचान को वास्तव में अलग कैसे रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/server-opsec-staying-anonymous)
[### Seedbox सेटअप गाइड — 2026 में अपना निजी Seedbox बनाएँ

परिचालन


अपने सर्वर पर खुद का seedbox कैसे बनाएँ: seedbox क्या होता है, उसकी साइज़िंग, web UI के साथ torrent client की इंस्टॉलेशन, और उसे निजी व सुरक्षित रखना।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/seedbox-setup-guide)
[### अपने खुद के VPS से DPI सेंसरशिप को कैसे बायपास करें (2026 गाइड)

गोपनीयता


आपका VPN काम करना बंद कर चुका है? अपने खुद के VPS से DPI सेंसरशिप बायपास करने का तरीका: डीप पैकेट इंस्पेक्शन असल में क्या पहचानता है, 2026 के पांच प्रोटोकॉल में से कौन-सा किस ब्लॉक को मात देता है, और एक पूरा VLESS+REALITY वॉकथ्रू।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/bypass-dpi-censorship-with-your-own-vps)
[### VPS पर फुल-डिस्क एन्क्रिप्शन: LUKS सेटअप और यह असल में क्या सुरक्षित करता है

परिचालन


LUKS से VPS एन्क्रिप्ट करने का तरीका: एन्क्रिप्टेड डेटा वॉल्यूम, SSH पर रिमोट अनलॉक वाला फुल-रूट एन्क्रिप्शन, छोटे सर्वर पर मायने रखने वाली सेटिंग्स, और डिस्क एन्क्रिप्शन असल में क्या रोकता है इसका ईमानदार ब्योरा।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/full-disk-encryption-on-a-vps)
[### ओरिजिन सर्वर IP छुपाना: CDN, रिवर्स प्रॉक्सी और जो फिर भी लीक होता है

गोपनीयता


ऑफ़शोर सर्वर के आगे CDN लगाएँ या नहीं: यह क्या छुपाता है, साथ में कौन-सी शिकायत डेस्क मिलती है, वे छह तरीके जिनसे ओरिजिन IP फिर भी लीक होता है, और अपना ऑडिट कैसे करें।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/hiding-your-origin-server-ip)
[### VPS Backup कैसे लें: Encrypted, Off-Site और भरोसेमंद Restore

परिचालन


आपका host कोई backup नहीं रखता। server को असल में क्या बर्बाद करता है, push backup साथ में क्यों मरता है, restic बनाम BorgBackup, और restore टेस्ट करने का तरीक़ा।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/vps-backup-strategy)
[### Website को Offshore Hosting पर बिना Downtime के कैसे Migrate करें

परिचालन


host migration को उबाऊ बनाने वाला क्रम: DNS TTL दिनों पहले घटाएँ, दोनों servers साथ चलाएँ, writes को घंटों की बजाय मिनटों तक freeze करें — और migration के पीछे छूटी passive-DNS, Certificate Transparency और WHOIS trail को साफ़ करें।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

परिचालन


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


8-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-a-crypto-payment-gateway)




## homeserver वहाँ चलाइए, जहाँ आपने चुना



सात jurisdictions, हर प्लान पर full root, custom ISO और unmetered bandwidth — एक छोटे Conduit या Dendrite सर्वर के लिए $7.50/माह से शुरू। No KYC, कोई ईमेल नहीं, सिर्फ़ crypto।


[VPS प्लान देखें](https://servhidden.com/hi/vps)
[सभी लोकेशन](https://servhidden.com/hi/locations)
[प्राइवेट होस्टिंग](https://servhidden.com/hi/anonymous-hosting)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "7 ऑफशोर न्यायक्षेत्रों में ऑफशोर VPS और डेडिकेटेड सर्वर। KYC नहीं, लॉग नहीं, केवल क्रिप्टो। आर्किटेक्चर से ही गोपनीयता।",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "खुद का Matrix Server Self-Host करें: Federation, Metadata और E2EE की सीमाएँ",
    "description": "अपने खुद के Matrix homeserver से असल में क्या मिलता है: Synapse बनाम Conduit, वह server_name जिसे आप बदल नहीं सकते, डिस्क भरने वाला media, और federation का एक्सपोज़र।",
    "image": "https://servhidden.com/assets/img/guides/self-host-a-matrix-server.webp?v=1787253905",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-21T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/self-host-a-matrix-server",
    "inLanguage": "hi",
    "keywords": "Matrix server self-host कैसे करें, अपना Matrix homeserver बनाएं, Synapse vs Conduit, Matrix server_name delegation, no-KYC VPS hosting, private chat server hosting, Matrix federation privacy, Matrix homeserver RAM requirement",
    "articleSection": "परिचालन",
    "wordCount": 3267
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "क्या Matrix को self-host करने से मेरे मैसेज ज़्यादा प्राइवेट हो जाते हैं?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "यह cryptography नहीं बल्कि custody बदलता है। प्राइवेट रूम में मैसेज की सामग्री किसी भी सर्वर तक पहुँचने से पहले ही end-to-end एन्क्रिप्टेड होती है, चाहे वह कोई कमर्शियल सर्वर ही क्यों न हो, इसलिए self-hosting ऐसा कुछ भी एन्क्रिप्ट नहीं करती जो पहले से एन्क्रिप्टेड न हो। जो बदलता है वह है कि metadata किसके पास है, आपका अकाउंट कौन बंद कर सकता है, और उसके बारे में अनुरोध किस कानूनी व्यवस्था तक पहुँचता है। ये असली फ़ायदे हैं, पर वे उस फ़ायदे से अलग हैं जो लोग आमतौर पर मान लेते हैं।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या दूसरे homeserver के एडमिन मेरे रूम पढ़ सकते हैं?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "वे एन्क्रिप्टेड मैसेज की सामग्री नहीं पढ़ सकते, पर बाक़ी बहुत कुछ देख सकते हैं। आपके रूम में जिस भी homeserver का कोई यूज़र है, उसे room state मिलता है और वह इसे स्टोर करता है: कौन सदस्य है, लोग कब शामिल हुए या निकले, display names, timestamps, reactions, और फ़ाइल ट्रांसफ़र का साइज़ व समय। यह डेटा उनके डेटाबेस में उनकी शर्तों पर रहता है, और आप अपनी तरफ़ से इसे डिलीट कर दें तो भी यह उनकी तरफ़ से नहीं हटता।"
            }
        },
        {
            "@type": "Question",
            "name": "Synapse या Conduit — मुझे कौन सा चलाना चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "एक छोटे प्राइवेट सर्वर के लिए Conduit या conduwuit चुनिए, क्योंकि embedded database वाला एक अकेला Rust binary किसी एंट्री-लेवल प्लान पर आराम से चलता है और बहुत कम ध्यान माँगता है। जिस भी चीज़ के बढ़ने, bridges चलाने या पब्लिक रूप से moderate करने की उम्मीद हो, उसके लिए Synapse चुनिए, क्योंकि यह reference implementation है और हर फ़ीचर व admin tool सबसे पहले इसी के लिए बनता है। बाद में implementations के बीच माइग्रेट करने का मतलब है export करना और फिर से बनाना, इसलिए दूसरे साल को ध्यान में रखकर चुनिए।"
            }
        },
        {
            "@type": "Question",
            "name": "Matrix सर्वर को कितनी RAM चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Synapse के लिए, शुरुआत में लगभग 2 GB, दस से पचास एक्टिव यूज़र के लिए क़रीब 4 GB, और सौ से ज़्यादा होने पर 8 GB या इससे अधिक। Conduit-परिवार के सर्वर इन आँकड़ों से काफ़ी नीचे रहते हैं। ज़रूरी बात यह समझ लीजिए कि memory आपके होस्ट किए गए अकाउंट की संख्या से नहीं, बल्कि आपके यूज़र जिन रूम में शामिल होते हैं उनकी संख्या और साइज़ से तय होती है — बहुत सारे बड़े पब्लिक रूम में मुट्ठी भर यूज़र, छोटे प्राइवेट रूम में बहुत सारे यूज़र से ज़्यादा महँगे पड़ते हैं।"
            }
        },
        {
            "@type": "Question",
            "name": "मेरा homeserver इतनी डिस्क क्यों खा रहा है?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "आमतौर पर दो वजहें साथ मिलकर काम करती हैं। बड़े federated रूम में शामिल होने से दूसरे सर्वरों की history और state आपकी डिस्क पर आ जाती है, इसलिए एक छोटा सर्वर भी ईमानदारी से एक बड़ा डेटाबेस ढो सकता है। और remote media डिफ़ॉल्ट रूप से अनिश्चित काल तक कैश होता रहता है, इसलिए जिन रूम में आपके यूज़र बस मौजूद भर हैं, उनकी इमेज और फ़ाइलें हमेशा के लिए जमा होती जाती हैं। remote media के लिए जल्दी एक retention policy तय कीजिए, पुरानी history को समय-समय पर हटाइए, और लक्षण दिखने का इंतज़ार करने की बजाय खाली जगह पर नज़र रखिए।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या मुझे registration खुला रखना चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "जिस सर्वर की आपको परवाह है, उस पर नहीं। खुला registration ऐसे automated signups खींचता है जो आपके डोमेन को spam का स्रोत बना देते हैं, और जवाब में दूसरे homeserver इसे साझा access-control lists में जोड़ देते हैं — और तब आपके असली यूज़र कहीं और के रूम से ब्लॉक हो जाते हैं। Registration को बंद रखिए और अकाउंट खुद बनाइए, या इसे registration tokens के पीछे गेट कीजिए ताकि दरवाज़ा सिर्फ़ आपके बुलाए लोगों के लिए खुले।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या bridge चलाने से end-to-end encryption टूट जाती है?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "यह सीमा को खिसका देता है। एक bridge को दो प्रोटोकॉल के बीच convert करना पड़ता है, इसलिए उस बिंदु पर उसे मैसेज को पढ़े जा सकने वाले रूप में हैंडल करना ही पड़ता है, और वह रिमोट अकाउंट के credentials भी रखता है। ट्रैफ़िक Matrix की तरफ़ और दूसरे नेटवर्क दोनों तरफ़ एन्क्रिप्टेड रहता है, पर bridge ख़ुद वह जगह है जहाँ दोनों पढ़े जा सकते हैं। इसे चलाने वाली मशीन को संवेदनशील इंफ़्रास्ट्रक्चर की तरह बरतिए, और ध्यान रखिए कि हर bridge किसी छोटे सर्वर के memory footprint को लगभग दोगुना कर देता है।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या मैं बाद में अपना server_name बदल सकता हूँ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं, और इंस्टॉल करने से पहले इसे दो बार पढ़ना समझदारी है। server_name आपके सर्वर द्वारा बनाए गए हर user ID, room ID और साइन किए गए event में हमेशा के लिए बैठा होता है, इसलिए इसे बदलने का मतलब अकाउंट और रूम का नाम बदलना नहीं बल्कि उन्हें छोड़ देना है। वह bare डोमेन चुनिए जो आप असल में चाहते हैं, फिर .well-known delegation या एक SRV रिकॉर्ड का इस्तेमाल करके इसे उस host की तरफ़ इशारा कीजिए जहाँ सॉफ़्टवेयर चल रहा है।"
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "होम",
            "item": "https://servhidden.com/hi/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "गोपनीयता होस्टिंग Guides",
            "item": "https://servhidden.com/hi/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "खुद का Matrix Server Self-Host करें: Federation, Metadata और E2EE की सीमाएँ",
            "item": "https://servhidden.com/hi/guides/self-host-a-matrix-server"
        }
    ]
}
```