Overview

migetpacks supports three complementary caching strategies that work together to minimize build times:
  1. Registry-based BuildKit cache (CACHE_IMAGE) - stores build layers in a container registry
  2. Shared package manager cache (BUILD_CACHE_DIR) - persists dependency downloads on a shared volume
  3. Docker layer caching - optimized COPY order in generated Dockerfiles

Registry-Based Cache (CACHE_IMAGE)

Store BuildKit cache layers in a container registry for sharing across builds, runners, and CI environments.

Cache Mode

Control how much data is stored in the registry cache with CACHE_MODE:
Caches only the final layer. Produces smaller cache images but fewer cache hits on intermediate layers.

Additional Cache Sources (CACHE_FROM)

Read from multiple cache sources (comma-separated). Useful for sharing cache across branches or teams:
CACHE_FROM sources are read-only. The build always writes to CACHE_IMAGE but can read from both CACHE_IMAGE and all CACHE_FROM entries.

Force Fresh Build (NO_CACHE)

Skip reading from cache while still exporting to the cache registry:
When NO_CACHE=true:
  • --no-cache is passed to the build
  • CACHE_FROM sources are skipped
  • Cache is still exported to CACHE_IMAGE (so subsequent builds can use it)

Insecure Registry (CACHE_REGISTRY_INSECURE)

For internal HTTP registries (e.g., a local cache registry), enable insecure mode:

Shared Package Manager Cache (BUILD_CACHE_DIR)

Mount a persistent volume to cache package manager downloads across builds. This is especially effective on self-hosted runners or Kubernetes environments with ReadWriteMany (RWX) PersistentVolumeClaims.

Cache Directories by Language

BuildKit cache mounts (--mount=type=cache,sharing=shared) are automatically added to generated Dockerfiles for all supported languages. The sharing=shared mode allows concurrent builds to share cache without locking.

Kubernetes PVC Example

Docker Layer Caching

All generated Dockerfiles use optimized COPY ordering to maximize Docker layer cache hits. This requires no configuration and works automatically.

How It Works

Cache Behavior

This optimization is applied for all languages:
  • Node.js: package.json + lockfile copied first
  • Python: requirements.txt / pyproject.toml copied first
  • Ruby: Gemfile + Gemfile.lock copied first
  • Go: go.mod + go.sum copied first
  • Rust: Cargo.toml + Cargo.lock copied first
  • Java: pom.xml / build.gradle copied first
  • .NET: *.csproj / *.sln copied first

Combining Strategies

For optimal performance, use all three strategies together:
This gives you:
  • Registry cache: BuildKit layers cached remotely (works across machines)
  • Package cache: Dependency downloads cached locally (fastest for reinstalls)
  • Layer cache: Docker layer ordering optimized (fastest for source-only changes)
  • Registry mirror: Base image pulls from local cache (fastest for image downloads)

Registry Mirror

Use REGISTRY_MIRROR to configure a pull-through cache for Docker Hub base images:
The mirror is configured in the Docker daemon’s registry-mirrors setting, so all image pulls automatically try the mirror first before falling back to Docker Hub.