Хостинг и облачные ресурсы

Хостинг нужен, чтобы приложение продолжало работать в интернете независимо от Превью и открытого рабочего пространства. На сервере можно разместить frontend, backend, API, фоновые процессы и всю необходимую проекту инфраструктуру.

Что можно развернуть

На облачном сервере агент может разместить:

• многостраничный сайт или full-stack приложение;
• backend, REST- или GraphQL API;
• WebSocket-сервер;
• Telegram-бота, webhook или интеграционный сервис;
• фоновые workers, очереди и задачи по расписанию;
• несколько связанных сервисов через Docker Compose;
• PostgreSQL, Redis, поисковый движок или другой сервер данных;
• собственное S3-совместимое хранилище, например MinIO;
• Nginx или Caddy для маршрутизации запросов;
• сбор логов, метрик и резервных копий.

Агент может подобрать операционную схему под конкретный проект: один процесс, несколько systemd-служб, набор Docker-контейнеров или комбинацию этих вариантов.

Домены и HTTPS

Для сервера выдаётся публичный IP-адрес. После этого агент может:

1. настроить Nginx или Caddy перед приложением;
2. привязать основной домен и нужные поддомены;
3. направить разные домены на разные сервисы или порты;
4. подготовить DNS-записи для регистратора;
5. выпустить и подключить сертификат;
6. включить HTTPS и автоматическое продление сертификата.

Домен можно купить у любого регистратора. Если управление DNS находится во внешнем сервисе, агент сообщит точные записи, которые нужно добавить, либо выполнит настройку через подключённый доступ.

Если вы не знаете, что выбрать

Например, можно спросить:

• «Нужен ли этому проекту облачный сервер или достаточно статической публикации?»
• «Что потребуется, чтобы приложение работало круглосуточно?»
• «Где лучше хранить пользовательские изображения?»
• «Нужен ли нам PostgreSQL и где его лучше разместить?»
• «Стоит ли создать отдельное S3-хранилище или развернуть своё?»
• «Как подключить уже существующую внешнюю базу данных?»
• «Подключи мой домен и включи HTTPS».

Можно начать не с команды, а с вопроса: агент сначала объяснит назначение сервера, базы данных, S3 и остальных компонентов, а затем предложит конкретный план.

PostgreSQL и S3: что это и зачем

PostgreSQL — реляционная база данных для пользователей, заказов, настроек, прав доступа и других структурированных данных приложения.

S3 — объектное хранилище для изображений, видео, документов, экспортов и резервных копий. Оно не заменяет PostgreSQL: база хранит структуру и связи, а S3 — сами файлы.

Для каждого ресурса доступны три подхода.

Подход	Как устроен	Что даёт
Расширение Promto	PostgreSQL или S3 создаётся как отдельный управляемый ресурс в Хостинге. Данные подключения автоматически становятся доступны серверу и агенту.	Быстрый запуск, отдельные ресурсы, управление состоянием и операциями из интерфейса Promto.
Свой ресурс на сервере	Агент устанавливает PostgreSQL либо S3-совместимое хранилище прямо на VM — нативно или через Docker.	Полный выбор версии, расширений, структуры каталогов, конфигурации и способа запуска. Всё находится на одном сервере и использует его CPU, память и диск.
Внешний сервис	Используется уже существующая база или S3 у другого провайдера. Агент подключает endpoint или строку соединения к приложению.	Можно сохранить существующие данные, использовать функции выбранного провайдера и масштабировать ресурс отдельно от сервера приложения.

Когда выбрать расширение Promto

• Нужно быстро получить готовый PostgreSQL или S3.
• Ресурс должен жить отдельно от сервера приложения.
• Нужно видеть его состояние и доступные операции в Хостинге.
• Агент должен получить параметры подключения автоматически.

Когда развернуть свой ресурс

• Нужна конкретная версия PostgreSQL или набор расширений.
• Требуется особая конфигурация.
• Удобно держать приложение и данные на одной VM.
• Вы хотите, чтобы агент полностью управлял установкой, обновлением, резервированием и запуском.

Для собственного S3 агент обычно разворачивает S3-совместимый сервер, например MinIO. Приложение продолжает работать через привычный S3 API, но endpoint указывает на ваш облачный сервер.

Когда подключить внешний ресурс

• База или хранилище уже существуют.
• Один ресурс используется несколькими приложениями.
• Нужны функции или тариф выбранного внешнего провайдера.
• База данных или S3 должны масштабироваться независимо от VM приложения.

Внешний PostgreSQL или S3 не нужно переносить в Promto. Передайте агенту задачу на подключение: он настроит переменные окружения, клиентскую библиотеку, миграции и проверит соединение из приложения.

Как проходит публикация

