একটি MCP সার্ভার হোস্ট করতে কি একটি dedicated IP দরকার?

একটি পাবলিক HTTPS endpoint-এর জন্য, হ্যাঁ। NAT প্ল্যান একটি একক SSH পোর্ট forward করে ও পোর্ট 443 ইন্টারনেটে উন্মুক্ত করে না। একটি dedicated-IP প্ল্যান আপনাকে প্রতিটি পোর্ট ও একটি ডোমেইন দেয় যা আপনি সরাসরি বক্সে তাক করতে পারেন।

stdio নাকি HTTP — কোন transport হোস্ট করি?

HTTP (SSE বা নতুন streamable-HTTP)। একটি stdio সার্ভার শুধু একই মেশিনের একটি client-এর সাথে কথা বলে; নেটওয়ার্কে পৌঁছানোযোগ্য চাওয়া যেকোনো কিছুকে একটি URL-এর পেছনে HTTP বলতে হয়।

একটি VPS কি কয়েকটি MCP সার্ভার চালাতে পারে?

হ্যাঁ। প্রতিটি সার্ভার একটি ভিন্ন local পোর্টে bind করুন ও reverse proxy-তে প্রতিটিকে নিজের subdomain দিন। RAM ব্যবহারিক সীমা, আর tool সার্ভার তার খুব কম ব্যবহার করে।

একটি MCP সার্ভারের কত RAM দরকার?

সাধারণত কম। একটি tool সার্ভার I/O-bound — এটি সংখ্যা পেষার বদলে API ও database-এর অপেক্ষা করে, তাই 1–2 GB বেশিরভাগ সামলায়। উত্তর তৈরি করতে একটি মডেল চালানো একটি আলাদা, অনেক ভারী কাজ।

একটি VPS-এ আপনার নিজের MCP সার্ভার হোস্ট করুন

আপনি একটি MCP সার্ভার লিখলেন। Local-ভাবে এটি ভালোই কাজ করে — আপনার agent এটি ডাকে, tools fire করে, সব যুক্ত। তারপর আপনি ল্যাপটপ বন্ধ করেন আর এটি চলে যায়। আপনার agent-এর যখনই দরকার তখন সেই সার্ভার পৌঁছানোযোগ্য চাইলে — অন্য মেশিন থেকে, একজন সতীর্থের সেটআপ থেকে, ভোর 3টার একটি নির্ধারিত job থেকে — এটিকে এমন কোথাও থাকতে হবে যা সবসময় চালু, একটি স্থিতিশীল ঠিকানা ও HTTPS সহ। ওটাই একটি VPS যার জন্য।

এই যে কীভাবে আপনার MCP সার্ভার আপনার ল্যাপটপ থেকে সরিয়ে আপনি আসলে নিয়ন্ত্রণ করেন এমন একটি বক্সে নেবেন, শ্রম কোথায় যায় তার সৎ নোট সহ।

Local বনাম remote: "hosting" আসলে কী বোঝায়

MCP সার্ভার দুই আকারে আসে।

একটি stdio সার্ভার একটি local process হিসেবে চলে ও standard input/output-এর মাধ্যমে একই মেশিনের একটি client-এর সাথে কথা বলে। আপনি বানানোর সময় এটি নিখুঁত — কিন্তু নেটওয়ার্কজুড়ে কিছু এতে পৌঁছাতে পারে না।

একটি remote সার্ভার একটি URL-এর ওপর HTTP (Server-Sent Events, বা নতুন streamable-HTTP transport) বলে। যে কোনো client যা URL জানে ও সঠিক credential ধরে তা এটি ডাকতে পারে। আপনার নিজের MCP সার্ভার হোস্ট করা মানে remote ধরনটি কোথাও পাবলিক ও স্থিতিশীলভাবে চালানো।

কেবল আপনার ল্যাপটপ tunnel করবেন না কেন

আপনি প্রযুক্তিগতভাবে একটি tunnel দিয়ে একটি বাড়ির মেশিন উন্মুক্ত করতে পারেন, আর একটি দ্রুত demo-র জন্য তা ঠিক। আপনি যার ওপর নির্ভর করেন এমন কিছুর জন্য, আপনি মেশিনের সমস্যা উত্তরাধিকারসূত্রে পান: এটি ঘুমায়, আপনার ISP আপনার IP ঘোরায়, আপনার upload ধীর, আর এখন আসল tools-এ ভরা একটি সার্ভিস আপনার বাড়ির নেটওয়ার্কে বাকি সবকিছুর পাশে বসে। একটি VPS আপনাকে একটি স্থির পাবলিক IP, একটি আসল ডোমেইন, সঠিক uptime, ও isolation দেয়। মাসে কয়েক ডলারে এটি "আমার agent কেন সংযোগ হারাল" প্রশ্নের একটি পুরো শ্রেণি মুছে দেয়।

stack, সুনির্দিষ্টভাবে

একটি ছোট বক্স বাছুন। একটি MCP tool সার্ভার বেশিরভাগ I/O — এটি API, ফাইল ও database-এর অপেক্ষা করে; ভারী গণিত করে না। বেশিরভাগের জন্য 1–2 GB RAM যথেষ্ট। (উত্তর দিতে একটি মডেল inline চালানো একটি ভিন্ন গল্প — দেখুন Ollama দিয়ে একটি LLM সেলফ-হোস্টিং।)

