Projects
Builds, deployments, and logs
LiveUnderstand the project execution lifecycle: build output, deploy state, rollback behavior, and where to inspect logs.
Goal
Know where to look when a project deployment does not behave the way you expect.
Current status
Live
This area is documented as current, user-reliable behavior.
Workflow
- 1Use build history to inspect build stages and failures.
- 2Use deployment history to see what is live and what changed.
- 3Use project logs to inspect runtime output after deploy.
- 4Use rollback actions when the latest deployment should not remain active.
Best debugging order
- Build first: did the artifact get produced correctly?
- Deployment second: did the release actually become live?
- Logs third: what is the running application doing now?
What each surface tells you
- Build history explains source and image creation problems.
- Deployment history explains release transitions and rollback choices.
- Logs explain the current runtime behavior after the deployment is live or failing.
How runtime shape affects lifecycle
- Worker services can still build and deploy, but they do not expose a public URL or domain ingress.
- Contract-build workloads stop at artifact creation and should be treated as build-only output rather than a live runtime.
- If a project is intentionally build-only, deploy actions are less relevant than build success, artifacts, and logs.
Expected result
You can trace a project issue from build to deployment to live runtime logs.