[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"docs-infra\u002Fgalaxy":3,"docs-tabs-infra\u002Fgalaxy":6},{"content":4,"lastmod":5},"\n# Galaxy-приложение\n\nGalaxy-приложение — это отдельное приложение Black Hole, которое живёт в контейнере на общем хосте — галактике — вместе с другими такими же приложениями. Каждое приложение получает свой HTTPS-субдомен и изоляцию, как у отдельной виртуальной машины, но все они делят одну галактику — это кратно дешевле, чем держать отдельный сервер под каждое приложение. Если администратор портала включил размещение в галактиках, тот же вызов `POST \u002Fv1\u002Finfra\u002Fservers` создаёт galaxy-приложение, а не виртуальную машину.\n\n**Скоуп:** `vibe:infra` · **Базовый URL:** `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1` · **Авторизация:** заголовок `X-Api-Key`\n\n## Кто выбирает модель размещения\n\nРежим размещения выбирает администратор портала в кабинете на странице «Галактики», в разделе «Размещение». Обычный участник портала видит режим только для чтения, а вызывающий API его не задаёт. Один и тот же запрос `POST \u002Fv1\u002Finfra\u002Fservers` создаёт либо отдельную виртуальную машину, либо galaxy-приложение, в зависимости от режима портала. Параметра «создать именно galaxy-приложение» в запросе нет.\n\nРежим портала — один из трёх:\n\n- **Сначала галактика** (`galaxies-only`) — новые приложения размещаются плотно внутри галактик. Если приложение перерастает свой контейнер, его переносят на отдельный сервер Black Hole.\n- **Гибридный** (`both`) — приложение попадает в галактику, когда в ней есть место, иначе разворачивается на отдельной виртуальной машине.\n- **Отдельные серверы** (`standalone-only`) — галактики не используются, каждое приложение получает свою виртуальную машину.\n\nЧто с этим делать вызывающему:\n\n- **Определяйте модель по ответу, а не задавайте её.** Признак galaxy-приложения — поле `createdVia` равно `galaxy` в ответе создания. Полный список признаков — в разделе «Как отличить galaxy-приложение в ответе» ниже.\n- **Нужна именно отдельная виртуальная машина — запросите её явно.** Если портал размещает приложения в галактиках, но конкретному приложению нужен выделенный сервер, передайте в теле [`POST \u002Fv1\u002Finfra\u002Fservers`](.\u002Fservers\u002Fcreate.md) поле `placement` равным `dedicated` — платформа создаст отдельную виртуальную машину вместо galaxy-приложения. По умолчанию `placement` равен `auto`, и применяется настройка портала.\n\nГотовность у моделей разная:\n\n- **Отдельная виртуальная машина** — по `status: \"running\"` и `blackholeStatus: \"CONNECTED\"`.\n- **Galaxy-приложение** — только через загрузку кода, ожидание `CONNECTED` здесь не работает (см. «Жизненный цикл» ниже).\n\n## Как отличить galaxy-приложение в ответе\n\n| Поле | Где | Значение |\n|------|-----|----------|\n| `createdVia` | ответ [`POST \u002Fv1\u002Finfra\u002Fservers`](.\u002Fservers\u002Fcreate.md) | `galaxy` для galaxy-приложения |\n| `kind` | ответ `POST \u002Fv1\u002Finfra\u002Fservers` и [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`](.\u002Fservers\u002Fget.md) | `GALAXY_APP` — galaxy-приложение (контейнер), `GALAXY` — галактика (хост-носитель), `STANDALONE` — отдельная виртуальная машина |\n| `galaxyId` | ответ `POST \u002Fv1\u002Finfra\u002Fservers` и [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`](.\u002Fservers\u002Fget.md) | ID галактики, в которой размещено приложение. Для остальных типов `null` |\n| `appCount` | ответ [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`](.\u002Fservers\u002Fget.md) | Для галактики (`GALAXY`) — число работающих в ней приложений. Для остальных типов `null` |\n\nУ galaxy-приложения нет своего SSH-доступа (`ssh` равно `null`), публичного IP-адреса и внешнего идентификатора виртуальной машины — у контейнера их нет. Поля `region` и `plan` в ответе — это регион и тариф галактики-носителя: переданные при создании значения ни на что не влияют, размещение платформа выбирает сама.\n\n## Жизненный цикл — сборка при загрузке кода\n\nGalaxy-приложение **никогда** само не доходит до `blackholeStatus: \"CONNECTED\"`. Его контейнер и агент туннеля создаёт сама загрузка кода — отдельного шага провижининга, как у виртуальной машины, здесь нет.\n\nИз этого следует главное правило: **загружайте код сразу после создания, не дожидаясь `CONNECTED`.** Если создать galaxy-приложение и просто опрашивать статус, оно останется в `provisioning`, а примерно через 20 минут платформа пометит его как `error` и запишет в поле `provisionError`, что код так и не был загружен.\n\n## Создание и загрузка кода\n\nСоздание идёт тем же вызовом [`POST \u002Fv1\u002Finfra\u002Fservers`](.\u002Fservers\u002Fcreate.md). Код загружают одним из двух сценариев.\n\n- **Сценарий 1 — одним запросом.** Передайте код в поле `source` вместе с `runtime` и `start` прямо в `POST \u002Fv1\u002Finfra\u002Fservers`. Сборка пойдёт в фоновом режиме, отдельный вызов загрузки не нужен.\n- **Сценарий 2 — в два шага.** Создайте приложение без `source`, получите в ответе `next: \"deploy\"`, затем загрузите код через [`POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdeploy`](.\u002Fdeploy\u002Fdeploy.md). Создание без `source` требует `provider`\u002F`plan`\u002F`region` (для galaxy они информационны — см. [пример в create.md](.\u002Fservers\u002Fcreate.md)).\n\nПолные тела запросов, поля и примеры для обоих сценариев — на странице [Создать сервер](.\u002Fservers\u002Fcreate.md).\n\nСоздание galaxy-приложения по сценарию 1 — `source` передан, сборка идёт в фоне. Признак модели — `createdVia` равно `galaxy`:\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"id\": \"7c2b1f08-3a4d-4e91-9b6c-2f5e8a1d0c33\",\n    \"status\": \"provisioning\",\n    \"name\": \"my-crm-app\",\n    \"kind\": \"GALAXY_APP\",\n    \"galaxyId\": \"\u003Cgalaxy-host-id>\",\n    \"ssh\": null,\n    \"ip\": null,\n    \"plan\": \"bc-medium\",\n    \"region\": \"ru-central1-a\",\n    \"mode\": \"BLACKHOLE\",\n    \"createdVia\": \"galaxy\",\n    \"subdomain\": \"app-7c2b1f08\",\n    \"blackholeStatus\": \"NONE\",\n    \"appUrl\": \"https:\u002F\u002Fapp-7c2b1f08.vibecode.bitrix24.tech\",\n    \"createdAt\": \"2026-04-22T10:50:11.477Z\"\n  }\n}\n```\n\n## Деплой\n\nДеплой galaxy-приложения отличается от деплоя виртуальной машины. Полный контракт — на странице [Деплой приложения](.\u002Fdeploy\u002Fdeploy.md).\n\n- Источник кода — только встроенный `source.content` (архив в base64). Варианты `source.url` и `source.versionId` отклоняются с `400 GALAXY_DEPLOY_CONTENT_ONLY`.\n- Поля `runtime` и `start` обязательны. Без `runtime` запрос вернёт `400 GALAXY_DEPLOY_RUNTIME_REQUIRED`. Список рантаймов — [`GET \u002Fv1\u002Finfra\u002Fruntimes`](.\u002Fdeploy\u002Fruntimes.md).\n- Свой `Dockerfile` класть не нужно — платформа генерирует его из полей `runtime`, `port` и `start`.\n- Переменные `env` подставляются в контейнер при запуске, а не вшиваются в образ, поэтому секреты не попадают в слои образа.\n- Рабочая директория контейнера — `\u002Fopt\u002Fapp`, путь `\u002Fapp` тоже ведёт на неё как ссылка. Постоянные данные сохраняйте в томе `\u002Fdata`.\n\n## Стоимость\n\nСтоимость считается за галактику, а не за каждое приложение. Несколько galaxy-приложений в одной галактике делят её стоимость — пять приложений на тарифе `bc-small` обходятся примерно как одна галактика, а не как пять серверов. В лимит серверов на API-ключ (`GET \u002Fv1\u002Fme` → `infra.limits.used`) galaxy-приложения не входят — он считает только отдельные виртуальные машины.\n\n## Логи\n\nДля galaxy-приложения [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Flogs`](.\u002Fdeploy\u002Flogs.md) возвращает поток вывода самого контейнера (`stdout` и `stderr`), а не системный журнал галактики. Чтение логов не будит спящую галактику. Если галактика спит или недоступна, ответ — пустой массив `data.logs` плюс диагностическое поле `data.hint`. Параметр `since` для galaxy-приложения принимает только длительность (`10m`, `2h`, `24h`) или метку времени в формате RFC 3339 (например, `2026-04-22T10:50:11Z`).\n\n## Удаление\n\nGalaxy-приложение снимается тем же вызовом [`DELETE \u002Fv1\u002Finfra\u002Fservers\u002F:id`](.\u002Fservers\u002Fdelete.md) — платформа разбирает его контейнер в галактике и помечает запись удалённой. Спящую галактику платформа будит сама перед удалением. Галактика с работающими приложениями этим вызовом не удаляется — сначала снимите её приложения.\n\n## Коды ошибок\n\n| HTTP | Код | Описание |\n|------|-----|----------|\n| 400 | `SOURCE_AT_CREATE_GALAXY_ONLY` | Поле `source` передано при создании на портале без режима галактик. Загружайте код через [`POST \u002F:id\u002Fdeploy`](.\u002Fdeploy\u002Fdeploy.md) после создания |\n| 400 | `GALAXY_DEPLOY_CONTENT_ONLY` | Деплой galaxy-приложения с `source.url` или `source.versionId`. Источник — только встроенный `source.content` |\n| 400 | `GALAXY_DEPLOY_RUNTIME_REQUIRED` | Деплой galaxy-приложения без `runtime`. Укажите рантайм, например `node20` |\n| 502 | `GALAXY_APP_BUILD_FAILED` | Сборка контейнера не удалась. Хвост лога сборки приходит в поле `buildLog` |\n| 502 | `GALAXY_APP_START_FAILED` | Контейнер собрался, но упал или ушёл в перезапуск по нехватке памяти сразу после старта. Хвост лога приходит в поле `buildLog` |\n| 409 | `GALAXY_HAS_APPS` | Удаляемый сервер — галактика, на которой ещё работают приложения. Тело содержит `appCount` |\n| 502 | `GALAXY_HOST_UNREACHABLE` | Галактика недоступна, и её не удалось разбудить. Повторите чуть позже |\n\nПолный справочник общих ошибок API — [Ошибки](\u002Fdocs\u002Ferrors).\n\n## Смотрите также\n\n- [Создать сервер](.\u002Fservers\u002Fcreate.md)\n- [Деплой приложения](.\u002Fdeploy\u002Fdeploy.md)\n- [Логи сервера](.\u002Fdeploy\u002Flogs.md)\n- [Удалить сервер](.\u002Fservers\u002Fdelete.md)\n- [Инфраструктура](\u002Fdocs\u002Finfra)\n","2026-07-07",{}]