Hi @Oscarthorn I see. Thanks for the extra context.
As far as I know, docker-compose does not support a method to mark containers that shouldn’t be started automatically.
Checking our internal feature tracking system, I see that couple of our users and team members already raised the same feature request. I added your interest on your behalf and also pinged my teammates who maintain the relevant modules here.
In my opinion, it’s a good ask. I could imagine several scenarios that such a feature would enable. Then I cannot comment when we could work and implement this feature. For sure we will notify you here as we make progress and ask for your feedback.
Having said these, the balena supervisor already offers methods to start and stop containers from another container at demand. Here are the docs that explain how to do it: Interacting with the balena Supervisor - Balena Documentation
Let’s say that you’d like
container-A to orchestrate the start/stop of
container-B. You could set the restart policy of
on-failure (Docker’s docs here). Then you’ll make sure that
container-B exits (without failure) when the balena engine starts it automatically. Then using the supervisor API calls I referenced
container-A will manage the starts and stops. You could use device tags to orchestrate the whole process. The value of the device tag would imply if a specific container is supposed to be stopped or started. Using the device tags has extra benefits like bringing visibility and control of the container lifetime via the balena dashboard and API (to control / observe container lifetimes from outside of
container-A as well).
Let us know if this would work in your case or not.