Manage builds
The Builds page lists every build across your organisation's projects, newest first. From here you edit a build, create newer ones, and delete the ones nothing uses.
The build list#
Open Builds (under Applications). The count above the table (“3 builds”) covers every project you can see.
| Column | Shows |
|---|---|
| Name | The build's name, as it appears in the deploy form. |
| Image | image:tag, for example ghcr.io/acme/api:1.4.2. |
| CPU | CPU request per replica, such as 0.5 CPU. |
| Memory | Memory request per replica, such as 512 MB. |
| Port | Container port, or — if none is set. |
| Project | The project the build belongs to. |
| Created | How long ago the build was created. |
| Actions | Edit and Delete. |
The dashboard Overview also shows your Recent Builds.
Build statuses#
The Builds page has no status column: a build is a stored configuration, not a running process, so it is simply present until you delete it. Whether an image actually starts is reported where it runs, on the deploy's pods. See Build status and lifecycle and Deployment status.
Inspecting a build#
Everything a build stores is in its row. To see it in form view, choose Edit; close the dialog without saving to leave it unchanged. There's no separate build detail page.
Which deployments use a build#
The Builds page doesn't list a build's deploys. Check from the other side: the Build column on Deployments shows name:tag for every deploy. Before editing or deleting a build, scan that column for its name.
Editing a build#
Edit opens Edit build with the same fields as New build. Change what you need and choose Save build.
| Property | After creation |
|---|---|
| Project | Fixed. The field is locked in Edit build. |
| Name, Image, Tag, Container port | Editable. |
| CPU, Memory | Editable by Managers and Admins. |
Creating newer builds#
To ship a new version, create a new build rather than editing the old one, then point the deploy at it:
Push the new image
Tag it with a new version, for example
ghcr.io/acme/api:1.5.0.Create a build for it
Builds→New build. A versioned name such as
api-v2keeps the Build list readable.Switch the deploy
Deployments→Edit on the deploy, pick the new build in Build, and choose Save deploy.
The old build stays in the list, which is what makes rollback a one-field change.
Builds created by Adjust resources#
When you change a deploy's CPU or memory with Adjust resources, DevLyft doesn't edit the build in place. It creates a copy with the new resources, named with a version suffix (api → api-v2, api-v2 → api-v3), and switches the deploy to it. Those builds appear in your list like any other.
Deploying an older build#
To roll back, open Deployments→Edit on the deploy, choose the earlier build in Build, and Save deploy. Any build in the same project can be selected.
Failed builds#
Because a build is only configuration, a bad image or tag surfaces when a deploy tries to run it: its pods don't reach Running, or restart repeatedly. Check the deploy's pods on Pods and its output in Watch logs, fix the image, and create a new build (or edit the tag). See Troubleshooting.
Deleting unused builds#
Choose Delete on the row and confirm “Delete build "…"?”. Delete a build only when no deploy's Build column shows it.