Hostuj własny serwer MCP na VPS

Napisałeś serwer MCP. Lokalnie działa dobrze — Twój agent go woła, narzędzia odpalają, wszystko podłączone. Potem zamykasz laptop i znika. Jeśli chcesz, by ten serwer był osiągalny, gdy Twój agent go potrzebuje — z innej maszyny, z konfiguracji kolegi, z zaplanowanego zadania o 3 nad ranem — musi żyć gdzieś, co jest zawsze włączone, ze stabilnym adresem i HTTPS. Do tego służy VPS.

Oto jak przenieść serwer MCP z laptopa na maszynę, którą faktycznie kontrolujesz, z uczciwymi uwagami o tym, gdzie idzie wysiłek.

Lokalnie vs zdalnie: co „hosting” właściwie oznacza

Serwery MCP przychodzą w dwóch kształtach.

Serwer stdio działa jako lokalny proces i rozmawia z klientem na tej samej maszynie przez standardowe wejście/wyjście. Jest idealny, gdy budujesz — ale nie może być osiągnięty przez cokolwiek przez sieć.

Serwer zdalny mówi w HTTP (Server-Sent Events lub nowszy transport streamable-HTTP) przez URL. Dowolny klient, który zna URL i trzyma właściwe dane uwierzytelniające, może go wywołać. Hostować własny serwer MCP oznacza uruchamianie rodzaju zdalnego gdzieś publicznie i stabilnie.

Dlaczego nie po prostu tunelować laptopa

Technicznie możesz wystawić domową maszynę tunelem, i do szybkiego dema jest to w porządku. Dla czegokolwiek, na czym polegasz, dziedziczysz problemy maszyny: zasypia, Twój ISP rotuje IP, upload jest wolny, a teraz usługa pełna prawdziwych narzędzi siedzi w Twojej domowej sieci obok wszystkiego innego. VPS daje Ci stałe publiczne IP, prawdziwą domenę, właściwą dostępność i izolację. Za kilka dolarów miesięcznie usuwa całą kategorię pytań „czemu mój agent stracił połączenie”.

Stos, konkretnie

Wybierz małą maszynę. Serwer narzędzi MCP to głównie I/O — czeka na API, pliki i bazy danych; nie robi ciężkiej matematyki. 1–2 GB RAM w zupełności wystarczy dla większości. (Uruchamianie modelu inline, by odpowiedzieć, to inna historia — zobacz samodzielny hosting LLM z Ollamą.)

Uruchom serwer związany z localhost, powiedzmy Node lub Python nasłuchujący na 127.0.0.1:3100. Trzymaj go bezpośrednio z dala od publicznego interfejsu — proxy to obsłuży.

Postaw z przodu reverse proxy, by zakończyć TLS na Twojej domenie. Caddy robi to w około czterech liniach i automatycznie pobiera darmowy certyfikat:

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

Skieruj mcp.yourdomain.com na IP swojego VPS, przeładuj Caddy, a Twój serwer działa pod https://mcp.yourdomain.com przez streamable-HTTP.

Utrzymaj go zawsze włączonym

Serwer, który umiera przy pierwszej awarii lub restarcie, nie jest „hostowany” — jest „działający na razie”. Owiń go w jednostkę systemd, by restartował się przy awarii i wracał po restarcie:

[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 i jest naprawdę zawsze włączony. (Ten sam wzorzec utrzymuje dowolnego agenta lub bota przy życiu 24/7.)

Część, którą ludzie pomijają: potrzebujesz osiągalnego portu

Publiczny punkt końcowy MCP potrzebuje portu przychodzącego — 443 — osiągalnego z internetu. Na planie NAT dostajesz dokładnie jeden przekierowany port dla SSH i nic więcej; nie możesz otworzyć 443 na świat. By hostować publiczny serwer MCP HTTPS, chcesz planu z dedykowanym IP, gdzie każdy port jest Twój i możesz skierować domenę prosto na maszynę. To różnica między „mój agent na tym samym laptopie może go osiągnąć” a „dowolny klient gdziekolwiek może”.

Zablokuj to — to API z uprawnieniami

Serwer MCP zwykle udostępnia narzędzia, które robią rzeczy: czytają pliki, uderzają w płatne API, przenoszą pieniądze. Nie umieszczaj tego na otwartym internecie nago.

• Wymagaj tokenu przy każdym wywołaniu. Odrzucaj anonimowe żądania; sprawdzaj token bearer lub klucz API, zanim jakiekolwiek narzędzie się uruchomi.
• Odgródź zaporą wszystko oprócz 443 i Twojego portu SSH.
• SSH tylko klucze, bez logowania hasłem. (Oto lista kontrolna na dziesięć minut.)

Traktuj punkt końcowy jak to, czym jest — API z prawdziwą władzą — a większość ryzyka znika.

Uczciwe granice

• Teraz Ty jesteś właścicielem operacji. Aktualizacje systemu, utrzymywanie procesu zdrowym, obserwowanie logów. Caddy odnawia certyfikat za Ciebie, ale reszta jest Twoja. Zarządzana funkcja chmurowa to ukrywa; VPS wręcza Ci to w zamian za kontrolę i znacznie niższy rachunek.
• Specyfikacja MCP wciąż się porusza. Transporty i wzorce uwierzytelniania zmieniają się z wydania na wydanie. Przypnij wersję SDK i spodziewaj się jej aktualizowania od czasu do czasu.
• Maszyna CPU jest właściwa dla serwerów narzędzi, nie do generowania odpowiedzi lokalnym modelem. Jeśli Twój serwer uruchamia LLM, by odpowiadać, to osobna, cięższa maszyna — zobacz przewodnik Ollama.
• Nigdy nie wystawiaj destrukcyjnych narzędzi bez uwierzytelniania i kroku potwierdzenia. Otwarte narzędzie, które usuwa rzeczy, w końcu spotka bota, który skanuje wszystko.

Płacenie za to

Zarejestruj się e-mailem i płać w USDC lub USDT — bez karty, bez dokumentu. A jeśli podłączasz to dla agenta, ten sam rodzaj maszyny może być zamówiony i opłacony programowo przez nasz własny serwer MCP — agent rejestruje się, zasila saldo i zamawia sam.

Zahostuj serwer raz, a Twoje narzędzia są tam, gdy agent po nie sięga.

Gotowa konfiguracja: zobacz VPS dla serwerów MCP — zalecany plan i minutowe wdrożenie za krypto.