This method is for one VPS: obtain source from Git and build the application with Docker directly on the server. CI, a separate registry, and SSH to itself are unnecessary. This guide keeps images on the VPS and disables backups.
1. Create a profile in Generator UI
Enable Docker and Production deployment in Deployment, and choose CI provider → None. In Deployment environments, create profile production with Single server preset. Select Image delivery → Build on server (manual) within it, enter your domains, TLS contact email, and Runtime directory. Choose None for Backup destination; working images use the project's Local files setting.
For field details, see profile preparation. Click Save deployment settings, then Generate. Settings appear in deploy/generated/environments/production.json; leave the empty adjacent custom file in deploy/custom/environments/ unchanged for now. Do not copy JSON into deploy/environments/.
Commit the result to the generated project's repository and push to Git. These source files and settings will be obtained on the VPS.
2. Prepare the server and get code
Complete VPS and domain preparation. Then switch to deploy in the VPS root terminal:
su - deploy
mkdir -p "$HOME/projects"
cd "$HOME/projects"
git clone https://gitlab.com/your-namespace/example-project.git
cd example-project
Replace the Git URL with your project address. For private repositories, grant deploy read access beforehand; do not put passwords or tokens in the command URL. example-project is the code folder, while /srv/admingen/example_project/production is the separate data folder already prepared on the VPS.
3. Use the created profile
The production profile files arrived with the project. Runtime directory must match the VPS directory you prepared. Source needs no SSH to itself. Local media and disabled backup need no separate secrets file: provision creates the database password and authentication keys.
4. Perform first startup
On the VPS as deploy, from the example-project root:
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
Run commands individually, proceeding only after success. Build builds the version; provision checks the environment and prepares secrets, PostgreSQL, and HTTPS; deploy applies migrations and starts the application. After provision, the application may still show a maintenance page. Successful deploy ends with status=complete; status must show a recorded current release and successful readiness.
A *.images.tar appears beside release-001.json. Keep them together: they contain the version's built images. Source still requires internet for Docker base images and dependencies.
Create the first administrator
For a new project without data, run on the VPS as deploy or root:
docker ps --filter label=com.docker.compose.service=backend
Take the name from NAMES and replace ИМЯ_BACKEND_КОНТЕЙНЕРА:
docker exec -it ИМЯ_BACKEND_КОНТЕЙНЕРА \
admin bootstrap-superadmin --if-needed --login owner
Enter and confirm a password of 12–128 UTF-8 bytes; input is hidden. Open https://admin.example.com with your domain and sign in as owner. If a superadministrator exists, this does not replace it or reset its password.
To transfer a populated development database, after successful first deploy follow data transfer into a Docker environment. Import replaces the new database, including the created account; afterward use accounts from the transferred database.
Update the application
Commit and push new changes from your workstation. Then on the VPS as deploy, from the same project root:
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
Choose another filename for each release, such as release-003.json. Normal updates do not repeat provision. up starts the recorded release rather than Git changes. Successful update ends with status=complete, and status shows the new current release.
With Backups None, no automatic backup precedes an update. Configure backups when data preservation is needed; S3 media is connected separately. Change an existing environment through supported reconfigure.
If release stops
From the same place where you ran control:
bash ./deploy/control status --env production --json
bash ./deploy/control logs --env production --service backend
Preserve the error message and operation ID. Continue with operation recovery. Do not delete data or state to retry. First deploy failure after migrations also requires operation investigation, even without a recorded current release.