Refurbishing workflow (deleted devices)

Hello, I am trying to work out refurbishing workflows for our devices, particularly around reusing storage from a device (balena fin in our current design) that has been deleted on balena cloud.

We want to delete decommissioned devices in order to reduce clutter and not pay the monthly fee for a non-functional device. Our workflow will likely involve re-flashing the device, which should create a new device on balena. However, we need a way to enforce that this happens, as it seems like it would be an easy step to skip by accident.

Is it possible to detect from a device if it has been deleted from balena cloud? If we can detect this on the device, we can display a message to the technician that the device needs to be re-flashed.


If your device has been deleted from the Cloud, and has access to the VPN to know that it has been deleted from the Cloud, then there shouldn’t be any containers running on the device anymore other than the Supervisor container. This would be an indicator that your device has been removed from the fleet.

This is not the behavior I am seeing on my test device. Our application appears to be running as usual.

If you still have containers running on the device after leaving the fleet, you could look inside the container for the variables associated with the fleet connectivity, such as BALENA_APP_NAME. It will all depend a bit on your setup though, whether they run with the Supervisor label will impact what variables are available to you. It will also vary depending on and how you envision interacting with the device after it has left a fleet. Another option could be via the Supervisor API where you could use a container or endpoint to report on the status to your main app: Interacting with the balena Supervisor - Balena Documentation. Once your device has left a fleet you will no longer be able to access it via the Cloud terminal. Do they permit local SSH access?

Unfortunately I did not have local ssh set up on my test device, so I can not log in to inspect the state. I will get the device reimaged and attempt this again with local ssh enabled.

BALENA_ variables and the status endpoints of the supervisor api all appear to report the same values after deleting the device from balena cloud.

Hi @aferm,

I can confirm that deleting the device on the cloud does not stop the running app on the device. One way to detect if the device has been deleted is to try to access the API using the BALENA_API_KEY set on the container when using the io.balena.features.balena-api label.

If the device has been deleted from the cloud side, then the device API key will no longer have authorization to the resource, so the following query should return a 4xx

curl "\$filter=uuid%20eq%20'$BALENA_DEVICE_UUID'" -H "Content-type: application/json" -H "Authorization: Bearer $BALENA_API_KEY"

I would advise you to try this first on a single device as I’m not exactly sure of what the API response be in the case the device is deleted.

1 Like

Here is some extra information on API resources Resources - Balena Documentation

Our services are not currently configured with access to the BALENA_API_KEY variable. Our devices are also cell connected, so I have concerns about polling an http endpoint for this purpose.

I do see error logs from the supervisor when it attempts to communicate with the balena api, and find it interesting that this state is not detected and exposed on the local api:

[error]   Error from the API: 304
[error]   Device state report failure! Status code: 401 - message: 

Would you consider adding an endpoint to expose cloud communication errors or connectivity status locally?

If we can’t detect this state through the local api, it will likely be best for our cloud services to detect this situation via integration with the balena cloud api and inform the device if/when it happens.