Skip to content
Containly

Compose override files

Since Containly 2.7.3 compose.override.yaml and every other compose file Docker used for a project are passed to each action, version updates find tags in override files, and the editor shows override files as tabs. How Containly picks the files.

Many stacks keep local changes in a second file next to compose.yaml, usually compose.override.yaml: an extra service such as Mailpit, a port mapping, a volume. docker compose loads that file automatically only when you do not name files with -f. Up to 2.7.2 Containly always named the main file, so override files were ignored. Since 2.7.3 Containly passes every file.

Which files Containly uses

  1. The files Docker recorded. Every container started by Compose carries the label com.docker.compose.project.config_files with the files of that deploy, in order. Containly uses these (from all containers of the stack), so a stack deployed with docker compose -f compose.yaml -f prod.yaml up -d keeps both files and their order. A default override file (see 2.) that exists in the folder but is missing from the label is added at the end.
  2. Before the first deploy, or when no recorded file is usable, the same rule as docker compose without -f: the main file plus the first of compose.override.yml, compose.override.yaml, docker-compose.override.yml, docker-compose.override.yaml that exists.

Only regular files inside the stack folder are used. Paths outside the folder and symlinks are ignored (and logged).

Every Containly action on the stack uses this list: deploy, pull, start, stop, restart, down, logs, the app catalog, Git stacks, CI redeploys, backups and restores, and moving a stack to another host.

In the editor

When a stack has override files, the editor shows them as tabs next to the main file, for example compose.yaml and compose.override.yaml (tagged Override). Both are editable with the same checks, unsaved changes are marked on the tab, and Check before deploy lists the saved changes of every file since the last deploy.

Version updates

An update of a pinned version tag (for example axllent/mailpit:v1.20.0 to v1.21.0) now searches all compose files of the stack and .env. Containly changes exactly the file that defines the tag: the override file when the image is only there, .env when the tag is a variable. If several files define it, all are updated together. If the redeploy fails, every changed file is restored. When the tag is in none of the files, the message names the files that were searched.

Good to know

  • A stack you deployed with plain docker compose up -d in its folder already carries the override in its label, so nothing changes for you.
  • If an older Containly redeployed such a stack and the override service was dropped, deploy it once from Containly 2.7.3: the override file is added again because it exists in the folder.
  • To stop using an override file, rename or delete it and deploy again.