---
sidebar_label: Overview
doc_id: ca6a1481-0b81-415b-b1dd-0ff32af9c233
description: >-
  Deploy application releases to scopes with progressive rollouts, rollbacks,
  and customizable strategies.
keywords:
  - deployment
  - rollout
  - rollback
  - deployment strategies
  - progressive delivery
---

# Deployments

A **deployment** publishes an application’s release to a [scope](/docs/scopes-legacy/scopes), where it can run and serve users.
It delivers a built asset to the underlying technology, such as virtual machines, Kubernetes, or serverless
platforms, using any configured [parameters](/docs/parameters) for that environment.

### Key features

- **Asset-based** – Deploy a specific released asset to a scope.
- **Progressive rollout** – Shift traffic gradually or all at once.
- **Rollback** – Revert to a previous deployment if needed.
- **Approvals** – Add review steps for sensitive releases.
- **Groups** – Deploy to multiple scopes at once.
- **Strategies** – Reuse rollout rules for pacing, targeting, and rollback.


## Deployment strategies

Deployment strategies let you define **how** a release is rolled out and **under what conditions** it rolls back.  
They give teams fine-grained control over traffic shifts, rollback triggers, and targeting rules. This helps you
deliver changes more safely and consistently.

With deployment strategies, you can:

- **Control rollouts** – Gradually shift traffic (e.g., blue-green) or cut over instantly (all-in).
- **Automate rollbacks** – Trigger reversions based on telemetry thresholds, like high HTTP error rate.
- **Target precisely** – Apply rules to specific environments, resources, or regions.
- **Enforce policies** – Ensure compliance with internal and platform-level guardrails.

Strategies can be **created once and reused** across multiple scopes, or customized at deployment time for one-off needs.

> See [Deployment strategies](/docs/deployments/strategies) for full details, examples, and configuration options.

## Deployment groups

A **deployment group** lets you deploy to multiple scopes at once. While each deployment runs independently, the group provides centralized visibility and control.

### Key behaviors

- **Flexible grouping**: Include scopes of any type or environment.
- **Individual control**: Cancel or roll back specific deployments at any time.
- **Group status**: The group is marked `FINALIZED` only when all deployments reach a terminal state.
- **Cancellation rules**: Groups can only be canceled if all deployments are still `RUNNING`.
- **Rollback behavior**: Rollback is allowed unless the group is `FINALIZING`.

## Approvals and policies

Approval policies help enforce control over critical deployments by requiring explicit review before they proceed.

**Examples**

- Block production deployments during a holiday freeze
- Require approval from a senior engineer for sensitive scopes
- Auto-deny deployments by non-whitelisted users in production

When a deployment is denied during approval, its status becomes `CREATING_APPROVAL_DENIED`.

> See the [Approvals guide](/docs/approvals) to learn how to create and manage policies.


## Deleted deployments

There's a special situation where an active deployment is not replaced by a new one. This occurs when a scope is
stopped, and the deployment status is set to `DELETED`.

> **Note:** This only applies to **Kubernetes** and **server instance** scopes.

## Learn more

- [**Lifecycle and flow**](/docs/deployments/flow) – Statuses and built-in rollout types.
- [**Strategies**](/docs/deployments/strategies) – Create, apply, and customize rollout rules.