We're in the same space as Balena and tackling some of the same problems, but with a different approach. Here are some of the big ways we defer from Balena (though these points really just scratch the surface).
Balena ties you into their ecosystem a bit too much. They require you to use BalenaOS which means they only support a fixed number of devices. In contrast, Deviceplane can be used with any Linux distro, meaning that as long as your device runs some form of Linux than it can be used with Deviceplane.
What's more, we've found that in most cases people really need the choice of what underlying Linux distro to use. For example, if you're using Jetson Nano devices and don't use the distro provided by Nvidia then you'll be fighting quite an uphill battle. Their distro includes a custom version of Docker (nvidia-docker) that adds support for using CUDA inside of containers.
Deviceplane also doesn't tie you to any specific container builder. We make it easy to integrate with popular CI systems so you can inherit all of their best features: build secrets, fully scriptable pipelines, etc...
Balena also lacks some of the core infrastructure that Deviceplane provides, such as our monitoring and bulk provisioning support.
Lastly, we're 100% open source and easy to host unlike Open Balena. Open Balena doesn't include user management or a UI. If you read through its installation guide you'll quickly get a sense that its architecture is needlessly complex and difficult to self-host. In contrast, Deviceplane was engineered to be self-hosted from day one and can be run in a single Docker command.
I looked at Balena for my project but being tied so tightly to their eco-system and not being able to use it with regular Raspbian really put me off. However, one feature that looked useful was the ability to have one service per container and have them tied all together with docker compose. Do you support that architecture or does Deviceplace manage a single docker container which must contain all the services bundled together?
I do agree that the openBalena install docs are not great. To me they sound like a bunch of separate hacks all stuck together.
We're in the same space as Balena and tackling some of the same problems, but with a different approach. Here are some of the big ways we defer from Balena (though these points really just scratch the surface).
Balena ties you into their ecosystem a bit too much. They require you to use BalenaOS which means they only support a fixed number of devices. In contrast, Deviceplane can be used with any Linux distro, meaning that as long as your device runs some form of Linux than it can be used with Deviceplane.
What's more, we've found that in most cases people really need the choice of what underlying Linux distro to use. For example, if you're using Jetson Nano devices and don't use the distro provided by Nvidia then you'll be fighting quite an uphill battle. Their distro includes a custom version of Docker (nvidia-docker) that adds support for using CUDA inside of containers.
Deviceplane also doesn't tie you to any specific container builder. We make it easy to integrate with popular CI systems so you can inherit all of their best features: build secrets, fully scriptable pipelines, etc...
Balena also lacks some of the core infrastructure that Deviceplane provides, such as our monitoring and bulk provisioning support.
Lastly, we're 100% open source and easy to host unlike Open Balena. Open Balena doesn't include user management or a UI. If you read through its installation guide you'll quickly get a sense that its architecture is needlessly complex and difficult to self-host. In contrast, Deviceplane was engineered to be self-hosted from day one and can be run in a single Docker command.