Deploy Watch: автоматический возврат при сбое проверок после релиза
Релиз может пройти проверку при запуске и сломаться через минуту. Процесс ещё работает, но его endpoint готовности уже отвечает ошибкой.
Deploy Watch добавляет короткое окно автоматических проверок после подходящего деплоя. При повторных сбоях Upferry пытается запустить и проверить предыдущий образ, прежде чем вернуть на него трафик.
v1: 200✓ Проверка до переключенияv2: 500× Три сбоя подрядЧто происходит после релиза
Upferry проверяет настроенный healthcheck примерно каждые 15 секунд в течение 10 минут. Успешный ответ сбрасывает счётчик сбоев. Три сбоя подряд запускают одну попытку возврата.
Предыдущий образ закрепляется от обычной очистки. Его процесс останавливается после штатной передачи трафика новому деплою. При возврате Upferry запускает именно этот образ без пересборки, проверяет его, переключает трафик и подтверждает выбранный маршрут.
На запуск старого образа нужно время. Обнаружение ошибки и запуск могут увеличить период недоступности. Если образ пропал, ресурсов не хватает или проверка не прошла, панель сообщает, что возврат не подтверждён.
Как включить
Открой сервис, перейди в Settings и раскрой Deploy Watch. Настройка общая для окружений сервиса, а каждая проверка относится к конкретному деплою в конкретном окружении.
- Настрой healthcheck, который действительно отражает нужную готовность приложения.
- Подтверди требования к приложению и включи Deploy Watch.
- Выложи рабочую версию для сравнения, затем изменение только кода с той же конфигурацией запуска.
Первая версия подходит одному HTTP-экземпляру без volume, cron и команды перед деплоем. Нужна подходящая предыдущая здоровая версия. Включение настройки не защищает уже работающий релиз задним числом.
Совместимость подтверждает владелец
Нужно подтвердить, что запуск не выполняет миграции базы и не включает потребителей очередей, таймеры и другие фоновые действия с побочными эффектами. Две версии должны безопасно работать одновременно короткое время. Текущая база, принятые записи и связанные сервисы должны оставаться совместимыми с предыдущим кодом.
Это требования к приложению, которые подтверждает владелец. Upferry не может доказать их проверкой произвольного Docker-образа. Возврат образа не отменяет изменения схемы, действия покупателей, платежи и внешние запросы.
Deploy Watch возвращает один сервис. Согласованный откат всего проекта он не выполняет.
Действующие настройки сохраняются
Deploy Watch не возвращает старые секреты и не ослабляет сетевую политику. Для подходящего релиза действующие настройки запуска и переменные совпадают с рабочей версией для сравнения.
Новый деплой, ручное действие с жизненным циклом или изменение соответствующей конфигурации отменяет прежнюю проверку. Её состояние переживает перезапуск воркера. Перед подтверждением возврата Upferry проверяет, что попытка всё ещё относится к текущему деплою.
Что именно проверяется
Запрос идёт к выбранной версии напрямую, а при ограниченной сети использует её существующий разрешённый вход. Endpoint, который всегда отвечает 200, не обнаружит сломанную оплату, обработку фотографий или вход.
Публичные DNS, TLS, ошибки прокси и функции вне выбранного endpoint не проверяются. Окно Deploy Watch заканчивается и не заменяет постоянный мониторинг. В истории сервиса видны сбои, этапы возврата и причина отмены или неуспеха. Настроенные каналы уведомлений могут сообщить результат.
Что есть у Railway
Railway описывает healthcheck до публикации деплоя и прямо указывает, что после запуска эти проверки не продолжаются. В действиях с деплоем есть ручной rollback.
В публичной документации, проверенной 27 октября 2026 года, мы не нашли такого встроенного сценария наблюдения после релиза с автоматическим возвратом. Похожую автоматику можно собрать из мониторинга, скриптов и API Railway.