Built this after working with Intel’s Bluetooth firmware team - we kept seeing builds suddenly fail because memory crept up a few bytes at a time until it overflowed. Then everyone lost hours/days bisecting symbols and linker maps to figure out which commit pushed it over.

So I made a CI tool that tracks firmware memory footprint across commits and flags bloat before it breaks the build.

How it works:

CLI parses ELF + DWARF, extracts per-section/per-symbol/per-file size info

CI uploads reports; the platform stores history and generates diffs

Shows exactly what changed between commits (what grew, where, and by how much)

Optional memory budgets via commit keywords (acts as a CI gate to block regressions)

The report generator is open source: https://github.com/membrowse/membrowse-action

Works with GitHub Actions or any CI, tested on ARM, ESP32, ARC, x86 (multiple toolchains).

There’s also a live demo analyzing MicroPython firmware builds at membrowse.com.

Curious to hear from embedded folks: * How do you track code size / memory usage today?

* What would stop you from adding this type of check to CI?

* What’s missing that would make this genuinely useful for your workflow?