1. Попросите агента изучить проект и предложить схему размещения.
2. Агент определит, нужен ли сервер, PostgreSQL, S3 или другие расширения.
3. Выберите предложенную конфигурацию и подтвердите создание ресурсов.
4. Агент подключится к VM с root-доступом.
5. Он установит зависимости, перенесёт проект, выполнит миграции и запустит процессы.
6. При необходимости агент добавит домен, reverse proxy и HTTPS.
7. После запуска он проверит службы, логи и публичный адрес приложения.

На один проект предусмотрен один основной облачный сервер. При этом внутри него агент может запустить несколько приложений, workers и вспомогательных сервисов.

Инструкции и CLI для агента

Перед созданием ресурса, публикацией, подключением домена, DNS или HTTPS главный агент обязан загрузить Promto Publish Capability — topic publish — через встроенный вызов get_instruction({ topic: "publish" }). get_instruction не является командой shell.

После загрузки инструкции главный агент использует доверенный CLI promto-publish. Основные команды:

promto-publish presets servers
promto-publish presets databases
promto-publish presets storage
promto-publish addon-check --type vm --preset-id <preset-id> --service <имя> --marker-only
promto-publish deploy <имя> --type vm --preset-id <preset-id>
promto-publish addon-check --type database --framework postgresql --preset-id <preset-id> --service <имя> --marker-only
promto-publish deploy <имя> --type database --framework postgresql --preset-id <preset-id>
promto-publish addon-check --type s3 --framework hot --preset-id <preset-id> --service <имя> --marker-only
promto-publish deploy <имя> --type s3 --framework hot --bucket-type private --preset-id <preset-id>
promto-publish detail <ресурс>
promto-publish status <ресурс>
promto-publish logs <ресурс>

Точные параметры агент выбирает из результатов presets, а не придумывает. Для одиночного дизайн-сайта существуют отдельные команды promto-publish site publish, promto-publish site detail и promto-publish site domain; полноценное приложение и VM публикуются по runbook Хостинга.

После выдачи VM агент работает с root-доступом через SSH и применяет подходящие системные CLI: systemctl, docker/docker compose, nginx или caddy, certbot и curl. Это обычные инструменты сервера, не команды Promto. Публичный URL главный агент проверяет встроенным инструментом promto_screenshot, который также не является CLI.

Терминальный агент сначала загружает актуальный runbook командой promto publish get-instruction, затем использует wrapper promto publish .... Standalone-эквивалент — promto-publish ....

Готовый промпт для агента

До любых действий вызови get_instruction по теме publish. Изучи проект и сначала предложи схему: VM, управляемый PostgreSQL или S3, собственный ресурс на VM либо внешний сервис. Для доступных конфигураций и создания ресурсов используй только promto-publish presets, addon-check, deploy, detail и status с параметрами из актуального runbook. После выдачи VM подключись как root по SSH, разверни приложение, настрой процессы, домен, reverse proxy и HTTPS. Проверь службы и соединения через системные CLI, затем проверь публичный пользовательский сценарий через promto_screenshot. Не считай одно создание ресурса готовой публикацией.

Подключение ресурсов к приложению

Созданные через Promto расширения можно передать агенту из карточки ресурса. После этого он:

• добавит параметры подключения в конфигурацию приложения;
• установит нужный драйвер или SDK;
• создаст таблицы и выполнит миграции;
• настроит загрузку файлов в S3;
• свяжет frontend, backend и фоновые процессы;
• перезапустит службы с новой конфигурацией.

Точно так же подключаются внешние ресурсы: отличается только источник endpoint и параметров соединения.

Как понять, что всё работает

Агент проверяет результат на нескольких уровнях:

1. процессы и контейнеры запущены;
2. приложение отвечает внутри сервера;
3. домен открывается по HTTPS;
4. backend подключается к PostgreSQL;
5. загрузка и чтение файлов через S3 работают;
6. основной пользовательский сценарий проходит по публичному адресу.

Создание VM, базы или бакета — это только создание ресурса. Итогом публикации считается работающее приложение по публичному адресу.

Если что-то нужно изменить

Можно вернуться в чат и попросить агента:

• выпустить новую версию;
• добавить ещё один сервис или worker;
• изменить домен;
• перевыпустить сертификат;
• подключить внешнюю базу;
• перенести PostgreSQL или S3 на отдельный ресурс;
• обновить Docker, runtime или системные пакеты;
• изменить reverse proxy;
• найти причину ошибки по логам;
• восстановить SSH-доступ к VM.

Старые публикации App Platform нельзя повторно выпустить из этого интерфейса: для миграции используется поддержка. Публикации одиночных дизайн-файлов выполняются в Промто Дизайн, а не в Хостинге.