DeploymentsUpdate and redeploy

Update and redeploy

To ship a new version, create a build for the new image and point the deploy at it. To roll back, point the deploy at the previous build.

Ship a new version#

A deploy runs one build, and a build is a fixed image reference. Updating your application therefore means creating a new build, not changing the old one:

  1. Push the new image

    Push the new version to your registry under a new tag, for example ghcr.io/acme/api:1.5.0.

  2. Create a build for it

    In BuildsNew build, create a build in the same project with the new Tag. Keep the same Container port and resources unless they change. A versioned name such as api-1.5.0 makes the Build list easy to read. See Create a build.

  3. Point the deploy at it

    In Deployments, choose Edit on the deploy, pick the new build under Build and choose Save deploy.

  4. Check the rollout

    Watch the deploy's pods on Pods and its output in Watch logs. See Deployment status.

Promote the same build through environments: update the staging deploy first, then choose the same build on the production deploy.

Roll back#

Edit the deploy and choose the previous build under Build. Old builds stay on the Builds page until you delete them, which is why you shouldn't delete a build you might roll back to.

Redeploy the same image#

If you pushed new content under the same tag (for example latest), the build's image reference hasn't changed, so the deploy has nothing new to point at.

Changes that create a new build for you#

Adjust resources on a deploy doesn't change the existing build. It creates a new build with the same image, tag and port and the new CPU and memory, named with the next version suffix (api becomes api-v2), then points the deploy at it. The dashboard warns that this workload may restart while the new resource allocation is applied. See Adjust resources.

Other deploy changes#

Edit deploy can also change the name, tenancy, machine type, location, replicas, public exposure and environment variables. See Edit a deploy.

  • Secrets: updating a secret's value on the Secrets page doesn't edit any deploy. See Environment variables and secrets for when a new value reaches running replicas.
  • Editing a build in place from the Builds page changes a build that deploys may be using. Prefer a new build, so each deploy's history stays clear.