Application default device type


We created an application with default device type of RPi3.
We can manually add to it devices of type both RPi3 & 4.
However, when we do the same operation via the cli, by calling

balena config generate

with the parameter

–device-type raspberrypi4-64

we get the error:

BalenaInvalidDeviceType: Invalid device type: Device type raspberrypi4-64 is incompatible with application RavenDB

The device itself is able to boot, and is displayed as RPi3 in the cloud, although it is actually RPi4.

  1. What is the significance of default device type for an application?
  2. Why an application cannot contain different devices? In other words - we would prefer it to be device agnostic and be capable of containing devices of different types.
  3. Why does the cli behave differently then the manual provisioning via the cloud dashboard?


Hi Vitaliy,

A device type in balena describes devices that have the same boot configuration and are capable of booting the same Operating system. When a new device type is created, it is usually because the system-on-a-chip (SoC) or configuration is distinctly different from others that exist.

As an example, the Raspberry Pi 1 model B+ and Raspberry Pi Zero W are part of the same device type since they are both armv6l architecture SoCs and the boot loader is capable of booting both boards. However, the Raspberry Pi 3 model B+ is by default a armv7l CPU and we therefore separate it into a new device type.

In balenaCloud the device type is also used to define what architecture the built containers for each app will be. So in the above example RPi ZERO deployments are built for the armv6l architecture where as RPi 3 applications will target the armv7l architecture and the Intel NUC device type will target x86_64 architecture.

Since your original app was created with RPi 3, have you tried defining the --device-type as raspberrypi3-64 or raspberrypi3?


Thank you John for the response,

I still don’t understand the following points:

  1. Why a balena application cannot host devices with different device types?
    We don’t want to define an app per device…
  2. Why does the cli behave differently then the manual provisioning via the cloud dashboard?
  3. What does the default device type of an application effect?


Hi @Vitaliy,

Balena application can host various device types, as long as all of them are of the same or a compatible device type as the selected default device type of the application.
That is, you can have an Raspberry Pi 3 application having both Raspberry Pi 3s and Raspberry Pi 4s, but not Raspberry Pi Zeros.
That’s because the images are built only for the CPU architecture of the application’s default device type, and devices can only run executables of architectures that they have compatibility with.
The default device type of an application is what controls the architecture for which the images will be build for.
Let me point you to the respective FAQ entry in our documentation page:

Regarding the issue that you are facing it seems that this is a limitation of the balena-cli which we should definitely fix.
I’ve opened a GitHub issue for this, which you can use to track progress:

We will give you a note once this gets implemented and released.

Kind regards,

1 Like

Hello @Vitaliy

Just to let you know that we’ve implemented the fix that allows the use of mixed architectures on the CLI’s config generate command.


1 Like

Awesome, Thanks allot @thgreasi & @ntzovanis for the exceptionally quick fix!

Please note that the error in cli is resolved,
however I still see in the cloud’s dashboard a wrong device type - although I specified raspberrypi4-64 in the command, RPi 3 is displayed as the type of the device.
The command:

balena config generate --device-type raspberrypi4-64

still generates a config file, with

“deviceType”: “raspberrypi3”

I believe that might be the reason.

Many Thanks,

Can you please confirm the exact balena config generate command that you used, since the one you mentioned does error complaining of missing arguments?
Please also confirm:

  • the exact commands that you used to inject the generated config to the balenaOS images.
  • how the image that this was injected was downloaded and that it is indeed for a Rasperry Pi 4. Was this downloaded from the balenaCloud dashboard? If so confirming that raspberrypi4-64 is part of the filename should make things cleaner.

Kind regards,

I can confirm that running :

balena config generate --app myRPi3App --version 2.51.1 --device-type raspberrypi4-64

on my side with balena-cli v12.5.0 does generate a config with thedeviceType: raspberrypi4-64 field as expected.

Sure @thgreasi !

Here’s our sequence of commands:

balena os download raspberrypi4-64 -o device.img --version v2.51.1+rev1

balena preload device.img --app APP --commit current

balena device register APP
This command returns a UUID which we store into $UUID

balena config generate --device $UUID --version v2.51.1+rev1 --network ethernet --appUpdatePollInterval 10 --app APP --device-type raspberrypi4-64 --o config.json

config inject config.json --type raspberrypi4-64 -d /dev/sda

Please see resulting config.json file, with some sensitive field values changed to 9999999999 & XXXXXXX:

“applicationId”: 99999999,
“deviceType”: “raspberrypi3”,
“userId”: 99999999,
“appUpdatePollInterval”: 600000,
“listenPort”: 48484,
“vpnPort”: 443,
“apiEndpoint”: “”,
“vpnEndpoint”: “”,
“registryEndpoint”: “”,
“deltaEndpoint”: “”,
“mixpanelToken”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”,
“files”: {
“network/settings”: “[global]\nOfflineMode=false\nTimeUpdates=manual\n\n[WiFi]\nEnable=true\nTethering=false\n\n[Wired]\nEnable=true\nTethering=false\n\n[Bluetooth]\nEnable=true\nTethering=false”,
“network/network.config”: “[service_home_ethernet]\nType = ethernet\nNameservers =,”
“connectivity”: “connman”,
“registered_at”: 9999999999999,
“deviceId”: 9999999999,

That makes things clear.
The issue is that the device is pre-registered with balena device register and you can see that after that point the device shows up in the dashboard with a device type matching the default device type of the application.
As a result, when you later use balena config generate you change the device type of the already registered device.
Perhaps it might be better to have the CLI error when ---device and --device-type are used together, so that it’s clear which option is respected.
It also seem that in order to be able to cover your use case, we should also add a --device-type parameter to the belana device register command.

We will let you know once these get implemented and released.

Kind regards,

Great, thanks allot @thgreasi!