Tested the hypothesis that cached base64 images were bloating TanStack Query and Redis. They are not, measured on a loaded 4-tab session: base64 data-URLs, server heap 0.01 MiB (2 strings) base64 blobs, browser heap 0.01 MiB (7 strings) Redis total 2.17 MB image bytes in Redis none - image-proxy stores URL + headers only What the server heap is actually made of (141 MiB used): 41.4 MiB is bundled JavaScript source retained as strings, ~29% of the heap. The memory is the code, not cached data — which is why every cache-tuning idea in the fix catalog measured at zero, and why serverExternalPackages was the only lever that moved idle memory. 7.86 MiB of that is literal duplicate copies: the same module inlined into several Turbopack chunks and retained once per chunk. @ioredis/commands' command table was in 10 chunks and resident 6 times (2.07 MiB wasted), so it is now external — ioredis is already external and owns it as a direct dependency, so it stays traced. Recorded as bundle hygiene, NOT a memory win: idle 89.7 -> 89.4 MiB is inside noise, and board-loaded/peak deltas were smaller than the run-to-run spread (one "before" run read 220.6 MiB against 169-173 for identical code). got and @octokit/request-error duplicate just as badly but were deliberately left bundled: they are only transitive dependencies, and a check inside the image showed got is not traced into node_modules, so externalising it would have turned a bundled module into a require that resolves to nothing — a possible MODULE_NOT_FOUND for zero measured gain. analyze-heap-strings.mjs buckets a snapshot's strings by what they are, which is what made "37 MiB of strings" actionable instead of just alarming. Verified: 28/28 widgets render, auth control passes, zero module-not-found in the container log, typecheck clean. pnpm test 1794/1795 with two different Testcontainers flakes across runs (pi-hole, sabnzbd); both pass 18/18 in isolation.
Live Demo 🎮 • Install 💻 • Translations 🈺 • Discord 👋
- 🖌️ Highly customizable with an extensive drag and drop grid system
- ✨ Integrates seamlessly with your favorite self-hosted applications
- 📌 Easy and fast app management - no YAML involved
- 👤 Detailed and easy to use user management with permissions and groups
- 👥 Support for single sign on via OIDC / LDAP
- 🙊 Safe encryption using BCrypt and AES-256-CBC for your valuable data
- 🕔 Realtime widget updates using WebSockets, tRPC and Redis
- 🔍 Search through thousands of data points in supported integrations or your data in Homarr using the fast built-in search
- 🦞 Icon picker with over 11K icons
- 🚀 Compatible with any major consumer hardware (x86, Raspberry Pi, old laptops, ...) and most OS (Windows, Linux, TrueNAS, Unraid)
- 🖥️ Extensive Kubernetes support with Helm for efficient scaling & high reliability
Please click here for official installation instructions
Homarr is a free-to-use open source project maintained by volunteers and developers from all over the world.
We publish under the Apache License 2.0 license which allows commercial usage.
We invest multiple hours daily in providing support, developing Homarr, integrating to third party software and more.
We also pay for licensing and server hosting fees.
Please consider helping us cover these costs to enable the future development of Homarr. Thank you!
Please click here to sponsor us at OpenCollective
You can also support us by helping with translating the entire project to as many languages as possible or contributing directly to the code or documentation. Please read our Contribution Guidelines. All contributions, regardless of their size or scope, are welcome and highly appreciated! Thank you ❤️
Sponsors
Thanks to your generous sponsors, we can continue to build Homarr. Check them out for high-quality and easy-to-use development tools. Feel free to contact us at homarr-labs@proton.me if you wish to become a sponsor.





