Этот способ подходит для одного VPS: вы забираете исходники из Git и собираете приложение Docker-командой прямо на сервере. CI, отдельный registry и SSH к самому себе не нужны. В этой инструкции изображения хранятся на VPS, резервные копии отключены.
1. Создайте профиль в Generator UI
В Deployment включите Docker и Production deployment, выберите CI provider → None. В Deployment environments создайте профиль production с preset Single server. Внутри профиля выберите Image delivery → Build on server (manual), заполните свои домены, TLS contact email и Runtime directory. В Backup destination выберите None; для рабочих изображений используется Local files, выбранный для проекта.
Подробное пояснение полей — в подготовке профиля. Нажмите Save deployment settings, затем Generate. Настройки появятся в deploy/generated/environments/production.json; пустой custom-файл рядом в deploy/custom/environments/ можно пока не менять. Копировать JSON в deploy/environments/ не требуется.
Закоммитьте результат в репозиторий сгенерированного проекта и отправьте его в Git. Именно эти исходники и настройки вы получите на VPS.
2. Подготовьте сервер и заберите код
Выполните подготовку VPS и доменов. Затем в root-терминале VPS переключитесь на deploy:
su - deploy
mkdir -p "$HOME/projects"
cd "$HOME/projects"
git clone https://gitlab.com/your-namespace/example-project.git
cd example-project
Замените Git URL адресом своего проекта. Для приватного репозитория заранее предоставьте пользователю deploy право чтения; пароль или токен не вставляйте в URL команды. Здесь example-project — папка кода, а /srv/admingen/example_project/production — отдельная папка данных, уже подготовленная на VPS.
3. Используйте созданный профиль
Файлы профиля production уже пришли вместе с проектом. Его Runtime directory должен совпадать с каталогом, подготовленным на VPS. Для Source не нужен SSH к самому себе. При local-медиа и отключённом backup отдельного файла секретов тоже не требуется: provision создаст пароль БД и ключи аутентификации.
4. Выполните первый запуск
На VPS под deploy, из корня example-project:
bash ./deploy/control build --env production --output release-001.json
bash ./deploy/control provision --env production --release release-001.json --confirm production
bash ./deploy/control deploy --env production --release release-001.json --confirm production
bash ./deploy/control status --env production --json
Выполняйте команды по одной и переходите дальше только после успеха. Build собирает версию; provision проверяет окружение и готовит секреты, PostgreSQL и HTTPS; deploy применяет миграции и запускает приложение. После provision приложение ещё может показывать страницу обслуживания. Успешный deploy заканчивается status=complete; status должен показывать записанный текущий релиз, а проверка готовности — успешное состояние.
Рядом с release-001.json появится *.images.tar. Сохраните их вместе: это собранные образы версии. Для source всё равно нужен интернет — Docker скачивает базовые образы и зависимости.
Создайте первого администратора
Для нового проекта без данных выполните на VPS под deploy или root:
docker ps --filter label=com.docker.compose.service=backend
Возьмите имя из столбца NAMES и замените им ИМЯ_BACKEND_КОНТЕЙНЕРА:
docker exec -it ИМЯ_BACKEND_КОНТЕЙНЕРА \
admin bootstrap-superadmin --if-needed --login owner
Введите и подтвердите пароль длиной 12–128 байт UTF-8; ввод скрыт. Откройте https://admin.example.com со своим доменом и войдите как owner. Если суперадминистратор уже существует, эта команда не заменяет его и не сбрасывает пароль.
Если переносите заполненную БД из разработки, после успешного первого deploy перейдите к переносу данных в Docker-окружение. Импорт заменит новую БД, включая созданный аккаунт; после него используйте аккаунты из перенесённой базы.
Обновите приложение
Закоммитьте и отправьте новые изменения с рабочего компьютера. Затем на VPS под deploy, из того же корня проекта:
git pull --ff-only
bash ./deploy/control build --env production --output release-002.json
bash ./deploy/control deploy --env production --release release-002.json --confirm production
bash ./deploy/control status --env production --json
Для следующего выпуска выберите новое имя файла, например release-003.json. Provision при обычном обновлении не повторяется. up запускает записанный релиз, а не изменения из Git. Успешное обновление заканчивается status=complete, и status показывает новый текущий релиз.
При Backups None автоматической копии перед обновлением нет. Настройте резервные копии, когда понадобится сохранение данных; S3-медиа подключаются отдельно. Уже работающее окружение меняйте через поддерживаемую процедуру reconfigure.
Если выпуск остановился
В том же месте, где запускали control:
bash ./deploy/control status --env production --json
bash ./deploy/control logs --env production --service backend
Сохраните сообщение об ошибке и operation ID. Продолжение — в восстановлении операции. Не удаляйте каталог данных или state для повторной попытки. Ошибка первого deploy после миграций также требует разбора операции, даже если текущий релиз ещё не записан.