RevampIT сейчас работает как self-host-приложение на Hetzner по адресу revampit.orangecat.ch. Публичный домен revamp-it.ch всё ещё указывает на старый сайт Joomla/Apache и поэтому не является продакшен-целью новой платформы.
Напрашивался вопрос: нужны ли нам Coolify, Dokploy или другой слой Platform-as-a-Service? Наш ответ на данный момент — нет. Не потому что такие инструменты плохи, а потому что они не решают первую проблему.
Сама проблема проще: деплой должен быть воспроизводимым, иметь чёткий гейт качества, откатываться при ошибке и делать видимым, какая версия сейчас работает. Эти свойства наша существующая структура из Caddy, systemd и rsync может получить напрямую, без установки новой control plane на тот же продакшен-сервер.
Поэтому мы сначала усиливаем существующий путь. Скрипт деплоя по-прежнему собирает standalone-артефакт Next.js, копирует его на сервер Hetzner и перезапускает сервис. Новшество в том, что перед активацией сохраняется предыдущий релиз. Если сервис не запускается или /api/health не отдаёт успешный статус, происходит автоматический откат.
Дополнительно появился эндпоинт /api/version. Он показывает версию приложения, Git-SHA и время сборки. Это мелочь, но важная: эксплуатация и мониторинг нуждаются в однозначном ответе на вопрос, что на самом деле работает вживую.
При этом одна деталь оказалась решающей: рантайм-файлы вроде .env и launch.sh не относятся к Git-репозиторию, но должны присутствовать в каждом активированном релизе. Поэтому скрипт деплоя переносит эти файлы локально на сервере из текущего каталога приложения, прежде чем запустить новый релиз.
Meilisearch тоже снова стал частью эксплуатационной картины. Приложение могло без Meilisearch откатываться на SQL-поиск, но из-за этого /api/health был лишь degraded. Поэтому на сервере Hetzner Meilisearch работает как localhost-only Docker-сервис с локальным серверным ключом.
Кроме того, GitHub-деплой-воркфлоу получает более чёткий гейт: линт и typecheck выполняются перед продакшен-деплоем. Локальный push-деплой остаётся удобным, но не должен быть единственной долгосрочной истиной. Целевое состояние такое: GitHub собирает, проверяет и деплоит; локальные деплои остаются ручным инструментом для исключительных случаев.
Что может появиться позже: если мы будем эксплуатировать много приложений, клиентских окружений или self-service-деплоев, control plane может оказаться разумной. Тогда мы трезво рассмотрим Coolify, Dokploy или Kamal. А до тех пор действует правило: меньше платформы, больше надёжной эксплуатационной дисциплины.
