Деплой на собственный сервер означает предоставление агенту доступа, близкого к SSH, к боксу, за который вы платите и на котором уже может что-то работать. Это иной уровень доверия, чем публикация на бесплатный поддомен, и настройка это отражает — несколько полей, заполненных один раз, и после этого каждая следующая сборка — это просто кнопка. Вот что люди на самом деле спрашивают до и после настройки цели деплоя.
Что нужно для создания цели?
Пять вещей, в разделе Настройки → Деплой:
- Название, которое вы узнаете позже — «prod-vps», «client-hostgator», что угодно, что не потеряется в выпадающем списке в 11 вечера
- Хост и порт
- Учётные данные SFTP
- Путь к корню сайта (webroot)
Никаких API-токенов, никакого CLI для установки на сервере, никакой cron-задачи, за которой нужно следить. Если ваш хостинг предоставляет доступ по SFTP — а это касается почти любого шаред-хостинга, любого VPS, любого управляемого WordPress-хостинга — вы закончите примерно за две минуты.
Пароль или ключ?
Ключ, если ваш хостинг это поддерживает. Пароли работают нормально, и мы храним их привязанными к вашему аккаунту, но ключ — это на один секрет меньше, лежащий где-либо, — разница между «отозвать ключ» и «сбросить пароль везде, где этот пароль случайно повторно использовался», если что-то потом пойдёт не так. Многие дешёвые шаред-хостинги с SFTP предлагают только парольную аутентификацию, и это тоже нормально. Просто не используйте этот пароль больше нигде.
Как найти правильный путь webroot?
Это поле, в котором люди ошибаются в первый раз, потому что неправильный ответ всё равно выглядит правдоподобно. Это не ваша домашняя директория, это не /var/www — это именно та папка, из которой ваш веб-сервер настроен отдавать контент.
| Сервер | Типичный webroot |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — или какой-то путь, который прошлый разработчик назвал три года назад по причинам, которые уже никто не помнит |
Если не уверены, забросьте одноразовый test.txt в папку, которую считаете правильной, через любой SFTP-клиент, а затем проверьте, открывается ли она по адресу yoursite.com/test.txt. Ошибётесь — и деплой всё равно отрапортует об успехе: агент честно записывает файлы не в ту папку, а вы остаётесь смотреть на живой сайт, который не изменился, недоумевая почему.
Может ли одна цель покрывать больше одного домена?
Да, и именно эта часть реально экономит время, как только вы прошли свой первый сайт. Цель — это один сервер и один набор учётных данных; она не привязана к единственному домену. В разделе Управление доменами вы привязываете каждый домен к цели с собственным переопределением webroot. Запускаете три сайта на одном VPS с блоками серверов Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
Одна цель, три привязки. Вам не нужно вводить SSH-пароль трижды и поддерживать три почти идентичных цели, которые расходятся в тот день, когда вы меняете ключ и забываете обновить одну из них. Нажмите деплой на любом из трёх доменов, и он уже знает, какой сервер и какую папку использовать — вам не нужно выбирать это в момент деплоя.
Что на самом деле делает агент при подключении?
Сначала он осматривается — только чтение, ничего ещё не записано. Эта проверка выясняет наличие:
- Пустой папки
- Предыдущей версии именно этой сборки
- Старой установки WordPress
- Заглушки «скоро запустимся», которую хостинг разместил там по умолчанию
Это определяет стратегию. Пустой webroot получает простую загрузку. Webroot, в котором уже что-то есть, обрабатывается более осторожно, потому что во многих реальных настройках рядом с сайтом живёт то, что не должно исчезнуть:
- A
.well-knownпапку для валидации SSL - Директорию
uploads, которую никто не добавлял в git - A
wp-config.phpкоторую никто не хочет трогать
Здесь задача ближе к «понять, что изменилось, и согласовать это», чем к «стереть и заменить».
Затем, прежде чем будет перезаписан хотя бы один байт, существующий webroot сохраняется как версия на вашем собственном хосте. Не запись в базе данных, не дифф, который мы вычисляем и надеемся, что он верен, — а настоящий снимок того, что там находилось. Это важнее всего именно при самом первом деплое на любую цель, потому что этот деплой всегда ложится поверх чего-то, даже если это «что-то» — пустота. Пустая папка — пустой снимок. Пятилетний статический сайт, о создании которого никто уже не помнит, — сохраняется в точности, бесплатно, до того как его затронут. Этот первый деплой также тот, в котором вы меньше всего уверены, поэтому именно тогда это важнее всего.
Загружает ли он мой исходный код или собранный сайт?
Всегда собранный сайт. Для статического сайта — это сгенерированные страницы. Для фреймворковой сборки — Next.js, Vite, что бы ни требовал тип сайта — это скомпилированный вывод, папка dist или build , никогда не дерево исходников. Считаю это правильным решением, даже несмотря на то, что вы не сможете зайти по SSH и выполнить npm run dev на том, что лежит на сервере. Загрузка исходников означала бы, что вашему продакшн-webroot нужны Node-рантайм и инструментарий сборки только для того, чтобы отдавать HTML — превращая сервер на общем хостинге, который никогда не предполагался для запуска пайплайна сборки, именно в это, и превращая каждый деплой в «надейся, что серверу хватит памяти, чтобы завершить npm install». Отправка только скомпилированного вывода оставляет webroot именно таким, каким его ожидает статический файловый сервер. Скучно. А скучное — это то, что вам нужно в 2 часа ночи, когда что-то не работает и вы смотрите на эту папку, пытаясь понять, что на самом деле отдаётся.
Как понять, что деплой действительно сработал?
После загрузки агент обращается к живому URL и проверяет, отвечает ли он — не 500, не пустая страница. Всё, что он обнаружит, плюс всё, что он заметил во время проверки и хочет уточнить у вас («в этом webroot есть папка wp-content , которую я оставил нетронутой, подтвердите, что так и должно быть»), попадает в чат сборки. Это шаблон всей платформы: никаких молчаливых успехов, никаких молчаливых сбоев, превращающихся в тикет поддержки. Агент рассказывает, что он увидел и что решил, в том же треде, где вы попросили сборку.
Что на самом деле хранится в истории версий?
Каждый деплой добавляет версию — не только первый. Так что история — это не ваши сборки, отложенные на абстрактной шкале времени; это буквальная последовательность того, что реально отдавалось из этого webroot, по порядку, начиная с того, что там было до вас. Версия один — это всегда то самое состояние до появления платформы, зафиксированное автоматически. Вам не нужно об этом думать.
Что именно восстанавливает откат?
Предыдущую живую версию — точно такую же, а не повторный запуск старой сборки, не приближение. Именно те файлы, которые обслуживали трафик до этого. Это заметно более надёжная гарантия, чем большинство функций «отката», которые я встречал в других местах — обычно это означает «передеплоить из старого коммита» и молча предполагает, что ваш процесс сборки детерминирован, а окружение не изменилось с тех пор. Здесь откат — это восстановление известного рабочего снимка, поэтому его безопасно использовать под давлением: вам не нужно гадать, поведёт ли откат себя иначе, чем то, к чему он откатывает.
А момент, когда он реально нужен, никогда не бывает спокойным: «новая сборка сломала оформление заказа, и трафик идёт прямо сейчас».
Один клик — предыдущая версия восстановлена, готово. Обоснование того, почему это сделано полноценной функцией, а не второстепенной опцией, изложено в статье «Итерации без страха» — стоит прочитать один раз, пока она вам не понадобилась. И история, и элемент управления восстановлением находятся на карточке сборки и в собственной истории цели.
Это резервирует и мою базу данных тоже?
Нет, и я предпочитаю сказать это прямо, чтобы никто не строил ложных предположений. История версий на хосте охватывает то, что этот пайплайн деплоя поместил в webroot. Если на вашем сайте есть база данных, пользовательские загрузки или что-то ещё, что меняется вне деплоев — это совершенно отдельный вопрос: откат этого не затрагивает, и его не следует принимать за стратегию резервного копирования, которая бы это делала.
