Unified balenaOS releases are now available

balenaOS, the lightweight, robust and reliable Linux based embedded operating system running in over 100 different boards and designed specifically to run containers, is now (since v2.85) available in a single unified image that can be configured at runtime for development or production mode.

We’re moving on from maintaining both development and production images to reduce operational overhead as well as giving us a better understanding of how our users would manage an image in production. Instead, users can now access development mode via runtime configuration changes. Read on to learn more.

Legacy development and production images

balenaOS used to come (before v2.85) in two flavored images, a development image that was recommended to use when developing applications, and a locked-down production image to be used on production devices.

Merging these images to avoid fragmenting distribution has been a long-term goal of the OS team. It simplifies a lot of the infrastructure and reduces the maintenance overheads and allows us to perform OS validation on exactly the same image that customers will be using in production.

The main differences between a production and a development image were:

• Development images had a serial console available
• Development images allowed passwordless root login on the different consoles
• Development images had the bootloader console accessible
• Development images exposed the engine socket so local development mode can be used

As such, development images were used to perform both application and BSP (Board Support Package) development.

Development and production modes in unified images

Since BalenaOS v2.85, unified images with runtime configurable development and production modes are available.

The current development mode and production mode differences are:

• Development mode has a serial console enabled
• Development mode allows passwordless root login on the different consoles – except if a custom SSH key is present in which case key based SSH authentication is enforced
• Development mode exposes the engine socket used in local development mode

NOTE: Neither development nor production mode images allow bootloader console access or display bootloader boot logs – you can build a custom development image for this as explained below.

Transitioning to unified images

The transition to unified images should be nearly transparent for balenaCloud users as the user interface remains the same. When a development image is requested, balenaCloud configures the image in development mode, likewise when a production image is requested it configures it in production mode.

Currently, development mode configuration is only possible by manually changing the config.json file in the boot partition of a device. In future, transitions between development and production mode are planned to be allowed via the dashboard and SDKs, but transitions between production and development mode are not. This is to avoid inadvertently running development mode in production situations.

The versioning of images have dropped the .dev./.prod suffixes in cases where they were used. As always, using the balena CLI balena os versions subcommand will list the correct versioning format for a specific release.

Using the most recent version of the Balena CLI is always recommended, but the transition to unified images makes this especially important as old CLI versions do not know how to configure development images. New CLI versions include a --dev argument to OS subcommands like balena os configure that allows configuring an image into development mode. A common pattern in Balena support has seen customers downloading a development image (a unified image configured in development mode by the cloud) and inadvertently using balena CLI, either an older version or without the --dev argument, which configures the image back into production mode.

Board support package development

Users performing BSP development will notice a difference though – both development and production mode do not allow entering the bootloader or show boot messages. For BSP development users need to build an image themselves and provide the -d argument to barys, our image builder script. With this argument, the bootloader console and boot logs are made available. It’s very likely that BSP development requires other changes to balenaOS, like the addition of debugging packages, so building an image has always been the recommended approach.

Thanks for your interest and continued use of BalenaOS, we hope the change to unified images is as frictionless as possible, but don’t hesitate to contact the team via balena forums or through other support channels. We will gladly answer any further questions.

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.