Reduce Embedded Linux Firmware Size to ~1MB Core
The Problem
Embedded Linux footprint matters: cellular IoT devices ship with tens of MB of flash, industrial gateways are quoted in hundreds of MB, and every megabyte is bandwidth, cost, and update window. Most container runtimes built for cloud (Docker + containerd, even k3s) sit at tens-to-hundreds of MB just for the engine — before any application code.
Pantavisor’s Footprint
Pantavisor itself is a single ~1 MB binary that runs as PID 1. There is:
- No container daemon — no
dockerd, nocontainerd. Each LXC container is a normal supervised process tree. - No image cache — content-addressed objects are stored once in
objects/, referenced by hash from any state revision. - No mandatory overlay layer cache — Docker requires overlayfs and bookkeeping; Pantavisor doesn’t.
Realistic minimal Pantavisor system breakdown:
| Component | Approx. size |
|---|---|
| Pantavisor (PID 1) | ~1 MB |
| LXC + supporting binaries | ~3–5 MB |
| Kernel + initramfs (varies by board) | 5–15 MB |
| Minimal BSP container (Alpine + ConnMan style) | 8–20 MB |
| Per-app container (typical) | 5–30 MB |
A complete RPi gateway image with BSP + connectivity + a single app commonly fits in ~50–80 MB of flash.
Why It Stays Small
1. No Long-Running Daemon
dockerd is a privileged root daemon that idles at significant RAM and disk. Pantavisor is PID 1; no separate process owns container lifecycle.
2. Content-Addressed Object Store
Every file (kernel image, container rootfs, config blob) is stored by its SHA256 hash. Two containers sharing the same library share the same object. Two state revisions sharing 99% of their content share 99% of objects.
3. Flexible Storage Backends
Containers can use:
- squashfs — read-only, compressed, ideal for production rootfs
- dm-verity — cryptographically verified read-only filesystems
- raw block volumes — direct partitions for data
- overlayfs — only when you actually want it
The runtime doesn’t force overlayfs (and its cache growth) on you.
4. Differential OTA
Updates ship only changed object hashes. A 200 KB config tweak doesn’t push a 200 MB rootfs over cellular.
5. Kernel and BSP as Containers
The kernel + modules + firmware live inside a bsp/ container, sharing the same content-addressed object store as everything else. No separate “system partition” duplicating storage.
Practical Footprint Reduction Tips
- Use squashfs root volumes — set
IMAGE_FSTYPES = "pvrexportit"with squashfs in your container recipes. 50–70% size reduction vs. plain rootfs. - Strip the BSP — disable kernel features you don’t use.
meta-pantavisor’sPANTAVISOR_FEATUREStoggles configure what’s compiled in. - Share base layers across containers — use the
--baseflag withpvr app addto create overlay containers that diff against a shared base. The diff layer isroot.ovl.squashfs— typically a fraction of the base. - Trim factory packages — distinguish
PVROOT_CONTAINERS_CORE(always present) fromPVROOT_CONTAINERS(optional, installable on first boot). Optional containers don’t bloat the initial flash. - Compress on transfer —
pvflasheraccepts.bz2,.xz,.zst, and.gzdirectly; ship images compressed and only decompress on the device.
Trade-offs to Be Aware Of
- System containers are larger than Docker app containers by design — they include init and supporting userspace. The overall system is smaller, but a single Pantavisor container will usually be larger than a single Docker app container.
- Kernel-as-container adds the BSP container’s overhead. This buys you OTA-able kernels — pay it knowingly.
Compared to Alternatives
| Stack | Engine footprint | Notes |
|---|---|---|
| Docker on embedded Linux | ~50–100 MB just for dockerd + containerd |
Plus image cache growth |
| balenaEngine + balenaOS | ~80–200 MB host OS | Slimmed Docker but still daemon-based |
| Pantavisor + LXC | ~1 MB Pantavisor + small LXC | No daemon, content-addressed dedup |
| Buildroot alone | Smallest in class (single-digit MB) | But no container runtime, OTA, or fleet |
If raw minimalism is the only goal, Buildroot still wins. If you want minimal plus containers + OTA + rollback + fleet, Pantavisor is the smallest stack that delivers that combination.
Next Steps
- Build an Embedded Linux Image from Containers — Configure a slim image
- Reproducible Embedded Linux Builds — Why content-addressed dedup also gives reproducibility
- Pantavisor vs Buildroot — Where each wins