[earakely-scale]

Why. Since #277, installs run the infra images published on GHCR instead of building them. A published image is rebuilt only when its sources change, since its tag is the build context's source digest. What a build pulls in isn't a source: the image behind a tag-only FROM, and the packages apt-get, pip and npm install. So a base's security fixes never reached the published image until someone edited its Dockerfile. Before #277, every host build picked them up.

Change

• Pinned by digest, to the multi-platform index each tag serves now (all include linux/amd64 and linux/arm64):

  • public.ecr.aws/docker/library/postgres:16-alpine (service-db) → @sha256:721873c3…
  • public.ecr.aws/docker/library/python:3.12-slim-bookworm (db-mcp) → @sha256:6a0e06f5…
  • ghcr.io/astral-sh/uv:python3.12-bookworm-slim (db-mcp's builder) → @sha256:e5b65587…

  The gateway, website-browser and db-web bases were already pinned.

• Dependabot: a weekly docker update for the three infra Dockerfile folders, grouped so one PR bumps them all. Merging a bump changes the image's sources, so the next release builds and publishes it, re-pulling the bases and packages. The wheel records the new digest, and installs switch to it on their next run.

• Test: test_every_infra_image_pins_its_bases_by_digest_and_dependabot_bumps_them fails if a shipped infra Dockerfile has a base without a digest (references to an earlier build stage don't count), or sits in a folder Dependabot doesn't watch.

• Docs: AGENTS.md and CONTRIBUTING.md say the bases are pinned and that Dependabot bumps them.

Effects

• New service-db tags. Pinning changes the service-db folder, which is the build context of all three service-db images, so they all get new source tags. This PR carries bump-version, so its release builds and publishes them. That also shows the image jobs can still push now that the packages accept pushes only from this repo's Actions.
• Dependabot PRs for the stale pins. The gateway's python:3.11-slim and website-browser's node:22-slim pins are older than their tags, so Dependabot will probably open a bump PR soon after this merges. That will be the first real run of the flow.
• CI builds the new service-db images. The service-db sources aren't published yet, so CI's slow tier builds all three images on the runner from the new pins, and its deploys run on them.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no actionable issues were found.

Summary

Pins the remaining service-db base images by digest and adds weekly, grouped Dependabot updates.

• Service-db images now use fixed base-image digests.
• Dependabot now groups weekly updates for every shipped image folder.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Dependabot updates a base digest] --> B[Dockerfile bytes change]
  B --> C[Source tag changes]
  C --> D[Next release builds and publishes]
  D --> E[Wheel records the new image digest]

Loading

_{Reviews (1) · Last reviewed commit: "fix(env): pin the infra images' base ima..." · Reviewed by Greptile}

[earakely-scale]

Chaos run, about 17 minutes on five fresh admin VMs. Each VM built random service-db, db-web and db-mcp images from this branch's pinned bases, and ran infra_build.py smoke on every image it built. A trial was the default builder, the legacy builder (DOCKER_BUILDKIT=0), --pull, --no-cache, or all three images building at once. Every third trial pruned all images, so later builds started cold.

VM	Docker	Builds and smokes
Amazon Linux 2023 x86	25.0.16	53/53
Amazon Linux 2023 arm64	25.0.16	86/86
Debian 12 arm64	20.10.24, no buildx	33/33
Ubuntu 24.04 x86	29.1.3, containerd store	48/48
Ubuntu 24.04 arm64	29.1.3, containerd store	92/92

That's 312 builds and 312 smokes with no failures, and no rate limits pulling the pinned bases from public.ecr.aws and ghcr.io.

On both Ubuntu VMs, the branch also ran the timing bundle's env task twice on the local provider from fresh stores. All 4 runs passed, taking 79–93 s for the first and 31–35 s for the second. The service-db sources changed and aren't published yet, so the host built them from the new pins (building, which can take minutes), while the gateway was registered from its published image. The VMs, security group and key pair are deleted.