These actions apply to an existing environment. For first startup, choose Prod-local, Source, Archive, or Registry.
In the commands below, ENV_NAME is a shell variable containing the profile name from Deployment environments, not the project name or preset. At the start of each block, replace production, local, or dev with your profile name, for example ENV_NAME=test. Commands use "$ENV_NAME" so --env and its confirmation receive the same value. Set the variable again when switching machines or opening a new terminal.
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
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control status --env "$ENV_NAME" --json
bash ./deploy/control logs --env "$ENV_NAME" --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
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control down --env "$ENV_NAME" --confirm "$ENV_NAME"
bash ./deploy/control up --env "$ENV_NAME" --confirm "$ENV_NAME"
Data is preserved. up starts the recorded version. For prod-local, set ENV_NAME to your local profile name, for example ENV_NAME=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:
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control rollback --env "$ENV_NAME" --release RECORDED_RELEASE_ID --confirm "$ENV_NAME"
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
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control status --env "$ENV_NAME" --json
bash ./deploy/control reconcile --env "$ENV_NAME" --json
Reconcile shows state and fixes nothing itself. Take the operation ID from the result. For a supported unfinished operation, resume its stages:
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control resume --env "$ENV_NAME" --operation OPERATION_ID --confirm "$ENV_NAME"
Or close the operation if you decide not to continue:
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control abandon --env "$ENV_NAME" --operation OPERATION_ID --confirm "$ENV_NAME"
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:
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control reconfigure --env "$ENV_NAME" --confirm "$ENV_NAME"
For Source → Archive/Registry, run the command on the active VPS with --on-host:
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control reconfigure --env "$ENV_NAME" --confirm "$ENV_NAME" --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:
ENV_NAME=production # replace with your exact profile name in Deployment environments
bash ./deploy/control reconfigure --env "$ENV_NAME" --confirm "$ENV_NAME" --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 "$ENV_NAME" --confirm "$ENV_NAME" |
| Restore a selected backup | restore --env "$ENV_NAME" --recovery-point ID --confirm-restore "$ENV_NAME" |
| Maintain HTTPS certificates | certificates --env "$ENV_NAME" --confirm "$ENV_NAME" |
| Rotate a secret | rotate-secrets --env "$ENV_NAME" --kind KIND --confirm "$ENV_NAME" |
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.