আপনার সার্ভার localhost-এ bind করে চালান, ধরুন 127.0.0.1:3100-এ listen করা Node বা Python। এটিকে সরাসরি পাবলিক interface থেকে দূরে রাখুন — proxy সেটি সামলায়।

সামনে একটি reverse proxy বসান আপনার ডোমেইনে TLS terminate করতে। Caddy এটি প্রায় চার লাইনে করে ও স্বয়ংক্রিয়ভাবে একটি বিনামূল্যের সার্টিফিকেট আনে:

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

mcp.yourdomain.com-কে আপনার VPS IP-তে তাক করুন, Caddy reload করুন, আর আপনার সার্ভার streamable-HTTP-র ওপর https://mcp.yourdomain.com-এ live।

এটি always on রাখুন

যে সার্ভার প্রথম ক্র্যাশ বা reboot-এ মরে সেটি "hosted" নয় — "আপাতত চলছে"। এটিকে একটি systemd unit-এ মুড়ুন যাতে এটি ক্র্যাশে restart হয় ও একটি reboot-এর পরে ফিরে আসে:

[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 আর এটি সত্যিই always on। (একই প্যাটার্ন যেকোনো agent বা bot 24/7 জীবিত রাখে।)

যে অংশ মানুষ মিস করে: আপনার একটি পৌঁছানোযোগ্য পোর্ট দরকার

একটি পাবলিক MCP endpoint-এর একটি inbound পোর্ট দরকার — 443 — ইন্টারনেট থেকে পৌঁছানোযোগ্য। একটি NAT প্ল্যানে আপনি SSH-এর জন্য ঠিক একটি forwarded পোর্ট পান ও আর কিছু নয়; আপনি বিশ্বকে 443 খুলতে পারবেন না। একটি পাবলিক HTTPS MCP সার্ভার হোস্ট করতে আপনি একটি dedicated-IP প্ল্যান চান, যেখানে প্রতিটি পোর্ট আপনার ও আপনি একটি ডোমেইন সরাসরি বক্সে তাক করতে পারেন। ওটাই "একই ল্যাপটপের আমার agent এতে পৌঁছাতে পারে" ও "যেকোনো জায়গার যেকোনো client পারে"-র মধ্যে পার্থক্য।

এটি লক করুন — এটি সুবিধা সহ একটি API

একটি MCP সার্ভার সাধারণত এমন tools উন্মুক্ত করে যা কাজ করে: ফাইল পড়ে, paid API-তে আঘাত করে, টাকা সরায়। ওটা খোলা ইন্টারনেটে নগ্নভাবে রাখবেন না।

প্রতিটি call-এ একটি token দাবি করুন। anonymous request প্রত্যাখ্যান করুন; কোনো tool চলার আগে একটি bearer token বা API key চেক করুন।
443 ছাড়া সবকিছু firewall করুন ও আপনার SSH পোর্ট।
শুধু-key SSH, কোনো password login নয়। (এই যে দশ-মিনিটের checklist।)

endpoint-কে যা তা তেমন ভাবুন — আসল কর্তৃত্ব সহ একটি API — আর বেশিরভাগ ঝুঁকি চলে যায়।

সৎ সীমা

এখন আপনি ops-এর মালিক। OS আপডেট, process সুস্থ রাখা, log দেখা। Caddy আপনার জন্য cert renew করে, কিন্তু বাকিটা আপনার। একটি managed cloud function এটি লুকায়; একটি VPS নিয়ন্ত্রণ ও অনেক কম বিলের বিনিময়ে এটি আপনাকে দেয়।
MCP spec এখনও চলমান। transport ও auth প্যাটার্ন release থেকে release বদলায়। আপনার SDK সংস্করণ pin করুন ও মাঝেমধ্যে এটি আপডেট করার আশা রাখুন।
একটি CPU বক্স tool সার্ভারের জন্য সঠিক, একটি local মডেল দিয়ে উত্তর তৈরির জন্য নয়। আপনার সার্ভার সাড়া দিতে একটি LLM চালালে, সেটি একটি আলাদা, ভারী মেশিন — Ollama গাইড দেখুন।
কখনও auth ও একটি confirmation ধাপ ছাড়া ধ্বংসাত্মক tools উন্মুক্ত করবেন না। একটি খোলা tool যা জিনিস delete করে তা একসময় সবকিছু scan করা একটি bot-এর দেখা পাবে।

এর জন্য পরিশোধ

একটি ইমেল দিয়ে sign up করুন ও USDC বা USDT-তে পরিশোধ করুন — কোনো কার্ড, ID নয়। আর আপনি এটি একটি agent-এর জন্য যুক্ত করলে, একই ধরনের বক্স আমাদের নিজের MCP সার্ভার-এর মাধ্যমে প্রোগ্রাম্যাটিকভাবে অর্ডার ও পরিশোধ করা যায় — agent register করে, একটি balance funded করে, ও নিজে অর্ডার করে।

সার্ভারটি একবার হোস্ট করুন, আর agent যখনই আপনার tools-এর দিকে হাত বাড়ায় তখন এরা সেখানে।

তৈরি সেটআপ: MCP সার্ভারের জন্য VPS দেখুন — সুপারিশকৃত প্ল্যান ও এক-মিনিটের ক্রিপ্টো deploy।