- Репозиторий целиком — в промпт попадают только ревьюируемые изменения и файлы, до которых они дотягиваются
- Всё, чего изменения не касаются, и всё, что исключено ключом ignore или маркером внутри файла
- Токен GitLab или GitHub и секрет вебхука
- История коммитов, другие MR/PR, пайплайны и их логи
Код не покидает
ваш контур.
ReviewGate ставится on-prem в вашем контуре. Вендор никогда не получает ваш код или дифф. С self-hosted-площадкой единственное исходящее соединение — к модели, которую выбрали вы, а локальная модель убирает и его. На github.com бот дополнительно ходит на api.github.com — это ваш же хостинг, а не новый получатель. Всё исходящее перечислено ниже.
- Промпт ревью — всегда дифф ревьюируемых файлов, ваши правила из config.yml и метаданные MR/PR (заголовок, автор, ветки, описание, ссылка) — только к LLM, которую выбрали вы, и по вашему ключу
- Что добавляют настройки: изменённые файлы целиком и импортируемые ими определения (когда работает судья или включён llm.full_file_context), версии стека из ваших манифестов (llm.environment_context) и — в режиме ответов — реплики треда со строками кода вокруг обсуждаемой
- С локальной LLM (Ollama, vLLM) наружу не уходит вообще ничего
Один контур, одно исходящее по умолчанию
Промпт ревью — дифф, ваши правила и метаданные MR/PR, плюс то, что добавляют настройки, — уходит только к выбранной вами LLM. Облачная получает его по вашему ключу; с локальной (Ollama, vLLM) из контура не выходит ничего. ReviewGate-вендор в этой схеме не участвует и кода не видит.
Что хранится, а что — никогда
- Число замечаний и их severity
- Статусы ревью и severity gate
- Израсходованные токены LLM
- Всё — в вашей БД, автоочистка через 90 дней
- Исходный код и дифф
- Содержимое файлов
- Тексты замечаний с фрагментами кода
Полный перечень — и как свести к нулю
Выбранная вами LLM
Исходящее соединение ревью — и только если LLM облачная. Endpoint и ключ — ваши. Локальная модель его убирает; на github.com остаётся api.github.com, потому что там живут сами pull request’ы.
Реестр образов (только при обновлении)
Pull нового образа — только по инициативе вашего девопса. В рантайме ревью не используется; для закрытого контура возможна поставка файлом.
Лицензия — офлайн
Проверяется вшитым публичным ключом локально. Никаких обращений «домой» — работает и в air-gapped-контуре.
- Вебхук подписан секретом; токен сверяется сравнением постоянного времени.
- Токен GitLab или GitHub и ключ LLM живут в вашем
.envв вашем контуре. - Лицензия проверяется офлайн вшитым публичным ключом — без звонков домой.
- Никакого нового субобработчика: код не уходит никому, кроме провайдера модели, которого вы выбрали сами и с которым у вас уже есть договор.
- Ни телеметрии, ни звонков домой — в сторону вендора нечего вносить в allow-лист.
- Air-gapped целиком: с self-hosted-площадкой и локальной моделью инсталляция работает при запрещающем правиле на исходящий трафик.
Частые вопросы
Уходит ли наш код к вам, вендору?
Нет. ReviewGate работает on-prem в вашем контуре и не получает ваш код или дифф. Мы видим только метаданные ревью, если вы сами их пришлёте для поддержки.
А в облако LLM?
Промпт ревью уходит только к той LLM, которую выбрали вы, и по вашему ключу. В нём дифф, ваши правила и метаданные MR/PR; настройки могут добавить изменённые файлы целиком с их импортируемыми определениями, версии вашего стека и — в режиме ответов — реплики треда. Точный список выше. Хотите ноль исходящих — поднимите локальную модель (Ollama или vLLM), бот это поддерживает.
Что вы храните?
Только метаданные: число замечаний, severity, статусы, израсходованные токены — в вашем же Postgres, с автоочисткой через 90 дней (по этим метрикам удобно смотреть пользу бота и то, что отбрасывает судья). Код и дифф — никогда: бот не пишет их ни в логи, ни в базу, и это видно в исходниках.
Можно ли работать полностью офлайн?
Да, на self-hosted-площадке: локальная LLM + офлайн-проверка лицензии дают инсталляцию без единого исходящего соединения. На github.com это невозможно в принципе — сами pull request’ы живут вне вашего контура.
Что будет, если сломается судья или БД?
Ревью доедет всё равно — движок сквозной fail-open: сбой судьи публикует находки первого прохода, ошибки БД метрик дают только предупреждение в логах, недоступный код-контекст откатывает на дифф, неопубликованный статус проверки игнорируется. Ни одна побочная подсистема не валит ревью.
Кто имеет доступ к токену GitLab или GitHub?
Токен живёт в вашем .env в вашем контуре. Мы его не видим и не получаем.
Насколько изолирован контейнер бота?
Образ запускается от non-root, с файловой системой только на чтение, снятыми Linux-капабилити (cap_drop ALL) и no-new-privileges. Внутрь штатно не залезть, а при компрометации зависимости — не закрепиться и не записать на диск. Полностью закрыть контейнер от root-администратора самого хоста нельзя (это устройство Docker, а не наша недоработка) — но всё нужное наблюдается снаружи, заходить внутрь не требуется.
Как получить логи для диагностики, не вскрывая контейнер?
Логи пишутся на хост и читаются снаружи: docker compose logs -f app (или выгрузка в файл одной командой). В них только метаданные ревью — модели, severity, токены; кода и диффа там нет. Логи остаются у вас и нам не уходят.
Проверьте сами
Всё, что описано выше, проверяется на вашей же инсталляции: поднимите бот в своём контуре и посмотрите, что уходит наружу, а что остаётся внутри.