Deployment lifecycle
Understand builds, automatic deployment, restarts, and the limits of a code rollback.
Build first, then replace
Section titled “Build first, then replace”Deplexo checks out the requested revision and builds its image before replacing the existing container. If the build fails, inspect that deployment’s logs and correct the cause before trying again.
For GitHub, GitLab, Bitbucket, and Codeberg, the configuration and build use the same resolved commit. ZIP deployments use the uploaded archive. Each redeployment validates deplexo.yaml again and applies its explicit fields over the saved dashboard defaults. Removing a YAML override restores the corresponding default. Starting an existing stopped container does not read changed source files.
When the image is ready, Deplexo stops the previous container before starting its replacement. This can briefly interrupt service. Handle termination signals, finish in-flight work promptly, and make clients reconnect after a connection drops.
Deploy after a git push
Section titled “Deploy after a git push”Automatic deployment uses the connected provider’s webhook for the configured repository. Turn it on in application settings to deploy on pushes, or leave it off to deploy manually.
If a push does not deploy, verify the branch, provider access, automatic deployment setting, and recent deployment activity. Review the commit shown in the deployment history before relying on an automated release.
Choose a restart or redeployment
Section titled “Choose a restart or redeployment”A process-only restart replaces the container using its existing image and current runtime configuration. A redeployment deploys the selected source revision with your current environment. If that source and its build settings haven’t changed since an earlier build, Deplexo deploys the stored image again without building, so changing only environment variables doesn’t trigger a build. Choose Rebuild in the dashboard, deplexo deploy --rebuild, or {"rebuild":true} in the API to build a fresh image, for example to pick up newer base images. The user API calls this operation POST /apps/{id}/restart. See the CLI guide or API guide before choosing an automation command.
Saving an environment value or mount setting does not alter an already-running process. Apply it with the relevant restart or redeployment action, then verify the new process and application behavior.
Rollback changes application code
Section titled “Rollback changes application code”Choose a previous deployment revision to rebuild and deploy an earlier code version. Check its dependencies and compatibility with the current environment and data before rolling back.
A code rollback does not restore a database, reverse a migration, recover deleted files, or rotate secrets to earlier values. Persistent data remains current. Design schema migrations and application releases so recovery is possible.
Make background work restartable
Section titled “Make background work restartable”When a worker receives a termination signal, it should stop accepting work and finish or safely release its current jobs. Use acknowledgments, leases, or idempotent handlers when supported by the queue or API.
Keep important state in persistent storage or an external database. Ensure a local development bot does not consume the production token. Replacing the deployed container does not stop a separate process using the same credentials.