Git в Plesk: устранение проблем с деплоем (SSH‑ключи и ошибки)

Plesk умеет разворачивать сайт напрямую из Git‑репозитория (GitHub, GitLab, Bitbucket или приватный Git). Если что‑то не работает, причина обычно в SSH‑ключах, неправильном URL репозитория или правах доступа к файлам.

Ниже – чек‑лист для среды GARMTECH (Plesk на хостинге).

Перед началом

• Убедитесь, что домен/подписка доступны в Plesk.
• Определите, репозиторий публичный или приватный.
• Выберите ветку для деплоя (например, main).

Шаг 1 – проверьте URL репозитория (SSH или HTTPS)

Git‑провайдеры обычно дают два варианта:

• HTTPS: https://github.com/user/repo.git
• SSH: git@github.com:user/repo.git

Для приватных репозиториев в Plesk чаще всего удобнее использовать SSH, потому что можно настроить deploy key.

Шаг 2 – добавьте SSH‑ключ Plesk в репозиторий (для приватных репозиториев)

1. В Plesk откройте домен → Git.
2. Если Plesk показывает публичный SSH‑ключ – скопируйте его.
3. В Git‑провайдере добавьте ключ как Deploy key для репозитория (обычно достаточно read‑only доступа).

После добавления ключа вернитесь в Plesk и повторите проверку/обновление репозитория.

Шаг 3 – проверьте папку деплоя

• Для стандартного сайта деплой обычно выполняют в httpdocs/ (основной document root).
• Если деплой в подпапку – убедитесь, что document root сайта соответствует этой папке.

Частые ошибки и решения

Permission denied (publickey)

• Проверьте, что вы добавили именно тот публичный ключ, который показывает Plesk.
• Убедитесь, что используете SSH‑URL (git@…), а не HTTPS.
• Если ключ менялся – удалите старый deploy key и добавьте новый.

Repository not found

• Проверьте URL на опечатки.
• Для приватных репозиториев убедитесь, что deploy key добавлен и активен.

Неверная ветка / ничего не деплоится

• Проверьте, что ветка в Plesk совпадает с реальной веткой (main vs master).
• Убедитесь, что изменения действительно закоммичены и запушены в эту ветку.

Сайт перестал работать после деплоя (500/403/белый экран)

• Откройте Logs в Plesk и посмотрите точную ошибку.
• Проверьте права доступа (обычно папки 755, файлы 644).
• Если проект требует сборку (Composer/NPM), убедитесь, что сборка выполняется при деплое, либо загрузите уже собранные файлы.

Рекомендации

• Сначала разворачивайте изменения на staging‑домен/поддомен, затем на продакшн.
• Конфигурацию (например .env) лучше хранить вне репозитория или защищать соответствующим образом.
• Не храните секреты (API‑ключи, пароли) в Git.