Overview

migetpacks supports Docker Compose files for building multi-service applications. When a compose file is detected, all services with a build section are built and pushed to the registry as separate images.

Detection Priority

migetpacks looks for compose files in the following order:
1

COMPOSE_FILE environment variable

If set, this path is used directly.
2

compose.yaml

The modern default compose file name.
3

compose.yml

Alternative YAML extension.
4

docker-compose.yaml

Legacy Docker Compose file name.
5

docker-compose.yml

Legacy alternative YAML extension.
If none of these files are found, migetpacks falls back to standard language detection and single-image build.

Image Naming

Each service’s image is named by appending the service name to OUTPUT_IMAGE:
For example, with OUTPUT_IMAGE=registry.io/myapp:latest:

Example

compose.yaml

Project Structure

Build Command

Build Output

The build produces three images:
  • registry.io/myapp-api:latest
  • registry.io/myapp-web:latest
  • registry.io/myapp-worker:latest

Custom Compose File

Use COMPOSE_FILE to specify a non-standard compose file:

Compose File Syntax

migetpacks supports both the full and shorthand build syntax:

Services Without Build Sections

Services without a build section (e.g., database services using pre-built images) are skipped:
Only api and web are built; postgres and redis are ignored.

Build Caching with Compose

Registry-based caching works with compose builds. Each service gets its own cache image:

CI/CD Example

GitHub Actions

This produces:
  • your-registry.io/myapp-api:{sha}
  • your-registry.io/myapp-web:{sha}
  • your-registry.io/myapp-worker:{sha}