Overview

migetpacks is a containerized build runtime that detects your application’s language, generates an optimized multi-stage Dockerfile, and builds a production-ready container image. It runs entirely inside a Docker container using Docker-in-Docker (DinD).

Build Flow

The build process follows a linear pipeline:
  1. Detect (bin/detect) — Identifies the programming language from source files
  2. Detect Version (bin/detect-version) — Reads version from .node-version, .nvmrc, .ruby-version, package.json, etc.
  3. Generate Dockerfile (bin/build) — Creates a multi-stage Dockerfile using the language-specific library
  4. Build — Runs docker buildx build with BuildKit features
  5. Push — Pushes the built image to the target registry (or loads locally)

Docker-in-Docker (DinD)

migetpacks starts a Docker daemon (dockerd) inside its own container. This provides:
  • Isolation from the host Docker daemon
  • Control over BuildKit configuration
  • Registry mirror configuration
  • Custom storage driver options

Daemon Configuration

The internal Docker daemon is configured with:

MTU Configuration

The Docker network MTU is lowered by 50 bytes from the host MTU to accommodate overlay network encapsulation headers:
This prevents packet fragmentation when running inside Kubernetes overlay networks (Flannel, Calico, Weave).

Storage Driver

The default storage driver is overlay2. For nested DinD environments where overlay2 is not available, use fuse-overlayfs:

Multi-Stage Builds

Every generated Dockerfile uses multi-stage builds to separate build dependencies from the runtime image:
Benefits:
  • Runtime image contains only production dependencies
  • Build tools and intermediate files are not shipped
  • Smaller image size and reduced attack surface

BuildKit Features

migetpacks leverages BuildKit for advanced build capabilities:

Cache Mounts

Package manager caches are mounted as BuildKit cache volumes, persisting across builds:
This avoids re-downloading packages when only source code changes.

Inline Cache

When CACHE_IMAGE is set, BuildKit exports cache metadata inline with the image, enabling cross-machine cache reuse:

Additional Cache Sources

Use CACHE_FROM to specify additional read-only cache sources:
These are skipped when NO_CACHE=true.

Layer Caching Strategy

Dockerfiles are generated with optimized layer ordering to maximize cache hits:
This optimization means dependency installation is skipped for most iterative builds, saving significant time.

Registry Mirror

When REGISTRY_MIRROR is set, it is configured in the Docker daemon’s registry-mirrors list. All image pulls automatically try the mirror first before falling back to Docker Hub:
This is particularly effective for:
  • Avoiding Docker Hub rate limits
  • Reducing pull times in private networks
  • Caching base images locally (e.g., Harbor pull-through proxy)

Security Model

Non-Root Runtime

All generated containers run as a non-root user (miget uid 1000, or nonroot for DHI). This prevents privilege escalation and meets Kubernetes Pod Security Standards.

Read-Only Source Directories

Source code is mounted read-only (readOnly: true) when possible. migetpacks copies source to a working directory before building, so the original source is never modified.

Credential Filtering

The KNOWN_BUILDER_VARS list in bin/build ensures sensitive environment variables are never written to the generated Dockerfile:
  • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN — never exposed
  • DOCKER_CONFIG — not written to image
  • Builder-internal variables — filtered out
Only unknown environment variables (user-defined) are injected as ENV statements in the Dockerfile. This enables passing build-time configuration like NODE_OPTIONS or VITE_API_URL while keeping secrets safe.

Image Provenance

BuildKit records build provenance metadata, including:
  • Source commit information (when available)
  • Build timestamps
  • Builder image version

Component Reference