Problem
There is no way to trigger a redeploy of a self-hosted stack from inside the `loopover` container itself -- confirmed no self-update/self-restart/webhook-listener mechanism exists anywhere in `Dockerfile`, `scripts/`, or `src/selfhost/**`. This repo has a strong, tested stance against ever mounting `/var/run/docker.sock` into an app-facing container (see `docker-proxy`'s own comments in `docker-compose.yml`: "a `:ro` socket bind-mount only protects the socket inode, it does NOT restrict the Docker API... effectively host root"), and the bot itself flags raw docker-socket mounts as an IaC misconfiguration finding in the PRs it reviews (`review-enrichment/src/analyzers/iac-misconfig.ts`) -- so mounting one into its own container to enable self-redeploy would directly contradict the posture this codebase already enforces on everyone else. Sub-issue of #7720.
Area
`docker-compose.yml` (the existing `docker-proxy` sidecar pattern), `scripts/deploy-selfhost-image.sh` / `scripts/selfhost-post-update-check.sh` (the manual mechanism this replaces), possibly a new small service.
Proposal (needs a decision before implementation, not just an obvious extension)
Two real options, both requiring real design work -- this issue is scoped to deciding between them and then implementing the winner, not to just "add a tool":
- Proxy-mediated, mirroring `docker-proxy`'s existing pattern exactly: a new narrowly-scoped sidecar (or an addition to the existing proxy) allowing ONLY a restart call against the named `loopover` service/container -- everything else denied, same `CONTAINERS`/`NETWORKS` GET-only + `POST: "0"`-by-default posture, with a single, explicit allowlisted exception.
- Host companion process, entirely outside any container -- a small listener (systemd unit or similar) that only accepts a narrow "pull the given tag + restart" command, with the app container calling into it (localhost port or a mounted non-docker socket). Avoids Docker API exposure entirely but requires operators to install something outside `docker compose up`, which is a real "batteries included" regression worth weighing against option 1.
Whichever is chosen must still call through `deploy-selfhost-image.sh`'s existing validated pull-and-restart-with-health-wait logic (or an equivalent), not reinvent it.
Deliverables
Resources
`docker-proxy` sidecar config + its own doc comments (`docker-compose.yml`), `self-hosting-security.mdx:154`'s existing docker-proxy rationale writeup, `scripts/deploy-selfhost-image.sh`.
Boundaries
Redeploy trigger only -- does not include the config read/write tools (#7721, buildable independently and with a much clearer precedent). Should not ship until the security tradeoffs of whichever approach is chosen are explicitly documented for operators.
maintainer-only -- genuinely new privileged control-plane surface (first-ever container-to-deploy-mechanism path in this codebase), needs maintainer review and a real design decision, not just implementation.
Problem
There is no way to trigger a redeploy of a self-hosted stack from inside the `loopover` container itself -- confirmed no self-update/self-restart/webhook-listener mechanism exists anywhere in `Dockerfile`, `scripts/`, or `src/selfhost/**`. This repo has a strong, tested stance against ever mounting `/var/run/docker.sock` into an app-facing container (see `docker-proxy`'s own comments in `docker-compose.yml`: "a `:ro` socket bind-mount only protects the socket inode, it does NOT restrict the Docker API... effectively host root"), and the bot itself flags raw docker-socket mounts as an IaC misconfiguration finding in the PRs it reviews (`review-enrichment/src/analyzers/iac-misconfig.ts`) -- so mounting one into its own container to enable self-redeploy would directly contradict the posture this codebase already enforces on everyone else. Sub-issue of #7720.
Area
`docker-compose.yml` (the existing `docker-proxy` sidecar pattern), `scripts/deploy-selfhost-image.sh` / `scripts/selfhost-post-update-check.sh` (the manual mechanism this replaces), possibly a new small service.
Proposal (needs a decision before implementation, not just an obvious extension)
Two real options, both requiring real design work -- this issue is scoped to deciding between them and then implementing the winner, not to just "add a tool":
Whichever is chosen must still call through `deploy-selfhost-image.sh`'s existing validated pull-and-restart-with-health-wait logic (or an equivalent), not reinvent it.
Deliverables
Resources
`docker-proxy` sidecar config + its own doc comments (`docker-compose.yml`), `self-hosting-security.mdx:154`'s existing docker-proxy rationale writeup, `scripts/deploy-selfhost-image.sh`.
Boundaries
Redeploy trigger only -- does not include the config read/write tools (#7721, buildable independently and with a much clearer precedent). Should not ship until the security tradeoffs of whichever approach is chosen are explicitly documented for operators.
maintainer-only -- genuinely new privileged control-plane surface (first-ever container-to-deploy-mechanism path in this codebase), needs maintainer review and a real design decision, not just implementation.