Builds and deploys
Every deployment goes through the same pipeline: a trigger, a build, and a rollout. This page covers what starts a build, how to watch it, what to do when it fails, and why an interrupted build doesn’t just die.
What triggers a build
Once a project is connected, a push to its tracked branch triggers a build and ship automatically. You don’t run a deploy command — the push is the deploy. Turn auto-deploy off per repository if you’d rather trigger builds manually, and roll back to any previous build from the project page.
Watching build logs
Follow build output in the dashboard. A successful build is followed by deployment and health checks; the app is ready only after the rollout succeeds.
When a build fails
A failed build leaves the previous deploy running — a bad push never takes down a working app. The build log shows exactly where it stopped, which is almost always enough to spot a missing dependency, a failing step, or a misconfigured start command. Fix the issue and push again; the next push starts a fresh build.
Why deploys resume
Builds run on infrastructure that can occasionally be replaced mid-run for reasons that have nothing to do with your code. Instead of failing your deploy when that happens, SetCloud picks the run back up from where it left off — it doesn’t re-run steps that already finished, and it never re-bills you for work it already charged. From your side, a resumed deploy just takes a little longer than usual; it doesn’t show up as a failure.
Next
- Deployments quickstart — connect a repo and ship your first deploy.
- Environment variables and secrets — configure what your build and running app can see.
- Full rate card on the pricing page.