Reduce native binary sizes for EdgeX core and app services (amd64/arm64) for legacy/low-spec industrial PCs

[AshishAvesta]

🚀 Summary / Problem Statement

We’re deploying EdgeX services as native binaries (not containers) on older Industrial PCs with limited disk and memory. The current binary sizes are relatively large, making rollout and updates challenging on constrained systems (slow disks, small storage). Examples from my builds:

 - core-command: ~20 MB
 - core-data: ~25 MB
 - core-keeper: ~25 MB
 - core-metadata: ~20 MB
 - app-service-configurable: ~40 MB

With 6–7 services, the total on-disk footprint reaches ~150–200 MB just for binaries (excluding configs/logs). I build for both amd64 and arm64, and the situation is similar across architectures.

Why this matters

Many industrial environments still run on legacy IPCs (old CPUs, small SSDs/eMMC). Native (non-container) deployments are common in such environments due to OS constraints and operational policy.

Environment

• EdgeX version: 4.x (Odesa)
• Build targets: linux/amd64 and linux/arm64 (also occasional armv7)

Current vs. expected

• Current: per-service binaries ~20–40 MB; combined 150–200 MB.
• Desired: any feasible reduction (even 25–50%) would materially improve deployability on constrained IPCs.

[judehung]

You can try make build-noziti to build without the heavy OpenZiti libraries, which will reduce the binary size significantly.

[AshishAvesta]

Thanks for the tip on make build-noziti 🙏 — I tried it and the sizes did drop a bit, e.g. core-data is now around 17.8 MB and core-keeper ~18 MB. That’s better, but still quite big when running multiple services together on old IPCs.

Quick follow-up:

Is there any way to strip out unused modules/backends at build time? For example, we only use Postgres for core-data, but the binary still includes the Redis implementation too. Ideally, I’d like to exclude things we don’t need.

Would it make sense to support this via build tags (e.g. -tags postgres_only), or a “minimal profile” build target that only compiles the selected backends? Curious if the project is open to something like that — happy to test if there’s a direction you’d recommend.

[cloudxxx8]

There is no Redis in v4 anymore.
~18 MB is the best we can do currently. If you can find out any further improvement, please help open a PR to contribute it.

[cloudxxx8]

@AshishAvesta Sorry, you are right. We keep the Redis support in v4 for the backward compatibility.
We plan to remove this dependency in v5. You can customize it by removing the source code folder internal/pkg/infrastructure/redis to build your own binary.

[AshishAvesta]

Thanks for clarifying 🙏 @cloudxxx8 — that makes sense. It's good to know that Redis is mainly for backward compatibility and will be dropped in version 5.

I’ll try building a custom binary by removing internal/pkg/infrastructure/redis as you suggested and see how much difference that makes. If I can quantify the savings and it looks worthwhile, I’ll share the results back here.

Appreciate the guidance! 👍