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 Pro and Team.

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 and Team keep 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.

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.