How builds work

A build turns source code into a container image that Koo can deploy. Builds run for two source kinds: deploys from Git and archives uploaded with koo up. Container deploys bring their own image and skip the builder — nothing else on this page applies to them.

Where builds sit in the pipeline

A deployment that starts from source moves queued → building → built → applied. A deploy that ships an existing image — a container deploy, or a rollback — skips the two build statuses and goes from queued straight to being applied.

A failed build fails the deployment before anything reaches your service: the running version keeps running, and the build error is recorded on the deployment.

How the image gets made

If your project has a Dockerfile at its root, Koo builds with it — the same image a local docker build would produce. Without one, Koo detects your language and framework and prepares the build itself; when detection isn't enough, it generates a Dockerfile with AI and builds from that. Either way the result is a normal container image, rolled out like any other deploy.

A Git deploy that resolves to a commit Koo has already built reuses that image instead of building it again.

Build logs

Build output lands on the deployment: open the service's Deployments tab and select the version to read its build log, streaming live while the build runs and kept afterwards. The Deployments API exposes the same log on the deployment's build-logs endpoint. Image deploys have no build, so they carry no build log.

When builds won't start

A deploy is refused — with the reason in the error — while your account is still being provisioned, and while it is suspended. There is no per-hour cap on builds: plan limits apply to what you run, not how often you ship — see usage and limits for your plan's ceilings.