The road to multi-app, mile 2: surfacing Apps on balenaHub and balenaCloud

In the first part of this series, we renamed the old concept of balenaCloud “applications” to Fleets. Due to that work, today, we’re able to surface a new concept on balenaHub and balenaCloud to continue driving down the long and winding road to multi-app: Apps.

Previously, we removed the concept of applications by renaming it to Fleets. That change ultimately enabled what we’re talking about today: the new concept of Apps. Apps join and sit alongside our existing concepts of Fleets and Blocks in both balenaHub and balenaCloud and are entirely separate from what “applications” represented in the past.

You may be wondering why we need another concept to think about alongside Fleets and the more recently added Blocks, which is a fair question.

Our thinking is that we have Fleets to manage our devices, alongside Apps and Blocks, which are used to manage our software. Where Blocks are granular, replaceable, reusable pieces of generic functionality, Apps are the concept we’re using to bring Blocks together alongside other specific software and functionality into a single concept that can be deployed to a fleet as a whole.

An App is designed to solve a problem or answer a use case, and it’s useful as-is when deployed upon a device standalone and can be built out of many services or Blocks. It should be self-contained and do its job using only what it comes with; It doesn’t rely on anything else. An App has releases of its own and is deployed to a fleet of devices.

The concept of Apps has now been surfaced in the dashboard allowing you to add Apps, add releases to those Apps and publish them on balenaHub. If you mark your App public, other users will be able to deploy it via balenaHub.

Unless you’re publishing on balenaHub, the benefits of adding an App from the balenaCloud dashboard today are minimal. We’re setting up the structure for the future and will build out the functionality with time, ultimately reaching the stage where you’ll be able to deploy Apps to fleets, and then deploy multiple Apps to your fleets.

Apps marked ‘public’ in the dashboard will now be available as another resource for the community on balenaHub. Users can deploy Apps from balenaHub to their own fleets managed in their own balenaCloud accounts using the ‘Deploy’ button with each App.

When the deploy button is used, the balenaCloud builder will fetch the latest source from the linked GitHub repository and create a new build for the chosen fleet.

TL;DR: The concept of “projects” has been removed from balenaHub. Setting joinable: false within a balena.yml file will no longer have any effect. Existing fleets with joinable set to false have been transitioned directly to Apps if they had no devices present, and have been removed from public view in the case that they did have devices present.

When we launched open fleets on balenaHub, one of the first pieces of feedback we received from you was that you did not want everything you published to be a joinable fleet. Open fleets work great in the use case where all software and configuration is shared amongst all devices, but there are of course situations where this is not desirable and the use case demands something different.

To that end we introduced the concept of projects, which were essentially functioning as non-joinable fleets. This was achieved by setting the parameter joinable: false within balena.yml when pushing a release to your fleet.

This was a hack which allowed us to progress toward today’s goals. This confusing and hard to find setting will at last be obsolete, as ‘Projects’ have now been removed. Apps will now cater to that use case.

Of course, we didn’t want to simply remove all of the projects from the site, as you have obviously put time and effort into building, documenting, and making them available for others to use. A downside of the joinable: false “hack” is that although the display was changed on Hub to prevent users from adding their devices to your fleet, you were still able to add devices using the balenaCloud dashboard.

Unfortunately this means that we have some fleets in the database that contain devices even though joinable: false has been set, and we can’t convert these blindly to Apps as it would cause loss of access to those devices. Therefore, if there are no devices in your project fleet, we have converted it to an App and left it published on hub as it was previously. If there are devices in your fleet, we have removed it from display on balenaHub since it would be joinable again. You are free to publish it again as an App or toggle the fleet visibility back to on if you’re happy for users to join.

Today, we’re only just starting to scratch the surface of what’s possible with the Apps concept. We know that at the end of this road lies “multi-app”, and that’s what we’re driving towards.

We anticipate that the next stop in this journey will be developing the functionality surrounding single Apps. As we discussed above, right now the concept of Apps is very much for organization, publication, and sharing purposes.

We’re going to be looking into how we can develop the ‘Deploy with balena’ functionality further so that when an App is deployed to a fleet, a relationship is established and maintained. That way we can inform the fleet owner of updates and allow them to be installed (automatically or otherwise) without having to deploy again.

Once again our team would like to thank everyone for joining us on this journey and for following along. To our project owners: I thank you for your patience as we build out and progress through our roadmap and course-correct where necessary.

Like the first part of this series, we hope that although it may be a little uncomfortable at the start, this is an exciting update for you all and that it unlocks a whole new range of use cases. As always, I’ll be hanging out down in the comments; share with me all the feedback you have and let’s discuss.

You can find out what other features we have in progress, let us know about what you'd like to see us developing and upvote features on our public roadmap.