Overview

migetpacks prioritizes its optimized multi-stage builds for known languages. A Dockerfile in your project is only used as a fallback when no supported language is detected. To force migetpacks to use your Dockerfile, set LANGUAGE=dockerfile or DOCKERFILE_PATH.

Detection Priority

1

Explicit override (DOCKERFILE_PATH or LANGUAGE=dockerfile)

If DOCKERFILE_PATH is set, or LANGUAGE=dockerfile is specified, your Dockerfile is used immediately.
2

Language detection

migetpacks checks for supported languages (Ruby, Python, Go, Node.js, etc.) and generates an optimized build.
3

Dockerfile fallback

Only if no supported language is detected, migetpacks falls back to using Dockerfile in your project root.
This priority order ensures you get migetpacks’ optimized builds by default. If your project has both package.json and Dockerfile, migetpacks will detect Node.js and generate its own Dockerfile. Use LANGUAGE=dockerfile to override this behavior.

Using DOCKERFILE_PATH

Point to a specific Dockerfile when it is not in the default location:
DOCKERFILE_PATH is relative to the project root (or PROJECT_PATH if set). You can also use an absolute path.

Examples

Standard Dockerfile in Root

If your project has a Dockerfile in the root directory, no extra configuration is needed:

Multiple Dockerfiles

Projects with environment-specific Dockerfiles:

Monorepo with Custom Dockerfile

Combine PROJECT_PATH and DOCKERFILE_PATH:
This looks for the Dockerfile at services/api/Dockerfile.production.

Use Cases

Custom Base Images

When you need a specific base image not supported by migetpacks:
If the base image lives in a private registry, set EXTERNAL_REGISTRY_URL / EXTERNAL_REGISTRY_USERNAME / EXTERNAL_REGISTRY_PASSWORD on the build so the builder can authenticate before pulling.

Complex Multi-Stage Builds

When your build process requires custom stages:

Specific Optimization Needs

When you need fine-grained control over layer ordering, build arguments, or caching:

Build Caching with Custom Dockerfiles

Registry-based caching (CACHE_IMAGE) works with custom Dockerfiles:
BUILD_CACHE_DIR and language-specific BuildKit cache mounts are only available in auto-generated Dockerfiles. If you use a custom Dockerfile, you must manage cache mounts yourself.

What migetpacks Still Provides

Even when using a custom Dockerfile, migetpacks handles:
  • Building the image with BuildKit
  • Pushing to the target registry (OUTPUT_IMAGE)
  • Registry-based caching (CACHE_IMAGE)
  • Architecture targeting (ARCH)
  • Registry mirror configuration (REGISTRY_MIRROR)
  • Result file generation (RESULT_FILE)
  • Port detection from the built image