How the build is detected

Which files count as a Dockerfile or a Compose file, how the port is found, and what happens when there are several candidates or none.

When you pick a repository and a branch, the platform reads the list of every file on that branch and works out what can be deployed from it. You get a list of applications to tick, not a form to fill in.

What is read

  • Every Dockerfile, in any directory.
  • Compose files, and the .env beside each one.
  • Other YAML files whose services name ready-made images. Those are offered separately, as stack files.

Directories that hold other people's code are skipped: node_modules, vendor, .venv, venv, site-packages, bower_components, .terraform, __pycache__ and .git.

What counts as a Dockerfile

Upper or lower case, in any directory:

  • Dockerfile and Containerfile.
  • With a suffix: Dockerfile.worker, Dockerfile.prod.
  • With a prefix: api.Dockerfile.
  • With both: api.Dockerfile.prod, web.Dockerfile.dev.

The name is also read for meaning. A word such as dev, local, test, ci, staging, prod, production or release names an environment: a second way of building the same application. Any other word names a service: Dockerfile.worker and api.Dockerfile are applications of their own.

What counts as a Compose file

compose.yaml, compose.yml, docker-compose.yaml and docker-compose.yml, in that order. One is read per directory. Others beside it, and overrides such as docker-compose.override.yml or compose.prod.yaml, are not applied, and the scan says so.

Each service with a build: section becomes an application, built from the Dockerfile and directory that section names. A Dockerfile used by a Compose service is not offered a second time on its own.

From such a service the scan also takes its environment, the env_file entries that are in the repository, and its port. Variables it expects from your machine are listed for you to set, never guessed.

Some things do not carry over, and each is said on the service concerned: volumes, the health check, build arguments, a build target, more than one copy, and a command or entrypoint override. A service that differs only by its command is left unticked for that reason.

A service that only names an image is not built. A database or broker image is listed apart, with a pointer to the managed equivalent, and any variable that points at it is flagged.

How the port is found

In this order:

  1. The Compose service's ports or expose: the container side, first TCP port.
  2. The Dockerfile's EXPOSE, in its final stage.
  3. Failing both, the built image is asked after the build. That also catches a port declared by the base image.

A detected port follows the image: if a later build exposes another one, the application moves to it. A port you type yourself is never changed by a build.

A service with no port whose name or start command says worker, consumer or scheduler is imported as a background worker: nothing is routed to it and it cannot be made public. Untick that if it does serve traffic.

Several candidates

Different services are all ticked. A repository with Dockerfile and Dockerfile.worker, or with api/Dockerfile and web/Dockerfile, gives one application each.

Environment variants are not ticked beside a plain one. With Dockerfile and Dockerfile.dev, the plain one is preselected and the other is offered unticked, so a deployment does not start a development build next to the real one.

When every recipe names an environment, production wins. With api.Dockerfile.dev and api.Dockerfile.prod and no plain file, the one named prod, production or release is ticked.

Otherwise nothing is ticked and you choose. Two files named for production, or only dev and staging, are not a question the name can settle.

The DevOps Agent, which also handles a project uploaded as a .zip, goes one step further. It reads what each recipe starts: a reloader, a watcher or a framework's development server is a development image whatever the file is called, and that outweighs the name. When a service has more than one recipe it asks you, with its recommendation and the reason, rather than picking.

Monorepos

One application per Dockerfile and per Compose service that is built, up to 20 in one import. Each is named after its directory, or after the repository for a file at the root, with the variant added: shop-worker.

When several are found, they are private unless something says otherwise: the only application of a repository, what Compose publishes on the host, and directories named like a front end (web, frontend, ui, app) are public by default.

When there is no Dockerfile

From a repository, nothing is offered. The scan says that nothing can be deployed yet and what to add: a Dockerfile, or a Compose file with a build: section. Nothing is guessed from the language of the code.

In the AI Studio it is different. When you publish a project that has no Dockerfile, one is written for it from the project's file list and its dependency manifest. It is saved in the project as an ordinary file, so you can read it, change it and commit it. A Dockerfile you wrote is never replaced. Writing one counts as AI usage. If none can be written, the build stops and says a Dockerfile is missing.

Everything can be overridden

Tick or untick any application, rename it, set its port, make it public or private, and add variables and secrets before deploying.

If a Dockerfile was missed, or needs a different build directory, add it by its path. It is read like the others.

What to read next