Utilize a label to tag dependency containers for update or restarts

[begunfx]

Since drydock is the orchestrator for container updates it should know when a container has a dependency on another container and will get updated or restarted when the parent is updated.

For example I have tdarr which has node containers on remote hosts. The tdarr parent and nodes must always be updated together. Having a label designating the nodes as dependencies should trigger updates for the nodes if the parent updates or have the option to just trigger a restart.

[s-b-e-n-s-o-n]

Great idea — this is something we've been thinking about too.

We have Container Dependency Ordering planned for v1.7 (Phase 6.1 on the roadmap). The plan includes:

• Auto-detection of depends_on relationships from Docker Compose files
• Manual override via a dd.depends_on=container_a,container_b label — so you could label your Tdarr nodes with dd.depends_on=tdarr and drydock would know they're linked
• Topological sort for update execution order (databases before apps, apps before proxies)
• Cycle detection with warnings
• Respecting dependency order in batch and Docker Compose trigger operations

Your Tdarr use case is a perfect example of why this matters — parent + nodes need to stay in sync, and updating them out of order (or missing the nodes entirely) can break things.

The restart-only option for dependents ("parent updated → restart nodes without pulling a new image") is a nice addition we hadn't explicitly called out — I'll make sure that's captured in the spec. Sometimes you just need the dependent containers bounced, not necessarily updated to a new image.

Thanks for the detailed example — it helps validate the design. If you have other dependency patterns you run into beyond Tdarr, feel free to share them here.

[begunfx]

In addition to adding dependency linking via labels I would also recommend showing those dependencies in the container list. So containers that are dependencies on other dependencies are shown in a hirearchy so the relationship is visualized. Also, if the parent has an update the dependencies should probably always show up below it even if they don't have an update so the user knows that those containers will be impacted by the update (action taken on them).

[s-b-e-n-s-o-n]

Both good ideas — they fit naturally into the dependency work.

Hierarchy in the container list: We already have container grouping (via compose project or dd.group label) that renders collapsible stacks. Dependency relationships could layer on top of that — showing parent → dependent ordering within a group, with a visual indicator (indentation or a small tree line) so the relationship is clear at a glance.

Surfacing impacted dependents alongside updates: This one is particularly useful. When Tdarr has an update available, showing the node containers underneath it (even though they don't have a pending update) makes it obvious what's going to happen when you hit update. We could tag them with something like "will restart" or "will be bounced" so it's clear they're not being updated to a new image, just restarted as part of the dependency chain.

I'll capture both of these as requirements in the v1.7 dependency spec. Thanks for thinking through the UX side of this.

[s-b-e-n-s-o-n]

Actually, thinking about this more — rather than layering dependency hierarchy into the existing stack/group view, a dedicated dependency view (as a separate view mode alongside the stack view) would probably work better. Stacks are about compose projects and logical grouping; dependencies are about update-time relationships and execution order. Mixing both into one view gets noisy fast.

A dependency view could show tree lines from parent → dependents, with badges like "will restart" or "will update" on the dependents when the parent has a pending update. You'd switch between stack view and dependency view the same way you switch grouping modes today.

[begunfx]

Works for me. My only recommendation is that the dependency view has the ability to take action on the containers like the stack view.

[begunfx]

Thinking a little further through this. Another scenario: What if a user updates a container on the updates available page or stack page but it has dependencies (using tdarr as an example). Unless the user triggers the update from the dependency page, it will not be clear to them that other containers will be affected (e.g., restarted or updated). What if the container has a dependency, then maybe the dependency chain should be displayed in the update confirmation dialog so the users knows what other containers will be affected by selecting update. Another scenario: What if the user tries to update a dependent container (ex tdarr_node) instead of the parent? How do you plan on handling that? Require the rest of the dependency chain to update or at least notify the user that the user should update the parent container noting that updating the child may have negative impact or something like that?

[s-b-e-n-s-o-n]

Really appreciate the continued thinking here — the follow-up comments shaped the spec significantly. Here's where we landed on each point:

Dependency hierarchy view — Agreed. Containers with dd.depends_on relationships will render as a visual tree in the container list, so the parent/child relationship is always visible even when nothing is being updated. This will be its own view mode alongside the current stack/ungrouped views.

Confirmation dialog showing dependency chain — Agreed, and this is critical UX. When you click Update on a container that has dependents, the confirmation dialog will list every container that will be affected (updated or restarted) so there are no surprises. Something like:

Update tdarr? This will also restart: tdarr_node_1, tdarr_node_2

Child-before-parent guard — Agreed. If you try to update a dependent (e.g. tdarr_node) directly, we'll show a warning that the parent (tdarr) should be updated first, with an option to update the parent instead. For restart-only dependents this is less of a concern, but for update dependencies it's important to prevent version skew.

Dependency group actions — Agreed. The dependency view will support the same action bar as stack view (Update All, etc.), operating on the full dependency chain.

All of this is captured in the Phase 6.1 spec for v1.7. For now, if you need to chain actions today, you can use post-hooks as a workaround:

labels:
  dd.hook.post: docker restart tdarr_node_1 tdarr_node_2

This runs after the parent updates successfully and will bounce the nodes. Not as clean as the native dependency system, but it works for the Tdarr use case today.