Build pipeline

1. 1

   Fetch the source

   A GitHub deploy shallow-clones the repo at the branch (or, for a rollback, fetches the exact commit SHA directly - it pins the tree regardless of what the branch points to now). An upload deploy instead extracts your last uploaded archive. Either way, the platform's own example project clones tokenless, so it works before you've connected GitHub.

2. 2

   Validate the project config

   Your pyproject.toml or package.json is parsed and checked against the field rules. An invalid value fails here, with the exact field and rule in the deploy log, before anything is built.

3. 3

   Detect the dependency manager

   The build directory is inspected for uv.lock, poetry.lock, Pipfile, pdm.lock, or a plain requirements.txt - whichever is present decides the install and run commands used next. An unsupported project shape fails here rather than midway through a build.

4. 4

   Build the image

   docker build runs against a generated Dockerfile, capped at 10 minutes. Every line of its stdout/stderr streams live to the build log, so a dependency resolution error shows up exactly as the installer printed it.

5. 5

   Start the new container alongside the old one

   Deployments are blue-green: the new image starts under a temporary name on the project's own network, fully routed, while the currently-live container keeps serving traffic untouched.

6. 6

   Wait for health

   The new container has 60 seconds to pass a health check (polled every 2 seconds, after a 10-second startup grace) before it's trusted with real traffic. If it never passes, it's discarded and the previous container keeps running - a broken build can't take a working deploy down with it.

7. 7

   Promote

   Only once the new container is healthy does the old one get removed and the new one renamed into its place. That swap is the only moment live traffic is touched at all, and it's a container rename, not another build.

The deploy log narrates these stages one line at a time; the build log carries only the raw docker build output. Both are covered in full in deploy & build logs.