Relationships
#1340 Docker-related model types/workflows would benefit from first-class dry-run/plan support
Opened by kitquiet · 7/22/2026
Problem statement
Tonight's session involved auditing and fixing a homelab's Docker Compose
stacks (via @swamp/ssh's exec/script methods, shelling out to raw
docker/docker compose commands — there wasn't a purpose-built compose
model type in play). Before applying compose changes to already-running,
production-ish containers, I wanted to see the actual plan (create/recreate/
no-op) against live state, not just validate YAML syntax.
docker compose config --quiet only validates the file — it doesn't tell you
what would actually happen. docker compose up --dry-run does: it showed,
for example, that removing unrelated stale service blocks from one compose
file would cause an unrelated, unchanged service to be marked for
recreation next time (a config-hash side effect), and that a
previously plain docker run-started container would need to be created
fresh (name conflict) rather than adopted. Neither of those was visible from
config validation alone, and I only found --dry-run because the human
using swamp already knew about the flag and suggested it — swamp itself
didn't surface or encourage it anywhere in the exec/script workflow.
Proposed solution
For docker-related model types (e.g. @adam/cfgmgmt's docker_container/
docker_image, which already follow a check/apply pattern) and generally for
any workflow that shells out to tools with native plan/dry-run support
(docker compose, terraform, etc. — via @swamp/ssh exec/script or a
future docker-compose-specific extension), it'd help to have a first-class,
discoverable way to preview the actual change plan before applying:
- For typed model types with a check/apply split: consider whether
checkalready surfaces this, or whether a distinctplan-style method/flag makes sense for compose-shaped resources specifically (since compose's own dry-run reasons about the whole project file, not a single resource). - For the generic
@swamp/sshexec/script path: maybe just a doc/skill callout (e.g. in the swamp skill's guidance) suggesting dry-run flags for common tools (docker compose, terraform plan, etc.) before mutating calls, so agents/users reach for it by default rather than by luck.
Alternatives considered
- Just rely on users/agents knowing about each tool's own
--dry-runflag (status quo) — works, but it's easy to miss, as this session shows. - A dedicated
@swamp/*docker-compose model type with its ownplan/applymethods, mirroring@swamp/ssh's fleet pattern — bigger lift, but would make this a native, typed capability rather than raw shell exec.
Context
Not a specific bug — a workflow/DX idea from real usage. Filing per a homelab user's request to raise it for the swamp team to evaluate.
Open
No activity in this phase yet.
Sign in to post a ripple.