CI builds the application after a push to main. Server deployment starts separately: choose a successful build and confirm its installation.
1. Choose delivery
In Deployment, choose GitLab or GitHub as CI provider. In Deployment environments, create a production profile, fill in VPS settings, and choose Archive or Registry. Save settings, run Generate, and commit the profile with the project.
| Delivery | Build output |
|---|---|
| Archive | release.json with an adjacent *.images.tar containing Docker images |
| Registry | Images in the selected registry and a release.json file |
The build creates release.json. It describes a specific application version and contains neither the database nor user-uploaded images. Keep Archive together with its JSON.
The registry need not match the CI system: GitHub Actions can publish to Docker Hub, for example. Source is intended for manual VPS builds; generated CI jobs do not support it.
2. Prepare the server and environment
Complete server preparation once and create the environment file. CI uses the same settings as manual commands.
3. Configure the chosen CI system
- GitLab CI/CD — project variables, runner, and manual deploy from a pipeline.
- GitHub Actions — secrets, environments, and choosing a build to release.
CI reads the generated profile and custom file from Git just like manual control. With normal UI setup, complete JSON does not need to be moved into CI secrets. SSH and registry secrets are set separately. ADMINGEN_BUILD_ENVIRONMENT_JSON and ADMINGEN_ENVIRONMENT_JSON remain optional complete manual overrides for configurations stored outside Git.
4. Prepare the first release
Push code to main, wait for build, and download its output. Perform initial provision following your chosen mode: Archive or Registry. Use the downloaded release in these guides instead of building again.
After provisioning, run deploy in CI. Later versions need no repeated provisioning.
What happens next
CI sends the prepared build to the server without recompiling. Until deploy, the application continues using the previous version. Maintenance jobs separately create backups and maintain certificates; they do not release new code.
CI artifacts are kept for 90 days. Preserve needed releases separately; for Registry, retain their images in the registry too. With backup.kind: none, maintenance skips backups but continues certificate work.
If a job is interrupted, open operation recovery. Rerunning a pipeline does not undo actions already performed on the server.