squid writes access.log and cache.log to files, not to stdout - the previous
commit already explains why - which puts them entirely outside the json-file
driver's max-size the rest of the stack just got. Left alone they grow forever
on the one service in this file without read_only: true.
Bounded the same way /tmp is bounded elsewhere: a size-capped tmpfs, lost on
restart rather than kept and unbounded. Needs uid/gid=13 because squid drops to
its own "proxy" user before opening these files, and a tmpfs mount point
defaults to root-owned like any other - which failed loudly the first time,
with squid's own answer to an unopenable log being fatal rather than a quieter
fallback. Compose's long tmpfs syntax has no field for that, so this uses the
raw mount-options string the top-level tmpfs: list already uses elsewhere in
this file.
Verified under compose itself, not a bare docker run: no errors at start, and
the log files it creates are owned by proxy:proxy as expected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Docker's json-file driver never rotates on its own, and every service here is
meant to run for weeks. One x-logging anchor, reused across all six services,
so the limit lives in one place instead of six copies that could drift.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
The allowlist still named the shared service's fixed 5173, from before the dev
server handed a port per execution. Every preview would have started on a port
the browser was not allowed to open, and the failure would have read as a broken
application rather than as a refused origin - the kind of mismatch that is found
by exhausting the other explanations first.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
They were three folders on one laptop: a coding agent with a git history of its
own, and two servers - a development server and a browser - with none at all.
What makes them a stack is what sits between them, and that lived nowhere: the
compose file, the gateway, the egress proxy and the networks that keep the worker
off the internet. So the whole thing is one repository, and the coding agent's
separate history is folded into it rather than kept alongside.
What is deliberately absent: .env, node_modules, and the live service
definitions. The .example files next to them say what belongs there.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lucio Lelii