# Deployments

A deployment is one build-and-release of a project environment. Every push, manual deploy, or rollback creates a deployment you can inspect step by step, with live logs. Deployments are per environment, so each environment keeps its own history and its own rollback targets.

## The pipeline

Each deployment runs a sequence of steps, surfaced live in the console:

- **Clone** - shallow-clone the repo at the environment's branch.
- **Analyze** - detect the framework, runtime, and port; generate a Dockerfile if the repo doesn't have one.
- **Build** - build the image in an isolated, resource-limited build sandbox, then store it for deploy and rollback.
- **Deploy** - run the new container with hardening, resource limits, env vars, and routing.
- **Health check** - verify the container comes up.
- **Finalize** - mark it live, supersede the previous deployment, and prune old images per your plan.

## Zero-downtime cutover

Where capacity allows, a new deployment starts alongside the previous container and traffic is shifted to it once it is healthy, then the old one is drained and removed. If something fails before the new container is healthy, the previous deployment keeps serving - a failed deploy does not take your app down.

## Live and historical logs

While a deployment runs, build and runtime logs stream live to the deployment page. Logs are retained afterward, so you can open a past deployment and read exactly what happened. Per-step output is kept separately, so you can tell a build failure from a runtime failure at a glance.

## Rollback

Open any previous deployment and roll back to redeploy its image. If the image is still retained the rollback is instant; if it has been pruned, orkestr rebuilds it from source at that commit. Rollbacks are available on the Pro plan.

> **Image retention**
>
> orkestr keeps a number of recent images per project (more on higher plans) and prunes older ones after each deploy. Instant rollback is available for any image still retained.

## Image pruning and plans

- Free keeps the most recent image; Pro keeps more.
- Pruning runs after each successful deploy to reclaim disk.
- Rollback to a pruned image still works - it just rebuilds instead of redeploying instantly.

## Triggering a deploy

- **Push** to a branch mapped to an environment (auto-deploy).
- **Manual** deploy from the console.
- **API / CLI** for CI pipelines and scripts.

> **Debugging a failed deploy**
>
> Open the failed deployment and check which step failed. Build failures show the build output (often a missing dependency or a Dockerfile issue); runtime failures show the container logs and the exact error, which is usually a missing env var or a port mismatch. See also [Monitoring](https://orkestr.eu/docs/features/monitoring).

## FAQ

### Will a failed deploy take my site down?

No. The previous deployment keeps serving until the new one is healthy.

### How far back can I roll back?

To any retained image instantly, or to any past commit by rebuilding from source.

### Where are build logs vs app logs?

Build and deploy logs live on the deployment; ongoing runtime logs live under [Monitoring](https://orkestr.eu/docs/features/monitoring).