Intel-nuc missing from list of supported platforms in my fleet


I created a fleet: balenaHub: an easier way to find and publish fleets, apps, and blocks for edge devices

And I added intel-nuc in the list of supported platforms: lab-passbolt-balena/balena.yml at main 路 passbolt/lab-passbolt-balena 路 GitHub

But Intel Nuc is not listed in the list when I want to create and flash a new image :confused:

I currently run my stack on a raspberry pi 2 and tried to reduce the list to only raspberry and intel nuc but no luck, intel NUC is still missing :confused:

All docker images I use are multiarch ones and I am pretty sure they are amd64 compatible.

Do you have any hint ?

Thanks! :pray:

Hey @AnatomicJC,

I tried to figure out why this might be.
I only had this idea:
The devices supported can鈥檛 be of mixed architecture and the base architecture is what determines what other devices can be supported.
This idea started when I looked for an example of the intel Nuc being a supported device type. I found this fleet: balenaHub: an easier way to find and publish fleets, apps, and blocks for edge devices
The owner of the fleet put the architecture in the name and has 3 nearly identical fleets. The main difference is the architecture of the default device is different for each one and matches the supported devices. I can鈥檛 help but wonder if there is a good reason for that. I would recommend trying that to see if that works. I will ping for help to see if anyone else can shed some light on this undocumented issue.

I know that doesn鈥檛 solve anything but that鈥檚 my best idea.


Thank you @tacLog for having a look to my issue :hugs:

I had a look at the balena.yml from balena-displane/balena.yml at main 路 displane/balena-displane 路 GitHub and I guess you are right :confused:

The default architecure is intel-nuc and raspberry are supported, but I cannot see any raspberry on the balena hub page of this project.

Hey there, my colleague Thomas alluded to this but I wanted to give you a firm answer and confirm this is currently a platform limitation. Of course, you can build an application and associated balena.yml file that support multiple device types of all different architectures, but the fleet on the balenaCloud/Hub side can only currently support a single architecture. This is why you鈥檙e seeing a cut down list - the platform is taking the list of supported devices you provide in balena.yml and filtering it to show only those device types compatible with the same architecture as the default device type selected for that fleet. This is why you鈥檒l see other fleets published with the architecture in the fleet name - they鈥檙e publishing one fleet per arch and pushing the same code to each.

We do plan to address this in the future, but as I mentioned, it is a limitation today. Alternatively, you could list your submission as an app, and it will show all the supported device types and simply ask the user to choose the one they want to use when they create a new fleet and deploy the app. The fleet will still only allow devices of a single architecture at a time however.

I鈥檒l update the FAQ on hub to cover this, which I know doesn鈥檛 solve the root of the issue right now, but the work to support multi-arch is going to take us a little longer.

Thanks for getting in touch about it!

1 Like

Thank you @chrisys for the answer and clear explanations :ok_hand:

It is ok and I understand the limitations.


Jumping in to say that the UX bit me on this. I wanted to see what platforms Balena supported, so I clicked 鈥榓dd device鈥, but I did it on a fleet I already had that includes an rpi, so I erroneously concluded that Balena only supports tiny SBCs. I eventually figured it out after finding a forum post referencing a NUC.

Maybe it should show the full list, but grey out unusable ones (and add [wrong arch for this fleet] after them)?



Hey Gwynm,

That is a fantastic point and not something I had ever considered. I am writing this up for our team so we can hopefully make the change you selected. It would really help people understand the difference between a device not being supported in a certain fleet, vs when we don鈥檛 support it at all.