The mongodb-js/devtools-docker-test-envs repo provides Docker images and docker-compose configurations used by DevTools projects (Compass, mongosh, etc.) to spin up a variety of MongoDB test environments (enterprise, LDAP, SCRAM, sharded, SSH, TLS, Kerberos, etc.).

These environments are currently hard‑wired to pull images from Docker Hub, for example:

• image: mongo

• image: docker.io/bitnamilegacy/mongodb-sharded:6.0.10

• image: docker.io/bitnamilegacy/mongodb

• image: devtools-mongodb-enterprise:${MONGODB_VERSION:-4.4} (built from Dockerfiles that ultimately pull from MongoDB repos).

We want downstream consumers (like Compass Evergreen) to be able to redirect these pulls through an alternate registry (for example, an AWS ECR Docker Hub pull‑through cache), without changing local developer workflows or hard‑coding any ECR‑specific details into this repo.

---

Requirements

R1 – Global registry override

Add support for an environment variable (name suggestion: IMAGE_REGISTRY) that allows callers to override the registry/host used for all Docker Hub–backed images in this repo:

• When IMAGE_REGISTRY is unset, behavior must remain exactly as today: images are pulled from Docker Hub (e.g. mongo, docker.io/bitnamilegacy/...).

• When IMAGE_REGISTRY is set (e.g. to example.com/docker-hub), all relevant images should be pulled from that registry instead, preserving the image path and tag semantics.

Acceptable approach:

• For images that currently reference Docker Hub explicitly or implicitly (for example mongo, docker.io/bitnamilegacy/mongodb-sharded:6.0.10, docker.io/bitnamilegacy/mongodb), compute the effective image name at runtime as:

• • Host: derived from IMAGE_REGISTRY (full string provided by caller; this ticket should not assume anything ECR-specific).

• • Path + tag: based on the existing image name, stripping any original registry host where appropriate.

Implementation details are up to you, but the result should let a caller set something like:
 
IMAGE_REGISTRY=<ECR_DOCKER_HUB_CACHE_REGISTRY>/docker-hub

and have all Hub-based images pulled via that registry, without this repo needing to know what ECR is.

R2 – docker-compose support

Ensure all Docker environments that are intended for CI/local testing and currently pull from Docker Hub honor IMAGE_REGISTRY:

• Update the docker-compose files in docker/ (enterprise, ldap, scram, sharded, ssh, tls, kerberos, etc.) to use the computed image value rather than hard‑coded Docker Hub hosts.

• When IMAGE_REGISTRY is not set, the effective compose config should be unchanged from today.

R3 – JavaScript wrapper support

The package exposes a JavaScript API used by tools like compass-scripts to programmatically spin up environments:
 
{{const createTestEnvs = require('@mongodb-js/devtools-docker-test-envs').default;
const envs = createTestEnvs(['enterprise', 'ldap', 'scram', 'sharded', 'ssh', 'tls', 'kerberos']);}}

Update this wrapper so that:

• It respects IMAGE_REGISTRY in the same way as the docker-compose CLI paths (or delegates to the same logic).

• Callers do not have to change their code; the override should be automatic based on environment variables / config passed to the library.

R4 – Backwards compatibility and documentation

• All existing flows (local docker-compose, current JS consumers, mongosh/Compass connectivity tests) must continue to work without changes when IMAGE_REGISTRY is unset.

• Add a short README section describing:

• • Purpose of IMAGE_REGISTRY.

• • Example usage with docker compose and via the JS wrapper.

• • Clarify that the variable is a generic prefix/host override and not tied to any specific vendor.

---

Acceptance Criteria

• AC1: With IMAGE_REGISTRY unset, docker-compose configs and JS consumers behave exactly as today (same image names, same registry, same tags).

• AC2: With IMAGE_REGISTRY set to a non-empty value, compose files and JS consumers pull all Docker Hub–backed images from the configured registry, without any code changes in downstream repos.

• AC3: New behavior is covered by simple automated tests (unit or integration) and documented in the repo’s README.

• AC4: Local developer usage documented in internal DevTools onboarding docs remains valid (no extra steps required for a default Docker Hub flow).