Selectively disable services on a per-device basis?

I’d like to be able to disable services (containers) selectively on a per-device basis using environment variables. Is there a built in way of doing this?

Failing that, is there a Supervisor API method for disabling services, ideally one that survives reboots?

Reason: my application contains several independent functions, and I’d like to be able to disable them on a per-device basis.



Thanks for your question.

There isn’t currently a way to do this, via envvars or not, for a balenaCloud application, as the Supervisor API only supports the starting/stopping/restarting of entire applications rather then the container, instead of disabling specific services. We don’t expose the balenaEngine socket to any containers, so unfortunately you also can’t do it manually.

There is a way to do this if you’re using local mode (ie. for development), which is to use the state endpoints of the Supervisor to post a new state (and you’d remove the relevant service containers from your newly POSTed state to stop them from being run). The local mode endpoints are documented here although as it notes, they’re not intended for general use.

That said, we do have have several customers that do something similar, but they carry out inter-service communication at initialisation to determine which services should continue to run or which should just stop. This doesn’t stop the service containers from being started, but does mean they don’t execute their function.

I’m going to raise an internal issue to moot the prospect of service disabling, but this does carry with it several architectural questions (for example, what to do in the event of a new release of an application).

Best regards, Heds

Hi again,

I’m actually incorrect and we do have an endpoint for stopping an independent service:

as well as starting a service again:

Given this, you could have a manager service which itself then determines when a service should be started based on envvars to that service.

Apologies for the incorrect advice, I’d completely missed those endpoints!

Best regards, Heds

Thanks so much for the fast responses. I’ll use the supervisor API route – I already have a service that can act as an orchestrator for the other services, and I can drive its behaviour using ENV vars.

This is a fantastic platform and toolset. The more I use it, the more impressed I am.


Thanks Peter, we constantly try to reduce the friction to do edge computing, so you can focus on more important things. Hope it works well for you, feel free to get back to us if you need any additional help.