How to trim a Linux image's footprint

“Small” is only useful if you can measure it. Follow the same loop each time: measure, change one thing, measure again.

1. Measure

• Storage: size of the image and of the installed root filesystem.
• RAM: memory used after boot and under your real workload, not at idle.
• Boot time: on systemd, systemd-analyze shows where the time goes.

2. Choose smaller building blocks

• A lean libc such as musl and BusyBox utilities instead of the full GNU userland can cut a lot, at the cost of compatibility: binaries built for glibc may not run (Alpine works this way).
• A lighter init system than a full-featured one reduces both size and start-up time.
• A build system like Buildroot lets you include only what you select.

3. Remove what you do not use

• Documentation, man pages and unused locales.
• Debug symbols — strip binaries and libraries for production.
• Unused kernel modules and drivers, and unused services.
• Large language runtimes if a statically linked program would do the job.

4. Store it compactly

Compressing the root filesystem (for example as SquashFS) saves flash space. Stronger compression usually means slower reads and more CPU work at boot, so test on your hardware. Tiny Core takes the extreme route of running entirely from RAM (Tiny Core).

5. Stretch RAM

Compressed RAM swap (zram) can help on memory-tight boards without writing to flash. Keep logs in RAM and rotate them.

Watch the trade-offs

A smaller system is not automatically better: removing components can remove tools you need for debugging, and unusual builds can be harder to update and secure. Keep the ability to rebuild the image reproducibly.