Assign re-flashed device to existing UUID/name?

When reflashing a device, is it possible to configure it to use the same device UUID and configuration as it did previously?

I believe this may be possible by extracting the config.json file from the device manually before reflashing it, then loading that same file into the image to be flashed, but I’m not sure if that works?

In the case that it is not possible to pull the config.json file off of the device though, is there any way to get its contents through the Balena Dashboard, API or CLI? There is the balena config read CLI command to read the configuration from a disk, but that will not work for eMMC devices where the filesystem can’t be mounted on another machine.

Reusing the original config.json file created by Balena Dashboard or balena config generate (before the device populates it with UUID, etc.) does not appear to work - it registers the device as a new UUID. I’m actually surprised that it does that even since I was under the impression that the generated config files were one-time-use. If they are not, is there any downside to reusing the same file to provision multiple new devices, or conversely is there any reason to create new config files for each device?



Hi Adam,
You are right, copying a config.json between devices allow you to provision the “same” device on different hardware.

In case you are not able to pull the config.json, I do not believe there is a method to rebuild it if it cannot be accessed directly.

And this is correct, the config.json is re-written during initial cloud provisioning.

Actually, I am wondering why you’d need to reflash the device and keep the same UUID. Are you trying to update it or push new code?
Please let me know more about that and we may be able to find another workaround that could help you.


Hi Georgia,

In this particular case, we were reverting the base OS image in order to test something. We wanted to keep the same UUID so all of the device’s environment variables with settings, access keys, etc. would get restored without having to manually enter them all again as there’s no way to copy environment variables from one device to another. Even then it would still be easier to just reinstate them since you might have to copy a number of parameters individually.

The other, more minor benefit to keeping the same UUID is that whoever is working with that device doesn’t need to go find a different UUID to enter into CLI commands. Not really a big deal, just worth pointing out since some of the CLI commands accept both device name and UUID, and others only take UUID. For example, it would be really helpful to refer to a device by name when using balena ssh, balena tunnel, and balena logs. If all CLI commands took both and the developer could do everything with human-friendly device names instead of UUIDs, that would be ideal. Not sure how difficult of a change that would be for the CLI team.



Hi Adam, thanks for clarifying. In the case of testing downgrades I’d say it definitely makes sense to re-provision the device. As for the reliance on shell history for balena-cli commands, using the device names is not practical unfortunately as they are not necessarily unique. One option could be using DEVICE_UUID=... in your shell and then referencing $DEVICE_UUID in your balena-cli commands. Thanks.

Ah, that makes sense. I didn’t realize the names didn’t have to be unique.

Yeah, the env variable is basically what we’re doing now and it works reasonably well. We made a script that uses the Python API to query the UUID for a given device name (assuming it is unique, which we plan to maintain for our own devices), and then just use the UUID after that.

Just wanted to weigh in with a link to relevant balena cli command.
I used that in the past to link a different/new image to an existing device.

Hope this helps.

Much appreciated. The main reason we specifically want to reuse the same UUID is to assign the same environment/service variables to the device, which don’t get stored in the config.json file - on-device settings like wifi and things aren’t a big concern for us. Unfortunately, there’s no way to do that and no way to copy or clone an individual device configuration in the dashboard. I think the easiest way may be to use balena envs or the Python API to pull all of the settings and push them to the new device.

Thanks for the feedback. We created an item to discuss this internally as it would make sense to offer an easy way to clone the environment of a device (or even of a whole application). I attached the item to this ticket so we will be able to get back to you with some feedback as soon as the conversation is resolved.

Update for anyone who’s interested: we were able to make this work by using the --device argument to balena config generate ( to specify the original device UUID. Must have missed that argument before, but it worked as expected: the reflashed device associated with the desired UUID and configured itself as before.

1 Like