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.

Build minutes

Every plan includes a monthly allowance of build time: 300 minutes on Starter and 2,000 on Pro, resetting on the 1st of each month. Only the Build step counts against it - cloning, deploying and health checks are not billed to you. Serverless function builds draw on the same allowance.

We measure wall clock, so a faster build costs fewer minutes. Pro builds run on a larger build machine, so the same project uses less of a bigger allowance.
A build that fails because of your code counts, since it still used a build machine. So does a build you replace with a newer push once it has started building - the machine was already working. A build that fails on our side, or that a newer push replaces before it starts building, does not.
Each individual build is capped at 15 minutes on Starter and 30 on Pro.
Your current usage is on the dashboard and on the billing page, and each deployment shows how long its build took.

Running out doesn't take your app down

On Starter, using the whole allowance pauses new builds until the reset - your deployed apps keep running and serving traffic exactly as before. We email you at 80% so it is never a surprise. Pro is never blocked: minutes beyond the included 2,000 are metered instead.

Bandwidth

Every plan includes a monthly bandwidth allowance - 100 GB on Starter, 1 TB on Pro - measured as the data your apps actually send to visitors, and reset on the 1st of each month. You can see the running total on your dashboard and on the billing page.

Running out pauses your apps

Unlike build minutes, exceeding bandwidth on Starter stops your apps serving until the allowance resets - visitors get a short "temporarily unavailable" page. Nothing is deleted, and your apps come back on their own at the reset, or immediately if you upgrade. We email you at 80% so you have warning. Pro is never paused: traffic past the included 1 TB is metered instead.

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.

Do failed builds use my build minutes?

A build that fails on your code does, because it still ran on a build machine. So does one you supersede with a newer push after the build has started. Only a build that never reached the build step - superseded while still cloning, or stopped by a failure on our side - is free.

Where are build logs vs app logs?

Build and deploy logs live on the deployment; ongoing runtime logs live under Monitoring.

Reading with an agent? This page is also plain markdown at /docs/features/deployments.md, and the full docs index lives at /docs/llms.txt.