Инфраструктура «на ручнике»: Как я организовал деплой без лишней магии
17 марта 2026 года. Пока все пытаются настроить сложнейшие CI/CD пайплайны, которые ломаются от каждого чиха, я решил пойти по пути предсказуемости и контроля.
Когда ты работаешь с Claude и быстро генерируешь код, есть соблазн автоматизировать всё. Но я выбрал схему «двух потоков». Рассказываю, как это работает и почему это не «откат в прошлое», а здравый смысл.
Моя схема: Локалка — GitHub — Beget
Вместо того чтобы заставлять Beget «слушать» GitHub (что на бюджетных тарифах часто превращается в квест с SSH-ключами), я разделил эти процессы:
- GitHub — это архив. Сюда улетает git push. Это моя история версий, бекап и страховка. GitHub не знает о сервере.
- rsync — это транспорт. Команда запускается локально и зеркалит изменения прямо на Beget. Сервер не знает о GitHub.
Почему это удобно?
- Контроль: Я деплою только тогда, когда уверен, а не при каждом случайном коммите.
- Скорость: rsync работает молниеносно. Он сравнивает файлы и докидывает только те байты, которые изменились.
- Безопасность: Мне не нужно хранить SSH-ключи от сервера в облаке GitHub. Все ключи и доступы — только у меня на машине.
Жёсткий реализм: Да, теперь мне нужно нажимать две кнопки вместо одной (git push и запуск скрипта деплоя). Но я экономлю часы на дебаге вебхуков и настройке окружения.
FAQ
1. Не лень делать два действия вместо одного?
Нет. Это занимает лишние 3 секунды. Зато я на 100% уверен, что на сервер попало именно то, что я проверил локально.
2. Почему не настроил GitHub Actions?
Столкнулся с проблемами SSH-ключей на стороне хостинга. Решил, что время на написание контента и кода с Claude важнее, чем борьба с конфигурацией серверов.
3. Можно ли потом всё-таки сделать автодеплой?
Конечно. Инфраструктура гибкая. Если проект вырастет — прикручу пайплайны. Сейчас главное — скорость запуска.
Подпишись на мой телеграм канал где буду выкладывать проблемы с которыми столкнулся при написании кода