Overview
The deployment can be seen as a state machine where each state is a “Deployment Status”. Depending on the current status of your application, different actions are available.
The deployment status is different from the running status. A deployment can be in error, but your application can still be running (with the previous version).
Deploy
The “Deploy” action will create the necessary resources to run your code on your Kubernetes cluster. This action is only available if your service/environment has never been deployed.Deployment Flow
The deploy action follows this sequence of statuses: QUEUED: The deployment request is in the queue, waiting for resources to be allocated. BUILDING: The Git repository is downloaded, the code is compiled, and the image is built and pushed to the registry. If something goes wrong during this phase, the status will change to “BUILD ERROR”. DEPLOYING: The pods are being created based on the built image. If something goes wrong, the status changes to “DEPLOYMENT ERROR”. If your service is deployed but the readiness probe never succeeds (the service is considered as not healthy), the status will remain “DEPLOYING” indefinitely until you fix the issue or cancel the deployment. DEPLOYMENT OK: All pods have been created and your service is running correctly.Environment Deployment Statuses
When deploying at the environment level, the status is derived from the status of all services:- QUEUED: At least one service is queued
- BUILDING: At least one service is building
- DEPLOYING: At least one service is deploying
- DEPLOYMENT OK: At least one service deployment is OK and no service is in error
- DEPLOYMENT ERROR: At least one service is in deployment error
Redeploy
The “Redeploy” action will update the remote configuration of your services based on the changes done on Qovery’s side. This action implements a rolling-restart deployment logic: a new instance is deployed, verified to be running correctly, then the old instance is stopped. This process is repeated sequentially for all instances. This action is only available after you have executed the “Deploy” action at least once. If the configuration has not changed, no pod restart will occur.Stop
The “Stop” action will stop the execution of your service/environment. The status of your service/environment will be “Stopped”. This action is only available if your service/environment status is “Deployment OK” or “Deployment Error”. The effect of this action depends on the type of service:- Applications and Containers: The pods are stopped, but any attached storage (volumes) is preserved
- Databases managed by cloud provider: The database is paused (available only for AWS, not available for Redis databases)
Restart Service
The “Restart Service” action will restart the pods of your service without changing the configuration. This action is only available for single services (not at environment level) and only when the status is “Deployment OK”. The restart action follows this sequence:- RESTARTING: The restart request has been received
- RESTARTED: All pods have been restarted
- RESTART ERROR: Something went wrong during the restart
Cancel Deployment
The “Cancel Deployment” action allows you to abort a “Deploy” or “Redeploy” action and halt the execution of the deployment pipeline. This action is only available during the “Queued”, “Building”, or “Deploying” statuses. When you cancel a deployment:- The current service deployment is stopped and rolled back to the previous version
- Services that were already deployed in the pipeline are NOT rolled back
- For Lifecycle Jobs, you need to force the cancellation by checking the confirmation checkbox in the modal
Deploy Other Version
The “Deploy Other Version” action allows you to deploy a different version of your service (git commit or image tag). This action is available regardless of the current deployment status.
Deploy Latest Version
The “Deploy Latest Version” action allows you to deploy the latest version of your services within an environment. This is an environment-level action only, available regardless of the current status.
Queueing and Merging
At any given time, only one deployment action is being processed. If you trigger successive deployment requests, they will be queued and you can see them in the Deployment History section.Merge Logic
Queued deployment requests can be merged under specific conditions: if the same user triggers multiple requests with the same action, these requests will be merged into a single request. Example 1: You trigger a deployment of application A. While A is deploying, you trigger the deployment of application B, then application C. The deployments of B and C will be queued and merged. Once A has finished deploying, B and C will deploy together following the order defined in the Deployment Pipeline. Example 2: Same as Example 1, but this time another user triggers the deployment of C. In this case, the deployments of B and C will NOT be merged. B will deploy first, then C will deploy, following the order defined in the Deployment Pipeline.Executing Actions
Actions can be triggered at different levels:- Environment level: Click the play button on the environment to execute the action on all services according to the Deployment Pipeline order
- Service level: Click the play button on a specific service to execute the action only on that service
- Multi-service selection: Select multiple services and use the floating action button to execute the action on selected services