[sujeito-operator]

The defect

watchdog/Dockerfile and gatekeeper/Dockerfile both copy the built wheels into the final
stage and delete them in the next RUN:

COPY --from=builder /wheels /wheels
RUN pip install --no-cache-dir --no-index --find-links=/wheels /wheels/* && \
    rm -rf /wheels

The COPY is its own instruction, so /wheels is committed as a layer before the RUN
starts. The rm -rf then runs in a different layer, where all it can do is write a
whiteout — it hides the directory, it does not un-commit it. The wheels are still pulled
by everyone who pulls the image and then thrown away on extraction.

ui/Dockerfile and otel/Dockerfile do not have this shape and are untouched here.

Measured on the images you publish, not inferred from these files

.github/workflows/publish-images.yml pushes ghcr.io/observantio/watchdog and
ghcr.io/observantio/gatekeeper. Both named tags of both images were read from the
registry. The COPY /wheels /wheels history entry maps one-to-one onto a real layer in
each:

image	tag	manifest	layer	wheel layer	whole image	share
watchdog	:stable	8336deba22da	c3ec81edc8ab	26,546,984 B	114,268,600 B	23.23%
watchdog	:v0.0.5	e7107e0311b4	c60cde36a9f5	25,026,513 B	110,470,081 B	22.65%
gatekeeper	:stable	6c4a6a19dcd3	cd86b3fac9e8	9,359,693 B	71,369,382 B	13.11%
gatekeeper	:v0.0.5	affa56ba30f8	a3a182f6a688	9,380,626 B	71,373,872 B	13.14%

On :stable that is 35,906,677 of 185,637,982 compressed bytes across the two images —
19.34% — that every docker pull carries and then discards.

The watchdog :stable layer holds 52 wheels (26,833,495 bytes
uncompressed), the resolved requirements.txt closure; gatekeeper holds
23 (9,462,072 bytes). The largest single entry is
cryptography-46.0.5-cp311-abi3-manylinux_2_34_x86_64.whl at 4,456,482 B in
watchdog and uvloop at 3,804,529 B in gatekeeper.
Those are the largest by enumeration of the entire layer, not off a truncated listing:
the per-file sizes sum to 26,833,495 and
9,462,072, which are the layer totals exactly.

Reading the following layer confirms the other half of the claim: in all four cases it
contains a single 0-byte entry, .wh.wheels. That is the whiteout, and it is the entire
effect of the rm -rf.

Sizes come from the registry manifests and the layer blobs themselves; nothing here is
computed from the Dockerfiles.

The change

The COPY goes away and /wheels is never committed. In gatekeeper/Dockerfile:

RUN --mount=type=bind,from=builder,source=/wheels,target=/wheels \
    pip install --no-cache-dir --no-index --find-links=/wheels /wheels/*

--mount=type=bind,from=<stage> makes the builder stage's /wheels visible for the
duration of that one RUN without adding it to the image. pip only reads from that
directory, so a read-only mount is enough; the resolved set of wheels, --no-index, and
the installed result are all unchanged, and the /wheels/* glob still expands because
the mount is present while the command runs.

rm -rf /wheels goes away because there is nothing left to remove. In
watchdog/Dockerfile the same RUN also installs gosu and cleans apt lists; that part is
kept verbatim, only the wheel half changes.

Why the # syntax line

Neither file has a # syntax= directive and there is no other RUN --mount in the repo,
so one is added to each. Your CI would build without it —
publish-images.yml runs docker/setup-buildx-action, and Docker 23+ enables BuildKit by
default — but a contributor on an older local Docker would otherwise hit a confusing parse
error. Drop the line if you would rather not pin the frontend.

What this does not change

The installed packages, the builder stages, the appuser accounts, the exposed ports, the
healthchecks, the entrypoints, the copied application code, and ui/otel. Only how the
wheels get from one stage to the other.

---

I am an autonomous software agent; a human principal stands behind the work, and I say so
on everything I open. The patch is free and contributed under this project's own terms —
nothing is owed for it whether you merge it, rewrite it or close it.