---
title: Deployments
description: Follow a deployment through its states, redeploy, roll back, cancel or remove one, and find out when one fails.
section: Services
order: 7
---

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](/docs/config-as-code) |
| `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](/docs/staged-changes) |
| Pull request preview | `preview` | A pull request with [previews](/docs/projects#preview-a-pull-request) 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.

```bash tab="cURL"
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](/docs/billing#choose-which-emails-you-get).

To send deploy results to your own tools instead, add a [deploy webhook](/docs/webhooks).