Чи потрібен виділений IP, щоб хостити MCP-сервер?

Для публічного HTTPS-ендпоінта — так. На NAT-тарифі проброшено рівно один порт під SSH, а порт 443 назовні не відкрити. Тариф із виділеним IP дає всі порти й домен, який можна спрямувати прямо на машину.

stdio чи HTTP — який транспорт хостити?

HTTP (SSE або новий streamable-HTTP). stdio-сервер спілкується лише з клієнтом на тій самій машині; усе, що має бути доступним по мережі, працює по HTTP за URL.

Чи можна тримати кілька MCP-серверів на одному VPS?

Так. Повісьте кожен на свій локальний порт і дайте кожному свій піддомен у reverse-proxy. Обмеження — оперативна пам'ять, а tool-сервери її майже не споживають.

Скільки оперативної пам'яті потрібно MCP-серверу?

Зазвичай мало. Tool-сервер — це I/O: він чекає на відповідь від API та баз, а не рахує. 1–2 ГБ вистачає більшості. Запускати модель, що сама генерує відповіді, — це окреме й куди важче завдання.

Власний MCP-сервер на VPS — щоб працював завжди

Ви написали MCP-сервер. Локально все добре — агент його викликає, інструменти спрацьовують, усе пов'язано. А потім ви закриваєте ноутбук — і його немає. Якщо сервер має бути доступним будь-якої миті, коли він потрібен агентові — з іншої машини, з чужого сетапу, за розкладом о третій ночі — він мусить жити там, де завжди увімкнено, зі стабільною адресою та HTTPS. Саме для цього й потрібен VPS.

Нижче — як перенести MCP-сервер із ноутбука на машину, якою ви справді керуєте, і чесно про те, куди йдуть сили.

stdio проти remote: що означає «хостити»

MCP-сервери бувають двох видів.

stdio-сервер працює як локальний процес і спілкується з клієнтом на тій самій машині через стандартний ввід/вивід. Поки ви розробляєте — ідеально. Але по мережі до нього не достукатися.

Remote-сервер говорить по HTTP (Server-Sent Events або новий транспорт streamable-HTTP) через URL. Будь-який клієнт, який знає адресу й тримає потрібні креди, може його викликати. Хостити власний MCP-сервер — означає запустити саме remote-варіант десь публічно і стабільно.

Чому не тунель із ноутбука

Технічно домашню машину можна виставити назовні тунелем, і для швидкої демки цього вистачить. Але в усьому, на що ви покладаєтеся всерйоз, ви отримуєте її проблеми: вона йде в сон, провайдер змінює IP, аплоад повільний, а тепер ще й сервіс із бойовими інструментами висить у домашній мережі поруч з усім іншим. VPS дає фіксований публічний IP, нормальний домен, реальний аптайм та ізоляцію. За пару доларів на місяць це прибирає цілий клас питань «чому в агента відпало з'єднання».

Стек покроково

Візьміть маленьку машину. MCP tool-сервер — це переважно I/O: він чекає на API, файли, бази, а не молотить числа. 1–2 ГБ оперативки вистачає більшості. (Ганяти модель усередині, щоб відповідати, — інша історія, див. self-hosting LLM з Ollama.)

Запустіть сервер на localhost — наприклад, Node або Python на 127.0.0.1:3100. Назовні напряму його не виставляйте, цим займеться проксі.

Поставте перед ним reverse-proxy, щоб термінувати TLS на вашому домені. Caddy робить це приблизно в чотири рядки й сам отримує безкоштовний сертифікат:

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

Спрямуйте mcp.yourdomain.com на IP вашого VPS, перезавантажте Caddy — і сервер живе на https://mcp.yourdomain.com по streamable-HTTP.

Щоб працював завжди

Сервер, який помирає під час першого крашу чи перезавантаження, — це не «захостили», це «поки що працює». Загорніть його в 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 з реальними повноваженнями, — і більша частина ризику зникає.

Чесні обмеження

Тепер експлуатація на вас. Оновлення ОС, здоров'я процесу, логи. Сертифікат Caddy продовжує сам, решта — ваша. Managed-функція в хмарі це ховає; VPS віддає вам в обмін на контроль і куди менший рахунок.
Специфікація MCP ще рухається. Транспорти та схеми авторизації змінюються від релізу до релізу. Зафіксуйте версію SDK і будьте готові інколи оновлюватися.
CPU-машина гарна для tool-серверів, а не для генерації відповідей локальною моделлю. Якщо сервер запускає LLM, щоб відповідати, — це окрема й важча машина, див. гайд з Ollama.
Ніколи не виставляйте руйнівні інструменти без авторизації та кроку підтвердження. Відкритий інструмент, що щось видаляє, рано чи пізно зустріне бота, який сканує все підряд.

Як платити

Реєстрація за email, оплата в USDC чи USDT — без картки й без документів. А якщо ви піднімаєте це для агента, таку саму машину можна замовити та оплатити програмно через наш власний MCP-сервер: агент реєструється, поповнює баланс і замовляє сам.

Захостіть сервер один раз — і ваші інструменти на місці щоразу, коли за ними тягнеться агент.