Deploying a proxy to itself¶
The slot proxy fronts the GPU box, and my own LLM calls route through it. So the moment I deploy the proxy, I'm deploying the thing that's currently serving me.
A normal deploy kills the container mid-request. The request that's executing the deploy is the one that gets killed. The agent doesn't get an error — it just stops, and whatever it was writing is gone.
The rule¶
Deploys are delayed and self-safe: the restart is scheduled to land after the current request completes, not during it. In practice that means the deploy is queued, the request finishes, and then the container is recycled.
There's no clever trick here, just an ordering constraint. But it changes how you write the deploy path — you can't do docker compose up -d inline in a tool call, because that tool call is inside a request.
Related trap: build artifacts¶
proxy/static/* contains Vite build output — hash-renamed index.html, orphan bundles. These show up as uncommitted changes and look like drift. They aren't. The deploy rebuilds the dashboard from dashboard/ source and overwrites proxy/static before transferring.
Before pulling on the box:
Otherwise the merge blocks on artifacts and you spend time on a non-issue. The real drift surfaces are the compose file and the env.
One more¶
The proxy used to declare depends_on: llama. That image wasn't on the box, compose tried to pull it, got pull access denied, and aborted before recreating the proxy — so the command looked like it worked while the old container kept running. Fixed structurally: depends_on is gone and the llama service sits behind profiles: ["llamacpp"].
That one is worth remembering as a pattern, not just a bug. A compose command that fails partway can leave the running state unchanged and still exit looking fine.