BuildsBuilds overview

Builds overview

A build is a container image plus the resources it asks for. You create builds in a project, then deploy them into that project's environments.

What a build contains#

The dashboard sums it up: A build is a container image + resource request. Create one, then deploy it. Each build records:

Project
The project the build belongs to. It's fixed when you create the build.
Name
Your label for the build, such as api or api-v2. Deploy forms list builds as name:tag.
Image and Tag
The container image reference and the tag to pull, for example ghcr.io/acme/api and 1.4.2. See Docker images.
Container port
The port your container listens on. It's optional, but a deploy of this build can only be publicly exposed if it's set.
CPU and Memory
The resources each replica requests, from 0.125 CPU and 256 MB up to 4 CPU and 8 GB, with 1–4 GB of memory per CPU. See CPU and memory.

How builds relate to deploys#

ProjectBuildImage, tag, port, CPU and memory
→
EnvironmentDeployBuild + location + replicas + variables
→
DeployReplicasRunning copies of the image on shared or dedicated nodes
  • A build doesn't run anything by itself. It becomes a workload when a deploy references it.
  • Several deploys can use the same build, for example the staging deploy and the production deploy.
  • A deploy runs exactly one build at a time. To ship a new version, create a new build and point the deploy at it. See Update and redeploy.
  • The build's CPU and memory are what each replica of the deploy requests, so a build's resources are also what you're billed on for shared compute.

Where builds come from#

Today, every build starts from a container image you've already built and pushed to a registry. DevLyft doesn't build images from source.

The Builds page#

Builds lists every build across every project in the organisation, newest first. Each row shows Name, Image (as image:tag), CPU, Memory, Port, Project and Created, with Edit and Delete actions. From here you can: