Автор каталога MCP-серверов Unyly, который ранее собрал индекс из 80 тысяч записей из девяти источников, столкнулся с типичной проблемой пользователей: найденный сервер нужно где-то запускать. Добрая половина MCP-серверов живёт не как готовый npm-пакет, а как репозиторий на GitHub, который нужно клонировать, собрать и поддерживать в рабочем состоянии. Для серверов на stdio-транспорте (а таких большинство) требуется дополнительно обернуть их в HTTP, иначе к ним не подключатся ни claude.ai, ни ChatGPT. В результате под сервер на 40 строк человек поднимает VPS, пишет Dockerfile, настраивает nginx, выпускает сертификат и вешает вебхук на автодеплой.
В ответ на это автор добавил в Unyly полноценный раздел деплоя. Пользователь подключает GitHub-репозиторий и получает работающий проект на поддомене slug.unyly.org; пуш в ветку автоматически пересобирает проект. Платформа поддерживает сайты (статика, фронтенд-сборки, Next.js) и MCP-серверы на Node и Python. Архитектура построена на обычных компонентах: GitHub push через вебхук на Next.js API с HMAC-проверкой попадает в очередь runner_deploys (SQLite), откуда демон-воркер забирает задачу, клонирует репозиторий токеном пользователя, генерирует Dockerfile, собирает образ и запускает контейнер с лимитами. Реверс-прокси на порту:3900 маршрутизирует запросы по Host к нужному контейнеру.
| Тип проекта | Базовый образ | Особенности |
|---|---|---|
| MCP-сервер на Node | node:22-slim | Обёртка supergateway, точка входа bin > main > index.js |
| MCP-сервер на Python | python:3.12-slim | Установка Node.js для supergateway, точка входа server.py или main.py |
| Чистая статика | nginx:alpine | Наличие index.html, отсутствие package.json |
| Фронтенд со сборкой | nginx:alpine | npm run build, автоматическое определение выходной папки |
| Next.js | node:22-slim | Запуск next start, определяется по зависимости next |
Ключевая особенность — генерация Dockerfile. Если в репозитории есть собственный Dockerfile, он используется как есть. В противном случае платформа выбирает один из пяти рецептов в зависимости от типа проекта. Для MCP-сервера на Node точка входа ищется в порядке bin > main > index.js из package.json, а stdio-процесс оборачивается в supergateway, который превращает stdin/stdout в streamable HTTP на /mcp. Для Python-серверов используется базовый образ python:3.12-slim, а supergateway (написанный на Node) доставляется через apt-get install nodejs npm. Для сайтов предусмотрены три рецепта: чистая статика на nginx:alpine, фронтенд со сборкой (npm run build с автоматическим определением выходной папки) и Next.js, который запускается через next start.
Новый раздел деплоя позволяет разворачивать сайты и MCP-серверы из GitHub-репозитория.
Запуск контейнеров происходит с жёсткими ограничениями, поскольку это чужой код на железе автора. Политика — минимум ресурсов и прав: docker run с --memory 384m, --cpus 0.5, --pids-limit 256, --cap-drop ALL и --security-opt no-new-privileges. Порт слушается только на localhost, наружу его выставляет реверс-прокси. Исключение сделано для nginx в site-образах: ему возвращаются capabilities CHOWN, SETUID, SETGID, иначе он падает при старте. MCP-контейнеры живут вообще без capabilities.
Healthcheck в Unyly не ограничивается проверкой «процесс поднялся». Для сайтов проверяется HTTP-код 2xx или 3xx на /. Для MCP-серверов выполняется JSON-RPC initialize по протоколу MCP с дедлайном 60 секунд: если в ответе есть "result", сервер говорит на MCP, а не просто открыл порт. При неудаче в лог деплоя выводится последние 40 строк docker logs.
Автор честно перечисляет грабли, на которые потратил время. Одна из важных деталей — прокси и воркер должны быть двумя разными процессами под pm2 (unyly-runner-proxy и unyly-runner-worker), а не одним; это стоило пары часов и всех живых сайтов. Также nginx-конфиг для сайтов с SPA-фолбэком добавляется через COPY, а не генерируется в RUN, из-за проблем с переменной $uri.
Платформа решает реальную проблему дисбаланса усилий: вместо ручного поднятия инфраструктуры пользователь получает деплой в несколько кликов. Это может быть полезно разработчикам, которые хотят быстро протестировать MCP-сервер или развернуть сайт без настройки сервера. Однако остаются вопросы: как платформа будет масштабироваться при росте числа пользователей, какие меры безопасности предусмотрены для изоляции контейнеров, и какова модель монетизации. Автор пока не раскрывает финансовые детали, но упоминает, что это его личный проект.
