The Deployer documentation
Creating & deploying a project

Build method

The build method decides how The Deployer turns your code into the container image that runs in your cloud. Most projects never need to change it. It matters mostly when your company requires builds to go through a package repository, or when you want a particular kind of image.

Where to find it

Open your project. On its dashboard, the Build settings card has three rows: Build method, Package sources and Build location. Click Change on the Build method row to open its panel. You need permission to change the project's settings.

Not set: the current behaviour for your cloud

Every project starts with no build method chosen. That keeps exactly the behaviour your project has always had, which depends on where it deploys:

  • If your repository has a Dockerfile, it is used.
  • If it doesn't, The Deployer either writes one for your language or builds with buildpacks, depending on your cloud and architecture.

The panel tells you what "current behaviour" means for this project, for example Current behaviour (Google buildpacks) on Google Cloud. Nothing changes until you pick a method.

The three methods

MethodWhat it doesGood for
Auto (recommended)Uses your Dockerfile. If there isn't one, The Deployer writes it.Most projects, and anything that must go through a package repository
DockerfileEvery download can go through your package repository. Fails clearly if your repository has no Dockerfile and your language has no ready-made one.Teams that want full control and no surprises
BuildpacksNo Dockerfile needed. Includes a bill of materials (a list of everything inside the image) and base-image patches. Some runtimes download from the internet unless a mirror is set.Projects without a Dockerfile that want a bill of materials and patched base images

Projects on Google Cloud that already build with Google buildpacks also see that option, so they can keep it. Google buildpacks always download language runtimes from Google, so they can't be used with Private only.

Build method and Private only

If the project's Package sources mode is Private only, every download has to go through your package repository. Auto and Dockerfile handle that fully. Buildpacks only work with Private only when your package repository also mirrors the language runtimes (Node, Java and so on). If it doesn't, the panel explains why and offers Use Dockerfile instead in one click.

Switching method

  • The change takes effect on the next deploy. Choose Apply on next deploy to save it for later, or Redeploy now to build with it straight away.
  • Your app keeps running while the new build is checked. The new image is built and health-checked first. The current version keeps serving until the new one passes its health check, and stays available for rollback.
  • Some details can differ between methods: the start command, the port your app is detected on, the working folder, and the image size. The panel shows what will change on the next build before you apply it.
  • You can go back. Click Go back to the current behaviour in the panel. That also takes effect on the next deploy.

Building with another Dockerfile

With Auto or Dockerfile, the panel also asks Which Dockerfile. It is Dockerfile unless you name another file in the service's folder, such as Dockerfile.lenovo or docker/Dockerfile.prod. The panel lists the Dockerfiles the last scan found, and checks the name you type against the project's branch: whether the file is there, and whether it mounts the build secrets you have set.

This is for a repository that two places build differently. Your company's own pipeline keeps building Dockerfile, and The Deployer builds the other file, like docker build -f Dockerfile.lenovo:

  • Your repository is never changed. Only the copy The Deployer makes for each build uses the chosen file in place of Dockerfile. A Dockerfile.lenovo.dockerignore next to it is used in place of .dockerignore.
  • What the build needs comes from the chosen file. Its build secrets, arguments and private registries are what the Build arguments and secrets panel lists, not those of Dockerfile.
  • A missing file stops the build clearly. If the branch doesn't have the chosen file, the build stops at its first step and says so. The version that is running keeps running.
  • Code Readiness leaves Dockerfile alone while another file is chosen.

To go back, empty the field (or type Dockerfile).

Related