Why Blender Add-ons Don't Report Updates

The short answer

Blender only offers updates for add-ons installed from a repository with a URL. Everything installed from a .zip lands in a local repository, and Blender's manual says plainly that "no updates will be available".
That covers most of the paid ecosystem — anything sold on Gumroad, a personal site, or on a store but not packaged as an extension.
The cost lands on everyone. Users run old builds and hit bugs that were fixed a year ago. Developers ship fixes nobody installs and answer the same support question forever.
The workaround developers use — bundling an updater that polls GitHub — only works if your source is public. Most paid add-ons cannot use it.
The missing piece is small: one endpoint that answers "what is the current version of add-on X?". Project LEUC provides exactly that, free, for any add-on regardless of where it is sold.

There is a bug in your favourite add-on. It was fixed fourteen months ago. You are still hitting it, because nothing ever told you a new version existed.

This is not a rare failure. For a large share of the paid Blender ecosystem it is the normal state — and if you only want the steps that do work today, how to update Blender add-ons has them. This page is about why the gap exists at all, because the cause is structural rather than negligence on anyone's part.

What actually happens

Since Blender 4.2, add-ons live in repositories. There are two kinds, and the difference decides everything:

Remote repository Has a URL. Blender can ask it what versions exist, compare against what you have installed, and offer an update. This is how extensions.blender.org works.

Local repository A folder on your disk. No URL, no version list, nothing to query. Blender has no way to know a newer version exists anywhere.

Install from Disk = local Every .zip you install by hand goes here. Blender's manual states it directly: "This is installed to a Local Repository and no updates will be available."

Blender is not being lazy or incomplete. You handed it a file. A file has no upstream. There is genuinely nothing to check.

The full mechanics — including the cases where updates do work, and how to trigger them — are in how to update Blender add-ons.

Why this hits paid add-ons hardest

Free extensions on the official platform are fine. They install from a remote repository, so updates flow normally, and that is one of the underrated reasons the most-downloaded free add-ons stay healthy.

Paid add-ons are a different picture:

Where it was bought	Updates in Blender?
extensions.blender.org	Yes
Superhive, packaged as an extension, repository connected	Yes
Superhive, not packaged as an extension	No
Gumroad	No
A developer's own site or Patreon	No
A bundle download	No

Superhive's remote-repository connection is genuinely good and under-used — it is covered in the update guide above. But it only applies to products packaged as extensions, on that one store. Everything else is a file in a folder.

The cost is real on both sides

For users, it is not just missing features. It is running a version that breaks on the Blender you upgraded to last month, when a compatible build has been sitting on the product page since March. It is a bug you have built a workaround habit around. And when you own thirty add-ons, "check every product page each time Blender updates" is not a plan anybody actually follows.

For developers, it is worse than it looks. You fix a crash, ship 2.4, and your installed base stays on 2.1 indefinitely. The support queue keeps producing the same report. Version fragmentation makes it impossible to tell whether a problem is in your current code or in a build from two years ago. And every hour spent on that is an hour not spent on the add-on.

Neither side can fix this alone. The user cannot make an add-on report its version. The developer cannot make Blender poll a repository that does not exist.

What developers currently do about it

Three routes exist, and each one excludes somebody.

Ship on extensions.blender.org. Updates work perfectly. It requires GPL-compatible licensing, which rules out most commercial add-ons.

Package as a Superhive extension and let buyers connect the repository. Good, real, and limited to that store and to products that qualify.

Bundle an updater. CG Cookie's blender-addon-updater polls a GitHub, GitLab or Bitbucket repo's tags or releases and offers a one-click install from your add-on's own preferences. It works well. It also requires your source to be public and tagged, which most paid developers cannot do.

So a developer selling a closed-source add-on directly to customers has no route at all — not because the problem is hard, but because nobody built the small piece that is missing.

The small piece that is missing

Strip the problem down and it is not a platform, a store, or a package manager. It is one question:

Given an add-on ID and the version installed, is there a newer one?

That is an HTTPS request and a JSON response. The add-on asks on startup, and if the answer is higher than what is running, it draws a line in its own preferences panel. No new store, no change to how the add-on is sold, no change to how files are hosted.

This is what Project LEUC is. A free endpoint that answers that question, plus the dashboard where a developer publishes the version number when they release. It deliberately does not host or distribute your files — you keep selling wherever you sell, on whatever terms you like.

Free, with no paid tier Not a trial, not freemium. There is no plan to charge for update checking.

Once per session, not per startup Off the main thread, and once per Blender session rather than every launch — so it should not cost measurable startup time.

A batch endpoint exists Today each add-on asks for itself. A bulk endpoint takes the whole library in one request, which is what the master add-on will use once it ships.

You own your add-on ID Claim it once and nobody else can publish under it.

You still host your own files The service reports that a version exists. Where the download lives is entirely yours.

Why I built it

I sell about thirty Blender add-ons. Most of them are .zip downloads, which means most of my own customers have no way of hearing about a new version — including the free ones I give away. I have answered "is this compatible with the new Blender?" more times than I can count, usually about a build that was updated months earlier.

Writing an updater for my own add-ons would have solved my problem and nobody else's. The version that helps is the one any developer can point at, so that is what this is.

I am not neutral about this, and it would be strange to pretend otherwise. What I can say is that the service is free, it has no upsell, and the honest description of it is on the features page rather than a pitch.

What each side can do now

If you use add-ons: connect Superhive as a remote repository if you buy there — it is the single biggest improvement available today, and it takes two minutes. Keep a plain text list of what you own and where it came from. Sweep the list when Blender releases a new version, not mid-project. Managing a large collection covers the rest.

If you make add-ons: if you can ship on the extensions platform, do. If you cannot, add an update check and publish your versions — it is one file and two lines in your register(). Whether you use this service or write your own, your users should not be finding out about your fixes by accident.