This is exactly what we use it for, it comes as a simple to setup device that almost anyone could set up in <5 min with no technical knowledge needed.

It's all about getting them deployed effortlessly for us, and treating them as first class citizens in terms of management. Most of the devices like this you can pivot to another hardware platform if you wanted or needed.

It gets much more complicated when you start doing video (especially if you try to containerize your application, but it is possible to do while remaining performant.)

I think about 60% of our use cases boil down to "put chromium on the screen" though.

What OS are they running that you can reliably remotely manage them and not end up with a bunch of failures? I've had too many Pis corrupt themselves with dist-upgrade churn.

If you're shipping commercial products based on Pis and running dist-upgrade you're likely doing it wrong. Using something like [Balena](https://www.balena.io) you can ship full update images so that devices are always in a known good state, rather than potentially having some proportion of the OS in a half-upgraded state. The key thing is to support atomic updates - the device is either updated, or it isn't.

There's then a bunch of other stuff you want to do like turning down log levels, and only logging super important stuff to the SD card, which will drastically improve the lifetime of your storage.

Agreed. My use case is personal, but wanting to setup things and have them continue to just keep working, rather than having to tinker when they break. Last Raspbian failure was the files missing from /boot (old ones removed, new ones not put in place). Couldn't figure out the root cause.

I'm thinking of going to NixOS. The filesystem will still be mutating, but in a much more atomic way. And if a host does die, I can easily rebuild an image from another host and pave over its whole sd card.

The most robust way would be the embedded approach of two static flash partitions (update each one alternately), a separate partition for config, and another for mutable state. Alas that's more development work than I want to do for personal projects.

> The most robust way would be the embedded approach of two static flash partitions (update each one alternately), a separate partition for config, and another for mutable state. Alas that's more development work than I want to do for personal projects.

Just to let you know, this is the approach that balenaOS takes. Applications are containerized and deployed using Docker. The OS uses read-only system partitions to store the engine, kernel, firmware, etc, and has an A/B partition layout for resiliency and atomic updates. Applications are downloaded and stored on a separate data partition, and mutable configs are stored on another. The partition layout and a lot of how the OS functions is also well documented and public. [0]

Additionally, the first ten devices are free and fully featured, and the same people that help create the product, including (but not limited to) engineers, monitor the forums to help users. I'm one of those engineers. :)

[0]: https://www.balena.io/docs/learn/more/masterclasses/host-os-...

There are a subset of use cases for the pi we work on that always seem to have posts on the Balena forums discussing, and the support that you all provide there is absolutely amazing. I don't know that I've encountered any official support that even comes close to what I see posted there. Thank you all for being awesome!

Thanks for the kind words! I've shared your feedback with the team.

> the first ten devices are free and fully featured

Neat project, but this implies some sort of ongoing third party dependency/control that the devices would have, making it a non-starter for my use. The main reason I am using RPis as security cameras (for one use) is to avoid these type of security vulnerabilities.

We've thought of that too. :)

There's OpenBalena for hosting your own device deployment and management server. https://www.balena.io/open/

It's self-hosted, which is a double-edged sword. You have to setup and maintain your own infrastructure, but you don't depend on a third party. For personal projects, it's probably the way to go.

Additionally, devices can be moved between servers easily. If you decide to use the cloud hosted platform in the future, or move devices from cloud hosted to self-hosted, it's easy to do.

That's awesome, and exactly the kind of thing I want to see from companies selling services! I'll be sure to check it out when I have a minute.

Nothing special, just Ubuntu. We have a few devices that run into issues every few weeks or months. Typically devices that live in horrible environments that are staying undervolted and losing power during upgrades.