Нужен ли ми е dedicated IP, за да хоствам MCP сървър?

За публичен HTTPS endpoint, да. NAT плановете пренасочват единичен SSH порт и няма да изложат порт 443 на интернет. План с dedicated IP ти дава всеки порт и домейн, който можеш да насочиш направо към машината.

stdio или HTTP — кой transport да хоствам?

HTTP (SSE или по-новия streamable-HTTP). stdio сървър говори само с клиент на същата машина; всичко, което искаш достъпно през мрежата, трябва да говори HTTP зад URL.

Може ли един VPS да пуска няколко MCP сървъра?

Да. Свържи всеки сървър с различен локален порт и дай на всеки собствен поддомейн в reverse proxy-то. RAM е практичният лимит, а сървърите за инструменти използват много малко от него.

Колко RAM се нуждае MCP сървър?

Обикновено малко. Сървър за инструменти е I/O-bound — той чака API-та и бази данни, вместо да смила числа, така че 1–2 GB се справят с повечето. Пускането на модел за генериране на отговорите е отделна, много по-тежка работа.

Хоствай собствен MCP сървър на VPS

Написал си MCP сървър. Локално работи добре — агентът ти го извиква, инструментите стрелят, всичко е свързано. После затваряш лаптопа и го няма. Ако искаш този сървър достъпен, когато агентът ти се нуждае — от друга машина, от настройката на колега, от планирана задача в 3 сутринта — той трябва да живее някъде, което е винаги включено, със стабилен адрес и HTTPS. За това е VPS.

Ето как да преместиш MCP сървъра си от лаптопа на машина, която реално контролираш, с честни бележки къде отива усилието.

Локален срещу отдалечен: какво всъщност значи „хостване“

MCP сървърите идват в две форми.

stdio сървър работи като локален процес и говори с клиент на същата машина през standard input/output. Перфектен е, докато строиш — но не може да бъде достигнат от нищо през мрежата.

Отдалечен сървър говори HTTP (Server-Sent Events, или по-новия streamable-HTTP transport) през URL. Всеки клиент, който знае URL-а и държи правилните credentials, може да го извика. Да хостваш собствен MCP сървър значи да пускаш отдалечения вид някъде публично и стабилно.

Защо да не тунелираш просто лаптопа си

Технически можеш да изложиш домашна машина с тунел, и за бърза демонстрация това е наред. За всичко, на което разчиташ, наследяваш проблемите на машината: тя заспива, ISP-то ти ротира IP-то, upload-ът ти е бавен, и сега услуга, пълна с реални инструменти, седи на домашната ти мрежа до всичко останало. VPS ти дава фиксиран публичен IP, реален домейн, свястно време на работа и изолация. За няколко долара на месец изтрива цял клас въпроси „защо агентът ми загуби връзката“.

Стекът, конкретно

Избери малка машина. Сървър за MCP инструменти е основно I/O — той чака API-та, файлове и бази данни; не прави тежка математика. 1–2 GB RAM са предостатъчни за повечето. (Пускането на модел inline за отговор е друга история — виж self-hosting на LLM с Ollama.)

Пусни сървъра си вързан към localhost, например Node или Python, слушащ на 127.0.0.1:3100. Дръж го извън публичния интерфейс директно — proxy-то се грижи за това.

Сложи reverse proxy отпред, за да прекрати TLS на домейна ти. Caddy го прави в около четири реда и взима безплатен сертификат автоматично:

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

Насочи mcp.yourdomain.com към IP-то на VPS-а си, презареди Caddy, и сървърът ти е live на https://mcp.yourdomain.com през streamable-HTTP.

Дръж го винаги включен

Сървър, който умира при първия срив или рестарт, не е „хостван“ — той е „работещ засега“. Увий го в systemd unit, така че да рестартира при срив и да се връща след рестарт:

[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 endpoint се нуждае от входящ порт — 443 — достъпен от интернет. На NAT план получаваш точно един пренасочен порт за SSH и нищо друго; не можеш да отвориш 443 към света. За да хостваш публичен HTTPS MCP сървър, искаш план с dedicated IP, където всеки порт е твой и можеш да насочиш домейн направо към машината. Това е разликата между „агентът ми на същия лаптоп може да го достигне“ и „всеки клиент навсякъде може“.

Заключи го — това е API с привилегии

MCP сървър обикновено излага инструменти, които правят неща: четат файлове, удрят платени API-та, местят пари. Не го слагай на отворения интернет гол.

Изисквай токен на всяко извикване. Отхвърляй анонимни заявки; проверявай bearer токен или API ключ, преди който и да е инструмент да се пусне.
Firewall на всичко освен 443 и твоя SSH порт.
SSH само с ключове, без вход с парола. (Ето checklist-а за десет минути.)

Третирай endpoint-а за това, което е — API с реален авторитет — и по-голямата част от риска изчезва.

Честните граници

Ops-ът вече е твой. OS ъпдейти, поддържане на процеса здрав, гледане на логове. Caddy подновява сертификата вместо теб, но останалото е твое. Управлявана cloud функция крие това; VPS ти го предава в замяна на контрол и много по-ниска сметка.
MCP спецификацията все още се движи. Transports и auth моделите се променят от release на release. Фиксирай версията на SDK-то си и очаквай да го обновяваш от време на време.
CPU машина е правилна за сървъри на инструменти, не за генериране на отговори с локален модел. Ако сървърът ти пуска LLM за отговор, това е отделна, по-тежка машина — виж ръководството за Ollama.
Никога не излагай деструктивни инструменти без auth и стъпка за потвърждение. Отворен инструмент, който трие неща, ще срещне рано или късно бот, който сканира всичко.

Плащане за него

Регистрирай се с имейл и плати в USDC или USDT — без карта, без документ. И ако свързваш това за агент, същият вид машина може да бъде поръчана и платена програмно през нашия собствен MCP сървър — агентът се регистрира, захранва баланс и поръчва сам.

Хоствай сървъра веднъж и инструментите ти са там, когато агентът посегне за тях.

Готова настройка: виж VPS за MCP сървъри — препоръчаният план и едноминутно crypto разгръщане.