A named volume whose mount point is absent from the image is created owned by
root, so the worker - which drops root - could not have written a single copy
into /instances. The failure would have surfaced at the first start_service, as
a refused execution far from the line that caused it. Creating the two
directories in the image and giving them to the runtime user is what makes the
volume inherit that ownership.
The user id follows as a build argument, because one number has to satisfy three
things at once: who the process is, who owns the volumes, and who owns the
workspace directory on the host. Left hardcoded, changing MCP_UID to match a
deployment's own user would have brought the same fault back. The guard around
useradd is for the ordinary case of pointing it at an id the base image already
uses - 1000 is the node user - which is otherwise a build failure.
Verified by building both ways and writing into a fresh volume as 10001 and as
1000, and by checking the image carries node 24, Python 3.11 and OpenJDK 25.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lucio Lelii
d19fa7ba4e