Deployments
Follow a deployment through its states, redeploy, roll back, cancel or remove one, and find out when one fails.
A deployment is one release of a service, built from a commit or pulled from an image. The project's Deployments tab lists every deployment in the environment with its commit or image, what started it and its build and deploy logs, and marks the one serving traffic as Active.
Deployment states
| State | What it means |
|---|---|
queued |
Waiting to start |
preparing |
Fetching the commit and reading any config file |
building |
Running the build |
deploying |
Starting the new release |
starting |
Waiting for the health check to pass |
healthy |
The release is serving traffic |
failed |
A step failed, and the previous release keeps serving |
cancelled |
You cancelled it, or a newer deployment replaced it |
removed |
It was serving and you took it down with Remove |
A deployment only becomes healthy once the health check passes, so starting a process isn't enough. When a deployment fails while an earlier release is still serving, the service stays up and its status says the latest deployment failed.
What starts a deployment?
| Shown as | Trigger | Started by |
|---|---|---|
| First deploy | initial |
Creating the service |
| Pushed to GitHub | push |
A push to the tracked branch |
| Deployed manually | manual |
Deploy in the service's details, or the API |
| Redeployed | redeploy |
Redeploy on a deployment |
| Rolled back | rollback |
Roll back to this |
| Settings changed | config_change |
Deploying staged changes |
| Pull request preview | preview |
A pull request with previews turned on |
How do I roll back a deploy?
Find an earlier healthy deployment and choose Roll back to this. Dekka deploys that deployment's image again, with the settings it ran with and the service's current variables, as a new deployment marked Rolled back. Nothing is rebuilt, so a rollback is usually quicker than a deploy and doesn't use build minutes.
curl -X POST https://api.dekka.cloud/v1/deployments/$DEPLOYMENT_ID/rollback \
-H "Authorization: Bearer $DEKKA_API_KEY"A deployment from GitHub records its image once it's healthy, and one without a recorded image answers 409 no_image, in which case you can redeploy its commit instead.
Redeploy, cancel or remove a deployment
- Redeploy builds the same commit again, or pulls the same image again, as a new deployment.
- Cancel stops a deployment that hasn't finished. The release that was serving keeps serving.
- Remove takes down the deployment that is serving. It becomes
removed, and the service stays stopped, even through pushes, until you deploy it or choose Start.
Choosing Restart in a service's details restarts the current release without deploying, which picks up saved variables.
Read a deployment's logs
Open a deployment to see its build and deploy output, which follows new lines while it runs. The API returns the same lines from GET /v1/deployments/{id}/logs, and GET /v1/deployments/{id}/logs/stream streams them as server-sent events until the deployment finishes.
Find out when a deploy fails
When a deployment fails, Dekka emails the person who started it and the organisation's owners and admins. The email names the service, the step it failed in and the error, and links to the project's Deployments. If the previous release is still serving, the email says so. Each person can turn these emails off under Settings, then Account, as described in Choose which emails you get.
To send deploy results to your own tools instead, add a deploy webhook.