​
Builder Configuration

These environment variables control how migetpacks builds your application.

​
Caching Options

These variables configure build caching for faster subsequent builds.

​
Docker Hardened Images

These variables enable Docker Hardened Images for secure, minimal containers.

​
External Private Registry

Set these variables when your Dockerfile pulls a base image from a private registry (any FROM <private-host>/... line). The builder runs docker login before invoking the build, so subsequent pulls authenticate. Values may come from the environment directly or from the platform’s BUILD_VARS JSON envelope. All three must be present for the login step to run. Login failure is logged and non-fatal — the FROM-pull error then surfaces during docker build, matching the DHI block’s behaviour.

​
Example

docker

​
Custom Environment Variables

Any environment variable passed to migetpacks that is not in the known builder variables list is automatically injected into the generated Dockerfile as an ENV statement. This allows you to configure your application’s build environment without modifying any configuration files.

​
How It Works

  1. You pass an environment variable to the migetpacks container (e.g., -e NODE_OPTIONS="--max-old-space-size=4096")
  2. The builder checks whether it matches any known builder variable pattern
  3. If it does not match, it is added to the generated Dockerfile as an ENV instruction
  4. The variable becomes available during both the build and runtime stages
The generated Dockerfile will include:

​
Common Use Cases

Increase the V8 heap size for large builds that run out of memory:
Inject variables consumed by Vite, Next.js, or similar frameworks during the build:
Provide the master key so Rails can decrypt credentials during asset precompilation:
Pass arbitrary flags to your build tooling:

​
Filtered Variables

The following categories of variables are never passed through to the Dockerfile:
  • Builder config: SOURCE_DIR, OUTPUT_IMAGE, LANGUAGE, BUILD_COMMAND, RUN_COMMAND, PORT, ARCH, CACHE_IMAGE, NO_CACHE, CACHE_MODE, CACHE_FROM, BUILDPACKS, USE_DHI, REGISTRY_MIRROR, RESULT_FILE, STORAGE_DRIVER, etc.
  • Language-specific: Go build flags, Scala/sbt options, Clojure/Leiningen settings
  • Credentials: AWS_* variables (never exposed in images)
  • Docker/system: DOCKER_HOST, DOCKER_CONFIG, DOCKER_BUILDKIT, etc.
  • Shell/system: PATH, HOME, PWD, TERM, SHELL, USER, HOSTNAME, LANG, LC_*, XDG_*, SSH_*, etc.

​
Build-arg name requirements

App environment variables reach the build through the platform’s BUILD_VARS envelope and are projected as Docker build args (--build-arg flags and generated ARG lines). Build args — like shell variables and Dockerfile ARG/ENV keys — must be POSIX identifiers (IEEE Std 1003.1 §8.1): a letter or underscore followed by letters, digits, or underscores, i.e. ^[A-Za-z_][A-Za-z0-9_]*$. Keys that don’t satisfy this rule — for example dotted settings such as discovery.seed_hosts (used by Elasticsearch and other JVM apps) — are skipped from the build-arg projection and logged. They are still delivered to the running container as ordinary environment variables; they simply cannot be build args, because ARG discovery.seed_hosts is not a valid Dockerfile instruction.
  • Runtime env (Compose Specification, permissive): keys are preserved verbatim.
  • Build args (POSIX / Docker ARG): only identifier-safe keys are projected; the rest are runtime-only.
If you need a non-identifier setting available at build time, expose it under an identifier-safe alias (e.g. ES_DISCOVERY_SEED_HOSTS) and reference that in your Dockerfile or build script.