आपने एक MCP सर्वर लिखा। स्थानीय रूप से यह ठीक काम करता है — आपका एजेंट इसे कॉल करता है, टूल दागते हैं, सब कुछ जुड़ा है। फिर आप अपना लैपटॉप बंद करते हैं और यह चला गया। अगर आप उस सर्वर को तब पहुँच योग्य चाहते हैं जब भी आपके एजेंट को ज़रूरत हो — दूसरी मशीन से, एक साथी के सेटअप से, 3 बजे की एक निर्धारित जॉब से — इसे कहीं ऐसे रहना होगा जो हरदम चालू हो, एक स्थिर पते और HTTPS के साथ। यही एक VPS के लिए है।
यहाँ है कि अपने MCP सर्वर को अपने लैपटॉप से हटाकर एक ऐसे बॉक्स पर कैसे ले जाएँ जिसे आप सच में नियंत्रित करते हैं, इस बारे में ईमानदार नोट्स के साथ कि मेहनत कहाँ जाती है।
स्थानीय बनाम रिमोट: "होस्टिंग" का असल में क्या मतलब है
MCP सर्वर दो आकारों में आते हैं।
एक stdio सर्वर एक स्थानीय प्रोसेस के रूप में चलता है और उसी मशीन पर एक क्लाइंट से मानक इनपुट/आउटपुट पर बात करता है। जब आप बना रहे हों तब यह उत्तम है — पर इसे नेटवर्क पर किसी चीज़ द्वारा पहुँचा नहीं जा सकता।
एक रिमोट सर्वर एक URL पर HTTP बोलता है (Server-Sent Events, या नया streamable-HTTP ट्रांसपोर्ट)। कोई भी क्लाइंट जो URL जानता हो और सही साख रखता हो, इसे कॉल कर सकता है। अपना ख़ुद का MCP सर्वर होस्ट करने का मतलब है रिमोट प्रकार को कहीं सार्वजनिक और स्थिर चलाना।
अपने लैपटॉप को बस टनल क्यों न करें
आप तकनीकी रूप से एक होम मशीन को एक टनल से उजागर कर सकते हैं, और एक झटपट डेमो के लिए वह ठीक है। किसी भी ऐसी चीज़ के लिए जिस पर आप निर्भर हों, आप मशीन की समस्याएँ विरासत में लेते हैं: यह सोती है, आपका ISP आपका IP घुमाता है, आपका अपलोड धीमा है, और अब असली टूल से भरी एक सेवा आपके होम नेटवर्क पर बाक़ी सबके बगल में बैठी है। एक VPS आपको एक तय सार्वजनिक IP, एक असली डोमेन, उचित अपटाइम और अलगाव देता है। महीने के कुछ डॉलर में यह "मेरे एजेंट ने कनेक्शन क्यों खोया" सवालों की एक पूरी श्रेणी मिटा देता है।
स्टैक, ठोस रूप से
एक छोटा बॉक्स चुनें। एक MCP टूल सर्वर ज़्यादातर I/O है — यह API, फ़ाइलों और डेटाबेस का इंतज़ार करता है; यह भारी गणित नहीं करता। ज़्यादातर के लिए 1–2 GB RAM बहुत है। (जवाब देने के लिए इनलाइन एक मॉडल चलाना एक अलग कहानी है — Ollama के साथ एक LLM स्व-होस्ट करना देखें।)
अपने सर्वर को localhost से बँधा चलाएँ, मान लें Node या Python 127.0.0.1:3100 पर सुनता। इसे सीधे सार्वजनिक इंटरफ़ेस से दूर रखें — प्रॉक्सी उसे संभालता है।
एक रिवर्स प्रॉक्सी सामने रखें अपने डोमेन पर TLS समाप्त करने के लिए। Caddy इसे लगभग चार लाइन में करता है और एक मुफ़्त प्रमाणपत्र अपने आप लाता है:
mcp.yourdomain.com {
reverse_proxy 127.0.0.1:3100
}
mcp.yourdomain.com को अपने VPS IP पर इंगित करें, Caddy रीलोड करें, और आपका सर्वर streamable-HTTP पर https://mcp.yourdomain.com पर लाइव है।
इसे हरदम चालू रखें
एक सर्वर जो पहले क्रैश या रीबूट पर मर जाता है, "होस्टेड" नहीं — "अभी के लिए चल रहा" है। इसे एक systemd यूनिट में लपेटें ताकि यह क्रैश पर पुनः शुरू हो और रीबूट के बाद वापस आए:
[Unit]
Description=My MCP server
After=network.target
[Service]
ExecStart=/usr/bin/node /opt/mcp/server.js
Restart=always
RestartSec=2
[Install]
WantedBy=multi-user.target
systemctl enable --now my-mcp और यह सचमुच हरदम चालू है। (वही पैटर्न किसी भी एजेंट या बॉट को 24/7 ज़िंदा रखता है।)
वह हिस्सा जो लोग चूकते हैं: आपको एक पहुँच योग्य पोर्ट चाहिए
एक सार्वजनिक MCP एंडपॉइंट को एक इनबाउंड पोर्ट चाहिए — 443 — जो इंटरनेट से पहुँच योग्य हो। एक NAT प्लान पर आपको SSH के लिए ठीक एक फ़ॉरवर्ड किया पोर्ट मिलता है और कुछ नहीं; आप 443 दुनिया के लिए नहीं खोल सकते। एक सार्वजनिक HTTPS MCP सर्वर होस्ट करने के लिए आप एक डेडिकेटेड-IP प्लान चाहते हैं, जहाँ हर पोर्ट आपका है और आप एक डोमेन सीधे बॉक्स पर इंगित कर सकते हैं। यही फ़र्क़ है "उसी लैपटॉप पर मेरा एजेंट इस तक पहुँच सकता है" और "कहीं का भी कोई क्लाइंट पहुँच सकता है" के बीच।
इसे बंद करें — यह विशेषाधिकारों वाला एक API है
एक MCP सर्वर आमतौर पर ऐसे टूल उजागर करता है जो काम करते हैं: फ़ाइलें पढ़ना, पेड API पर पहुँचना, पैसा हिलाना। उसे खुले इंटरनेट पर नंगा न रखें।
- हर कॉल पर एक टोकन माँगें। गुमनाम अनुरोध अस्वीकारें; किसी भी टूल के चलने से पहले एक bearer टोकन या API कुंजी जाँचें।
- 443 और अपने SSH पोर्ट को छोड़कर सब कुछ फ़ायरवॉल करें।
- सिर्फ़-कुंजी SSH, कोई पासवर्ड लॉगिन नहीं। (यहाँ दस-मिनट चेकलिस्ट है।)
एंडपॉइंट को वैसा मानें जैसा यह है — असली अधिकार वाला एक API — और ज़्यादातर जोखिम चला जाता है।
ईमानदार सीमाएँ
- अब ऑप्स आपके हैं। OS अपडेट, प्रोसेस को स्वस्थ रखना, लॉग देखना। Caddy आपके लिए प्रमाणपत्र नवीनीकृत करता है, पर बाक़ी आपका है। एक प्रबंधित क्लाउड फ़ंक्शन इसे छिपाता है; एक VPS इसे नियंत्रण और एक कहीं कम बिल के बदले आपको सौंपता है।
- MCP स्पेक अब भी बदल रहा है। ट्रांसपोर्ट और auth पैटर्न रिलीज़-दर-रिलीज़ बदलते हैं। अपना SDK संस्करण पिन करें और कभी-कभी इसे अपडेट करने की उम्मीद रखें।
- एक CPU बॉक्स टूल सर्वर के लिए सही है, एक स्थानीय मॉडल से जवाब जनरेट करने के लिए नहीं। अगर आपका सर्वर जवाब देने के लिए एक LLM चलाता है, तो वह एक अलग, भारी मशीन है — Ollama गाइड देखें।
- विनाशकारी टूल कभी auth और एक पुष्टि क़दम के बिना उजागर न करें। एक खुला टूल जो चीज़ें मिटाता है अंततः एक ऐसे बॉट से मिलेगा जो सब कुछ स्कैन करता है।
इसके लिए भुगतान
एक ईमेल से साइन अप करें और USDC या USDT में भुगतान करें — कोई कार्ड नहीं, कोई ID नहीं। और अगर आप इसे एक एजेंट के लिए जोड़ रहे हैं, वैसा ही बॉक्स प्रोग्रामेटिक रूप से हमारे ख़ुद के MCP सर्वर पर ऑर्डर और भुगतान किया जा सकता है — एजेंट रजिस्टर करता है, एक बैलेंस भरता है, और अपने दम पर ऑर्डर करता है।
सर्वर को एक बार होस्ट करें, और आपके टूल तब वहाँ हैं जब भी एजेंट उनकी ओर बढ़े।
तैयार सेटअप: MCP सर्वर के लिए VPS देखें — अनुशंसित प्लान और एक-मिनट क्रिप्टो डिप्लॉय।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।