Repository navigation
Add optional auto-confirm label on volumes #13807
Description
Activity
Not a maintainer, but recent Compose builds already have a non-interactive confirmation flag for some commands:
-y, --yes(Assume "yes" as answer to all prompts and run non-interactively). It is documented ondocker compose up/createin the current reference.Could you check whether this use case is already covered by:
docker compose up -y
or, for a create step:
docker compose create -y
If the volume-recreate prompt still appears even with
-y, then this issue can probably be narrowed to "the existing yes flag does not cover the volume mismatch prompt" rather than needing a new option. That would be easier to reproduce and fix without changing the CLI surface.hey @qianlongzt
The issue as filed seems already covered by the existing--yesflag, it does not establish why Compose needs a new volume-specific auto-confirm mechanism instead of using the existing non-interactive mode.@qianlongzt Ok this is not what the issue describe here. Can you update it and add a reproducible example, please?
- changed the title
[-]Support optional auto-confirm for volume recreation in CD workflows[/-][+]add optional auto-confirm label for volume recreation in CD workflows[/+]on Jun 5, 2026 - changed the title
[-]add optional auto-confirm label for volume recreation in CD workflows[/-][+]Add optional auto-confirm label on volumes for CD workflows[/+]on Jun 5, 2026 - changed the title
[-]Add optional auto-confirm label on volumes for CD workflows[/-][+]Add optional auto-confirm label on volumes[/+]on Jun 5, 2026 @glours Updated the description and added clarification about per-volume scope.
- added 2 commits that reference this issue
on Jun 5, 2026 Thanks, the per-volume scope makes the proposal clearer.
The next thing that would make this actionable is a minimal repro with two named volumes where the existing volume specs differ from the Compose file: one volume with the proposed label and one without it. Then the expected behavior can be separated from the existing global --yes flag:
- without --yes, Compose should still protect/prompt for the unlabeled volume
- with the proposed label, only the labeled volume would be auto-recreated
- with --yes, everything remains globally non-interactive as today
That would show why this needs per-volume policy instead of only the existing command-level confirmation flag.
- added 2 commits that reference this issue
on Jun 6, 2026 @vaguul Updated the description and test cases in the PR.
- added a commit that references this issue
on Jun 7, 2026 @qianlongzt
After looking at the downstream use case and discussing with @ndeloof , we don’t think we should solve this by introducing a Compose-controlled label that automatically recreates volumes.Using a label for this is too fragile and potentially dangerous: adding the label to an existing volume changes the volume spec/hash and can immediately trigger a destructive recreation path. Once enabled, any future volume spec change would also bypass the normal confirmation flow.
For the tmpfs-like / ephemeral use case described downstream, I think you should first consider existing Compose patterns:
- use a service-level
tmpfsmount when the data only needs to exist for the lifetime of the container; - use an anonymous volume with
--renew-anon-volumeswhen Compose should be allowed to replace the volume; - use an external volume and let the deployment tool own its lifecycle when recreation policy is specific to that tool.
The external-volume option is less convenient, but it keeps the destructive lifecycle decision outside of Compose and in the tool/user workflow that explicitly owns it.
So I’d prefer not to add the proposed label-based mechanism as-is. If we still want an upstream Compose feature here, we should discuss a more explicit and safer definition in the compose definition than a volume label.
- use a service-level
- I can't use a service-level tmpfs because it needs to be shared with other services.
volumes_fromis not suitable either, as it mounts everything to the same target path, which is not always possible. - These are not anonymous volumes and are not defined by the image.
- Volume hash change is acceptable in this case.
- The user has already indicated that it is safe to recreate the volume. Why ask for confirmation again?
- The label can always be removed if needed, so it is not a permanent risk. The main reason to allow it is that users explicitly opt in because volume recreation is already considered safe in their workflow.
This also raises two questions:
- Why should users be required to confirm every time if they have already opted into a safe-to-recreate mode?
- If a user explicitly adds this label, they are already acknowledging the behavior—so why treat it as unsafe or require additional gating?
I updated the use cases in the issue description.
- Shared tmpfs mounts between services
- Volume mounts that can be safely deleted without removing the underlying data (e.g., NFS volumes)
Add an option to indicate whether a volume should be recreated. kimdre/doco-cd#1130 doco-cd fails to update container when NFS mountpoint changes kimdre/doco-cd#1267
- I can't use a service-level tmpfs because it needs to be shared with other services.
Thanks for the clarification. I agree that
volumes_fromis not a complete answer for every shared tmpfs case: it mounts all volumes from the referenced service/container at the same target paths, with onlyro/rwcontrol, so it cannot select a subpath or remap the target.However, I still think the right model for this is an externally managed volume, not a Compose label that bypasses confirmation.
Compose already supports this with
external: true: the Compose file can consume a shared volume, and the deployment tool can own the lifecycle of that volume before running Compose. This also works for the multi-service case, since the same external volume can still be mounted by different services at different target paths.For
doco-cdspecifically, this seems to fit its architecture. It already has a staged deployment pipeline with apre-deploystage beforedeploy, and it loads the Compose project before invoking Compose. It also already has helper code to list/remove labeled volumes, even though that is currently used in the destroy flow rather than during pre-deploy. So doco-cd could add an explicit pre-deploy resource preparation step for doco-cd-owned external volumes: create/recreate selected volumes according to its own policy, then let Compose consume them normally.That keeps the destructive lifecycle decision in the deployment tool that owns the policy.
More generally, I don’t think managing this through labels is desirable in Compose. If we want to support this upstream, it should be through a more explicit and robust evolution of the Compose specification, not through a
com.docker.compose.*label that turns volume metadata into a destructive control instruction.If labels are not the right approach, would you be open to a new Compose volume attribute, for example:
volumes: my_vol: recreate-on-spec-change: true
This seems more explicit and aligns with your concern that destructive behavior should be expressed through the Compose specification rather than
com.docker.compose.*labels.The current volume attributes are documented here:
https://docs.docker.com/reference/compose-file/volumes/#attributesI suggest we introduce a
disposableattribute to volume definition, to tag such a volume as "can be recreated without risks to loose user's data" so compose don't need to prompt the user.Reacted by qianlongztReacted by qianlongztA
disposableattribute for volumes sounds good to me.
Description
In CI/CD workflows, changes to volumes may trigger interactive confirmation prompts, which can break automation and require manual intervention.
For example, when an existing volume does not match the Compose specification, Docker may prompt:
Volume "... " exists but doesn't match the Compose specification in the Compose file. Recreate (data will be lost)?To support non-interactive environments, it would be useful to provide an option to automatically confirm volume recreation in such cases, while keeping the default interactive behavior unchanged.
This behavior is controlled via a per-volume label, allowing precise control when multiple volumes are defined in a single Compose file. The label does not apply globally.
Example
services: app: image: alpine volumes: - my_vol:/my_vol - no_recreate_label:/no_recreate_label volumes: my_vol: driver: local driver_opts: device: tmpfs o: size=1k,uid=65530,gid=0,mode=0700,noexec type: tmpfs labels: + com.docker.compose.volume.recreate-when-spec-updated: "true" foo: bar nfs: driver: local driver_opts: type: nfs o: addr=XXX,nfsvers=4.2,soft,timeo=600,retrans=2,rsize=1048576,wsize=1048576 device: :/storage2/sonarr/media/ labels: + com.docker.compose.volume.recreate-when-spec-updated: "true" no_recreate_label: labels: foo: baruse case
kimdre/doco-cd#1130 kimdre/doco-cd#1267