[Feature Request] Blank stack button that will assign it to running stacks.

[AiAe]

I haven't researched if this is even possible, but I would love to have such feature, where I can fill a page with blank stack buttons, and they will auto fill with each project thats currently running?
Since some times I need to run multiple stacks at once, while also having other useful buttons, I'm running out of space on the page, so it would be cool if there is something that would dynamically show the currently running stacks.
When there is stack running and we press it, it should just turn it off and then be blank again until it finds another running stack and assign it to it?

I'm not sure if that makes sense, if not i will try to explain it more in-depth.
If i have some free time I might look into this feature if its doable and open PR, if you think its also something cool to have.

[Darkdragon14]

Hello 👋

Thanks for the suggestion.

Just to be sure I understand correctly: the idea is to have a generic “blank stack button” that automatically assigns itself to an existing Docker Compose project/stack from the current Docker context, instead of manually configuring the button for a specific stack.

So for example:

• I add a few blank stack buttons on my Stream Deck page
• the plugin detects existing Docker Compose projects/stacks
• each blank button automatically displays one available project/stack
• pressing the button would start/stop the assigned stack, like the current stack action
• the button would only become blank again if the assigned stack/project no longer exists

Is that correct?

If yes, I think it’s an interesting idea. It would be different from the current stack action, because the current one is configured manually for a specific stack, while this one would be more like an auto-discovery / dynamic slot.

I need to think about the cleanest way to implement it, especially to keep the assignment stable between buttons and avoid unexpected changes, but I understand the use case.

[AiAe]

You wrote just as I was posting this ;D

Managed to make it with codex surprisingly turned out exactly what I wanted to do.
I'm not sure whats your policies regarding AI so I wont open PR just yet, will review code and clean it up if needed, if you like the idea of having such feature.

CleanShot.2026-06-03.at.3.29.57.mp4

[AiAe]

Also with this I think we can add dial for stack starting, so this can complete the idea even further, where we can start via dial and then be able to see whats running and stop it if we want, like what I showed on the video above.

[Darkdragon14]

I don’t have any problem with AI-generated code, as long as it is used properly.

For me, the important part is that the code is reviewed, cleaned up if needed, understandable, and maintainable. So if you are happy with the result, feel free to open a PR. I would be glad to review it.

Also, this feature is interesting to me, so I would be happy to have your contribution. And again, thank you very much for your work on this 👍

About the dial idea: yes, I think it could make sense to have a dial that automatically lists the available stacks, so we can start one from there, and then use the dynamic buttons to see/manage the stacks.

One small point: in your video, I’m not fully sure I understood how the button becomes empty again. But apart from that, I think we are almost on the same vision.

[AiAe]

Thanks, I've pushed what AI wrote so far, haven't yet reviewed it you want, can check it here if you want AiAeForks@681fd3e
It did move some of the logic to its own utils file so it can be reused in the project.

About the last paragraph, I made it so once stack is off, it will make the button empty again.
I think this makes most sense, in cases you don't want to have it filled with one-time stacks and so on.
Which is why I suggested the new dial-up to help with this and allow us to browse and start stacks, which then they will get listed above again.

[Darkdragon14]

I added one comment, but otherwise it looks clean to me.

I still need to test it properly on my side, but the implementation looks good overall.

One thing I noticed while reviewing: the current behavior seems to only bind to running stacks, so after stopping a stack the button becomes empty again. That may be okay for this action, but I just want to confirm that this is the intended behavior.

Also, I’m not sure about the streamDeck.connect() call inside onSendToPlugin. Is it needed here? I usually expect this to be handled globally by the plugin.

[AiAe]

I will check and see if streamDeck.connect() is needed there and if not remove it.

Regarding the question above, as I said earlier in the comments I do want it to bind to only running stacks ideally.
Otherwise what other option would there be to clean them up?

If you do think saving them is better idea, so they can be started again later on I can maybe see if we can maybe clear the buttons to empty after some duration, like half a day?

[Darkdragon14]

Yes, that makes sense.

For this action, I think binding only to running stacks is probably the cleanest behavior. It keeps the feature simple and avoids having buttons stuck on old stopped stacks.

If we want to start stopped stacks again later, I think that could be handled by the dial feature instead, where the dial lists available stacks/projects and lets the user start one.

So for this feature, I’m fine with keeping the dynamic buttons focused on running stacks only:

if a stack is running, it can be assigned to a button
if it is stopped, the button becomes empty again
starting stacks can be handled separately later

No need to add a duration/timeout cleanup for now, I think it would add extra complexity without being necessary at this stage.

[AiAe]

Yes, that makes sense.

For this action, I think binding only to running stacks is probably the cleanest behavior. It keeps the feature simple and avoids having buttons stuck on old stopped stacks.

If we want to start stopped stacks again later, I think that could be handled by the dial feature instead, where the dial lists available stacks/projects and lets the user start one.

So for this feature, I’m fine with keeping the dynamic buttons focused on running stacks only:

if a stack is running, it can be assigned to a button if it is stopped, the button becomes empty again starting stacks can be handled separately later

No need to add a duration/timeout cleanup for now, I think it would add extra complexity without being necessary at this stage.

Sounds good.

About streamDeck.connect(), from what I can see you also use it everywhere in the actions: https://github.com/search?q=repo%3ADarkdragon14%2Fstreamdeck-docker%20streamDeck.connect()%3B&type=code should I also remove it from there? I tested it and everything seems fine so far, with it being removed from all actions

[Darkdragon14]

Good catch.

If everything works without streamDeck.connect() in the actions, then yes, it is probably unnecessary there as well.

I’m fine either way: if you prefer to keep this PR focused only on the new feature, that’s totally okay. But if you want to include the cleanup for the existing actions too, you’re welcome to do it in this PR as well. Otherwise, I can do it later.

So feel free to choose what is easier for you.

[AiAe]

Opened the PR, also pushed the clean up in there.
Will work on the dial up next and will PR that in a bit.

[Darkdragon14]

For me, this PR looks good now 👍

I’ll keep it open for now only because I don’t want to forget to prepare the release tonight.

About the dial feature, no worries, I didn’t expect it to be ready immediately 😄

Do you prefer that I wait for the dial PR before making a release, so both features can be released together?

If yes, I can merge this PR now and wait for your second PR before preparing the release.
Otherwise, I can release this one first and the dial feature can come in a later release.

[AiAe]

You can merge now, I should be ready in an hour or two.
I think it makes sense to ship them together.

[AiAe]

Took some tweaking to get the design to be good, but I think I got it.
#20