On a Raspberry Pi, the OS question is mostly solved. On alternatives it's the main risk: an IoT device runs for years and needs security updates the whole time.
Three sources of images
| Source | Typical kernel | Pros | Cons |
|---|---|---|---|
| Vendor image (Orange Pi OS, Radxa, Banana Pi, Hardkernel images) | vendor (BSP) kernel | all board features (NPU, video, camera) often work first here | kernel can be old; update cadence depends on the vendor |
| Armbian | per board; vendor-derived or closer to mainline | consistent tooling across many boards, active community | support level differs per board (see below) |
| Mainline distribution (Debian, Fedora, etc. on well-supported SoCs) | upstream kernel | long-term security updates, standard tooling | newest SoCs may lack drivers for NPU, video or some I/O |
Armbian support levels (from Armbian's rules)
| Level | What it means |
|---|---|
| Standard support | Armbian publishes stable images through its mirrors and runs best-effort automated hardware tests; the board has an active maintainer |
| Community maintained | not under active supervision; images are untested, and the Armbian team won't respond to issues or apply fixes |
| Staging | work in progress; periodic/nightly CLI images, best-effort support |
| Platinum | business arrangements with vendors |
Before choosing a board, look it up on Armbian's download page and note its level. "An image exists" is not the same as "supported".
Checklist for long-lived IoT deployments
- Which kernel version does the image ship, and when was the image last updated?
- Does the image receive security updates through the package manager, or do you have to reflash?
- Do the features you need (NPU, hardware video, camera, PCIe/NVMe boot) work on that image, not just on the vendor's demo image?
- Can you reproduce the image (build scripts, config) if the vendor disappears?
- Plan updates: A/B root filesystems or at least tested backup and restore before running
apt upgradein the field.