Introduction
Traditional OTA solutions such as A/B partition, delta update and full image replacement are still a best solution for certain use cases, it becomes complex and heavy as product lines grow, hardware diversifies, and software components grow. In our previous blog, we explored how Docker containers could power modular and maintainable over-the-air (OTA) update mechanisms for connected devices. While Docker excels in many cloud-native scenarios and resource rich edge use cases, it doesn't always align with embedded system constraints like limited storage, tight security requirements, or need for fine-grained application confinement. Unlike Docker, Snap integrates deeply with the base OS. It's a containerized software packaging system from Canonical (the makers of Ubuntu). Snap brings the promise of a scalable, modular OTA framework using container based updates that are secure, flexible, and adaptable across hardware platforms and application domains.
In this blog, we will see how Snap can be used to design a scalable and modular OTA system using container based updates, explore the architecture behind it, weigh its pros and cons, and examine how it enhances upgrade workflows, testing cycles, and system security. The Snap package OTA update architecture for embedded systems is particularly suited to automotive, industrial, and IoT edge platforms where atomic updates and air-gapped updates are critical requirements.
Architecture of a Snap-Based OTA System
Snap operates on a containerized model where each software component is packaged with its dependencies into a single unit called a Snap package. These packages are isolated from the base system and run in their own restricted environment, ensuring consistency across devices. This model enables true container based updates — each component is upgraded independently without impacting the rest of the system.
Snap based OTA Architecture
The OTA system built using Snap comprises the following key components:
- Snap Daemon (snap): This background service is responsible for installing, updating, and removing Snap packages. It handles version tracking, channel management (e.g., stable, beta), rollback, and security confinement.
- Snap Store or Private Storefront: The central repository from where Snap packages are delivered. This can be Canonical's Snap Store or a self-hosted solution for OEM-specific rollouts, enabling air-gapped updates in disconnected or offline environments.
- Snaps: Modular application or service components that are sandboxed and versioned. Examples: UI Snap, Middleware Snap, Sensor Driver Snap, Security Services Snap. Application containerization for embedded systems via Snap enables each component to be upgraded independently.
- Channels: Represent different release streams, such as stable, candidate, beta, and edge. They allow staged rollouts and testing before global deployment.
- Device Agent (snapd API client): Runs on the target device to check for updates, download, verify, and install Snap packages via REST APIs exposed by snap.
- Cloud Dashboard: An optional management UI where developers can publish new versions, monitor update statuses, and manage devices and channels.
This modular structure decouples various system components, making container based updates more targeted and rollback mechanisms more robust.
Scalability & Modularity
A key advantage of Snap is that it allows you to think in terms of services or features instead of a monolithic image. This modularity, driven by container based updates, helps in managing large-scale deployments more effectively. For example, an automotive head unit may comprise display logic, telematics stack, and connectivity services — each encapsulated in its own Snap. When the telematics feature is updated, only that Snap is upgraded, reducing the risk and bandwidth cost of full system OTA.
Snap also excels at horizontal scalability across hardware variants. By using interfaces and plug mechanisms, Snap packages can adapt to different boards and SoCs, reducing the need to maintain hardware-specific OTA paths. This Snap package OTA update architecture for embedded devices allows a single infrastructure to serve multiple product lines, geographies, and hardware revisions. Atomic updates ensure that each upgrade either completes fully or rolls back cleanly, preventing partial update states that could brick a device.
Pros and Cons of Using Snap for OTA
| Aspect | Pros | Cons |
|---|---|---|
| Modularity | Each component is independently packaged and upgradable as a Snap — enabling true container based updates | May require careful interface definition between loosely coupled Snaps |
| Security | Built-in AppArmor confinement, signed packages, sandboxed runtime | Requires AppArmor profiles and Snap-specific security policy understanding |
| Dependency Handling | Bundled dependencies ensure consistent behavior across devices | Larger package sizes compared to system package managers provided by native OS |
| Cross-Platform Support | Works across multiple Linux distributions and CPU architectures | Limited support for non-Linux platforms (no Windows/macOS client support) |
| OTA Management | Channel-based release management (stable/beta/edge), delta updates, atomic updates | Full Snap Store reliance unless using self-hosted infrastructure |
| Rollback & Recovery | Automatic rollback on update failure; atomic updates ensure clean state transitions | Revert state tied to Snapd; not as customizable as Docker volumes |
| Developer Experience | Unified tooling (snapcraft, snapd) simplifies lifecycle management | New learning curve if team is used to Docker or Yocto workflows |
| System Integration | Deep OS integration with startup control, service management, etc. | Can be tightly coupled with Ubuntu-based systems unless tuned |
Despite the cons, the operational simplicity and long-term scalability of container based updates make Snap an appealing choice for many connected device ecosystems.
Upgrade Advantages
One of the most significant improvements Snap brings to OTA is the granularity of upgrades. With traditional OTA systems, even a minor update might require re-flashing or delivering the entire image. Snap, however, updates only the affected components via container based updates, preserving bandwidth and reducing device downtime.
Additionally, Snap supports delta updates, which means only the binary diff between versions is sent to the device. This can dramatically reduce update sizes — an essential consideration for bandwidth-constrained devices in remote locations. This is particularly important when implementing air-gapped updates where only minimal data can be transferred through offline media or USB.
Furthermore, Snap supports scheduled updates, allowing OEMs to define maintenance windows or coordinate updates with user behavior patterns. Combined with channel-based rollouts, OEMs can create staged deployment pipelines, reducing risk by catching bugs in pre-production or early adopter groups. The Snap package OTA update architecture for embedded platforms integrates naturally with CI/CD pipelines, making continuous delivery of air-gapped updates and online atomic updates straightforward.
Security Point of View
From a security standpoint, Snap brings multiple layers of protection that directly support application containerization for embedded systems:
- Sandboxing: Each Snap runs in an AppArmor-confined sandbox, preventing unauthorized access to system resources.
- Read-Only File System: The Snap itself is immutable and mounted as read-only, preventing runtime tampering.
- Signed Updates: Every Snap package is digitally signed, and snapd verifies signatures before installation — essential for secure air-gapped updates.
- Automatic Rollbacks: In case of a failed or compromised update, Snap ensures atomic updates that roll back to a previously working version cleanly.
- Minimal Attack Surface: The modular nature reduces the impact radius. A vulnerability in one Snap does not compromise the whole system.
- Secure Channels: Updates are delivered over HTTPS with integrity checks.
In security-critical sectors like automotive, medical, and industrial IoT, these mechanisms contribute to achieving compliance with standards like ISO 21434 and IEC 62443. For instance, Snap's trust chain and update authentication processes directly support requirements related to update security, software integrity, and tamper resistance.
Our cross-domain embedded expertise and IoT Security and Data Protection Services enable scalable, secure OTA architectures with reliable update management.
Conclusion
Designing a reliable OTA (Over-The-Air) update system is a complex effort. It demands the right balance of flexibility, security, scalability, and long-term maintainability. Snap offers a powerful solution through its modular, container based updates architecture, enabling robust atomic updates and rollback mechanisms, fine-grained security confinement, and smooth integration with CI/CD workflows. The Snap package OTA update architecture for embedded systems significantly reduces maintenance efforts while enhancing system reliability and adaptability. While Snap comes with its own set of considerations, such as larger package sizes and ecosystem alignment, the long-term benefits in agility, testability, and security — including support for air-gapped updates in offline deployments — often outweigh these trade-offs. As embedded devices become more connected and software-centric, leveraging modern OTA frameworks like Snap becomes essential to maintain competitiveness and deliver consistent user experiences.
At Embien Technologies, we have leveraged Snap to architect scalable, modular OTA solutions using container based updates for customers in domains like automotive, industrial automation, and smart healthcare. Our hands-on experience in deploying Snap-based systems on constrained hardware platforms has demonstrated its effectiveness in ensuring secure, fail-safe atomic updates and air-gapped updates across diverse environments.