Portainer-managed stacks need a first-class update action or update-capable command actions

[IARI]

I am experimenting with using Drydock to manage updates for Portainer-managed Compose stacks.

The use case:

• Portainer owns the stack definitions and redeploy flow.
• The compose files use Portainer stack env variables for versions, for example:
  • image: pihole/pihole:${PIHOLE_TAG:-2026.05.0}
  • image: gitlab/gitlab-runner:${GITLAB_RUNNER_TAG:-v19.0.0}
• A custom Drydock command action can call the Portainer API, update the relevant stack env variable, and ask Portainer to redeploy the stack.
• This keeps the stack managed by Portainer instead of directly editing files under Portainer's compose store or recreating containers outside Portainer.

Technically, this can already be prototyped with a command action. For example, I have a command action called command.portainer that:

• receives container_json
• infers the Portainer stack from com.docker.compose.project.working_dir
• fetches the matching Portainer stack via the Portainer API
• infers or reads a label for the version env var, e.g. dd.portainer.version-var=PIHOLE_TAG
• updates the stack env var to the detected newer tag
• triggers a Portainer stack redeploy

The problem is UX.

Right now, to update a Portainer-managed stack through this userland command action, the workflow is:

1. See in the containers list that a container has an available update.
2. Click the container.
3. Open the Actions tab.
4. Scroll to Associated Triggers.
5. Find command.portainer.
6. Click Run.

Compared to the built-in Docker Compose update action, this is too hidden and too cumbersome for day-to-day use.

I see two possible ways to solve this:

1. Implement Portainer as a first-class update action provider in Drydock.

   This would be the cleanest model. Drydock could understand that the action is a real update action, show the normal update button in the container list, and apply the update through Portainer's API.

   I would be willing to work on a PR for this if you think this belongs in Drydock.

2. Allow selected command actions to declare themselves as update actions.

   This could be a fallback if you prefer to keep Portainer-specific logic in userland. For example, a command action could opt into update-action semantics and then appear wherever normal update buttons appear, with the same eligibility/policy behavior as docker/dockercompose update actions.

Some open questions:

• Would you prefer a dedicated Portainer action provider, or a more generic “command update action” mechanism?
• Should command actions ever be allowed to participate in the normal update-action UI?
• If command actions become update-capable, how should they receive the canonical target version when Drydock shows an update insight/tag?
• Should notification triggers like mqtt.hass appear with a generic “Run” button next to action triggers in the same Associated Triggers list, or should notification and action triggers be visually separated?

For my setup, the ideal outcome would be: Portainer-managed stacks get the same one-click update flow as Docker Compose-managed stacks, but the actual redeploy is performed through Portainer so Portainer remains the owner of the stack.

[scttbnsn]

Makes sense as a request. Portainer-managed stacks don't respond well to the plain Docker recreate action since Portainer owns the stack definition, so a first-class integration (or update-capable command actions with the right context passed in) is the right shape. It's on the roadmap now. In the meantime the command action can drive Portainer's API with a webhook or a script if you want something working today.

[IARI]

wonderful! looking forward to it - let me know if i can support.

[IARI]

In case you are welcomming contributions like this, I created a PR for a first-class integration:
#941

Have a look, If you find the time.
I'll gladly adjust it to make it suitable for merging, unless you say youd rather do it on your own.

[scttbnsn]

Saw it, thanks. It's going in through your PR on dev/v1.8 so the attribution stays with you. Notes are on #941.

[scttbnsn]

Merged on dev/v1.8 (#941, 88999f6). Ships in 1.8.0. Restart recovery for in-flight Portainer updates is a follow-up; right now an update interrupted by a controller restart is expired rather than reconciled.

[IARI]

Amazing! Thank you for your work on this, and for picking this up so quickly.

Its marvelous that we can enjoy live in this age of AI, agentic workflows are a blessing.