The Project LEUC Master Add-on
One panel that checks every LEUC-enabled add-on you own for updates in a single request, instead of twenty separate checks. Currently in development.
This is not released yet. It is in development, and this page exists because people ask what it will do, not because there is something to install today. If you want the part that works now, that is the drop-in module for developers and the per-add-on notices it produces.
With that said, here is the reasoning.
The problem it solves
Once an add-on ships update checking, it can tell you about its own new version. Good. Now own thirty of them.
Thirty add-ons each politely checking on their own behalf is thirty HTTP requests at startup, thirty places a notice can appear, and no single view of what is actually out of date. The per-add-on notice is the right design for one add-on and the wrong one for a collection — the same way a single N-panel tab is fine and sixty of them are not.
What it does
One request, not twenty Today each add-on asks for itself through the single-add-on endpoint. The master add-on collects every supporting add-on's ID and version and posts them together to the bulk endpoint instead — one request, one identification, one answer.
One list Everything with a pending update in a single panel, rather than a notice buried in each add-on's own preferences.
Bulk actions Act on several at once instead of walking through them one at a time.
Standalone It is its own extension. Add-ons do not depend on it, and it does not need to be installed for their own notices to work.
Why one request matters more than it sounds
Startup cost in Blender is not mostly about bytes. It is about serial work happening before you see a viewport, which is the whole reason Blender gets slow as your collection grows.
Twenty add-ons each opening their own connection is twenty chances to block, twenty timeouts to survive when the network is bad, and twenty independent failure modes. One batched request is one of each. It also means the answer for your entire library arrives at the same moment, which is what makes a single list possible at all.
The drop-in module is already built for this: it checks once per session rather than on every startup, and off the main thread. The master add-on takes that further by making it once per session for everything.
What it will not do
It will not find add-ons that do not support the platform. It can only report on add-ons whose developers ship the update check. An add-on that never reports its version is invisible to it — as it is to Blender itself.
It will not replace Blender's own update system. If you installed something from extensions.blender.org, Blender already handles it properly. Use Blender's own update flow for those; this is for everything Blender cannot see.
It will not host or install files it does not have a source for. Where a download lives is the developer's business, not the service's.
What to do in the meantime
The honest answer is that the practical steps today are the boring ones, and they work:
Connect Superhive as a remote repository if you buy there. It genuinely updates purchased extensions in place from inside Blender, it takes two minutes, and almost nobody knows it exists. Steps are in how to update Blender add-ons.
Keep a written inventory. Name, where you bought it, version you have. Ten minutes to write, and it turns "check everything" from a vague dread into a list you can actually work through.
Sweep on Blender releases, not mid-project. A new Blender version is when compatibility breaks, and it is the natural moment to check everything at once.
Clean Panels Pro
Relevant to the same problem from the other direction: it groups your add-ons into sets that load on demand rather than all at boot. The grouping doubles as the inventory the paragraph above asks for.
Mine, and genuinely not worth buying under about fifteen add-ons — below that the free approach in managing extensions is enough.
For developers
If you make add-ons, nothing here requires you to do anything differently. Ship the drop-in module and your add-on works with per-add-on notices today and with the master add-on when it lands — same integration, no second implementation.