These actions apply to an existing environment. For first startup, choose Prod-local, Source, Archive, or Registry.
Examples name the server environment production: commands select the UI production profile with its custom overrides; a complete manual JSON is used only when present. Source runs on the VPS itself; Archive/Registry runs from the controlling computer.
State and logs
bash ./deploy/control status --env production --json
bash ./deploy/control logs --env production --service backend
Available logs are backend, frontend, and postgres. In status, check current, operation completion, and component readiness. ready: null means readiness is unconfirmed.
Stop and restart
bash ./deploy/control down --env production --confirm production
bash ./deploy/control up --env production --confirm production
Data is preserved. up starts the recorded version. For prod-local, use --env local; local up/down need no confirmation.
Release new code or return to old code
New code requires build and deploy — see the complete update procedure. Build creates release JSON; do not write it manually.
To return to a previously successful release:
bash ./deploy/control rollback --env production --release RECORDED_RELEASE_ID --confirm production
Substitute the saved release ID. Rollback restores application images but does not roll back the database. To restore data, use backup and restore.
If a command is interrupted
bash ./deploy/control status --env production --json
bash ./deploy/control reconcile --env production --json
Reconcile shows state and fixes nothing itself. Take the operation ID from the result. For a supported unfinished operation, resume its stages:
bash ./deploy/control resume --env production --operation OPERATION_ID --confirm production
Or close the operation if you decide not to continue:
bash ./deploy/control abandon --env production --operation OPERATION_ID --confirm production
Abandon preserves data and history but does not undo applied migrations or fix the application. Before choosing, read operation recovery. Reconfigure uses its own retry method, below.
Change delivery or backup
reconfigure changes Source/Archive/Registry delivery and None/Local/S3 backup settings for an existing server environment. The application stays running; this command does not move database or media data. Changes to servers, domains, root, topology, and media need a separate procedure, rather than reconfigure.
1. Update tools before changing settings
The current successful release must support reconfigure. If created by an older generator, first run Generate, build, and deploy the updated application using the old delivery and old environment file. Otherwise the command reports missing tools in the current release.
2. Prepare new settings
Change delivery or backup in the Generator UI profile, save, and run Generate. For manual additions, use deploy/custom/environments/production.json. Check Preview effective JSON; leave other parameters unchanged. If the project still uses a complete deploy/environments/production.json, edit it or import it into UI first following these instructions.
When switching to Registry, fill in three repositories and prepare access. For S3, prepare storage and keys. Pass new secrets through a file using DEPLOY_SECRETS_FILE, as in environment setup. Password values are not command arguments.
3. Apply the change
Normally:
bash ./deploy/control reconfigure --env production --confirm production
For Source → Archive/Registry, run the command on the active VPS with --on-host:
bash ./deploy/control reconfigure --env production --confirm production --on-host
This applies new SSH settings before switching to computer or CI control. The deployment user must already have access to existing environment directories: the command does not transfer permissions to another user.
For Archive/Registry → Source, one VPS is required. Run on that VPS from the project checkout, with new delivery.mode: source, without --on-host. Source selects local execution itself.
4. After completion
Send updated generated/custom files through Git to the controlling machine and synchronize CI settings if used. CI does not apply to Source. Release subsequent builds using the chosen method.
If reconfigure is interrupted, preserve the same JSON and secrets file, then repeat with the ID from output:
bash ./deploy/control reconfigure --env production --confirm production --operation OPERATION_ID
If the first command used --on-host, add it on retry too. Do not change files between attempts. Ordinary resume is not used for this operation.
Backup, certificates, and secrets
| Action | Command |
|---|---|
| Create a backup | backup --env production --confirm production |
| Restore a selected backup | restore --env production --recovery-point ID --confirm-restore production |
| Maintain HTTPS certificates | certificates --env production --confirm production |
| Rotate a secret | rotate-secrets --env production --kind KIND --confirm production |
Prefix each line with bash ./deploy/control. Rotation kinds are auth, postgres, media, backup, registry, db-leaf, db-ca. Full guides: backups and secret rotation.
Backup None creates no copies and makes backup/restore unavailable. Local backups on the same server do not protect against losing that server.
All parameters are in the deploy/control reference.
Check containers and free space
docker ps -a on the VPS shows actual containers. An old tag in docker image ls does not mean an old container is running. For image roles, see Docker images; for cache and archives, disk cleanup. Control currently has no automatic old-release cleanup command.