Publishing Blender Add-on Updates
Claim an add-on ID, publish a version, ship a changelog, and see how fast a release actually reaches your users — the developer side of Project LEUC.
Most of the work of shipping an add-on update is the part nobody sees: knowing whether the update reached anyone. This is the developer-facing half of Project LEUC — what you do when you release, and what you get back.
If you have not integrated yet, start with the drop-in module; that is the code side. This page is about the account side.
The three steps
1. Claim your add-on ID
A unique ID that matches the one in your blender_manifest.toml. Claim it once. It is yours from then on.
2. Publish a version When you release, publish the new version number to the dashboard. This is the number every install compares itself against.
3. Ship the check
Your add-on asks once per session whether anything newer exists. Two lines in register().
Full detail lives in the documentation, including the API reference if you would rather call the endpoint yourself than use the module.
Why ID ownership matters
It is easy to read "claim an ID" as bureaucracy. It is the opposite — it is the thing that makes the whole mechanism safe.
An update notice is a message telling a user that new code exists. If anybody could publish a version under any ID, that message would be worth nothing, and a bad actor could point your users somewhere you did not choose. Namespace ownership means the only person who can say "MyAddon 2.4 exists" is the person who owns MyAddon.
It also protects you from the mundane version of the problem: two developers independently picking cable_tools as an identifier.
What you get back
Version distribution. How your installed base actually splits across versions. This is the number that tells you whether a release landed or whether half your users are still on a build from last year — which is the default state for most paid add-ons.
Update velocity. How quickly a new release propagates. Useful for the practical question of when it is safe to stop supporting an old version.
Changelog support. Release notes attached to the version, so the notice a user sees can say what they are getting rather than just that something changed. This matters more than it sounds — "update available" converts badly; "fixes the crash on Blender 5.2" converts well.
A clearer support queue. When a bug report arrives, knowing the reporting version is the difference between debugging and guessing.
What it deliberately does not do
Worth stating plainly, because "update platform" implies more than this is.
| It does | It does not |
|---|---|
| Answer "is there a newer version?" | Host your files |
| Store your version number and changelog | Handle payments or take a cut |
| Verify who owns an add-on ID | Require open source |
| Report adoption across versions | Require you to sell anywhere in particular |
| Batch checks for the whole library | Replace extensions.blender.org |
If you ship on the official extensions platform, Blender already handles updates natively and you do not need this. It exists for everything that platform cannot take — closed source, sold direct, or distributed as a .zip from your own site.
Release habits worth having
Most of the value here is process, not tooling.
Publish the version at release, not before. The check compares against whatever is published. Publishing 2.4 before the download is live produces a notice pointing at nothing, and that is the fastest way to make users distrust the notice.
Write the changelog for the person deciding whether to bother. Two lines about what broke and what now works beats a commit log.
Keep your blender_manifest.toml version honest. The whole comparison rests on it. A manifest that still says 2.1 while you ship 2.4 makes every install think it is current.
Declare a real Blender version range. A product page listing 4.2–5.2 signals maintenance; one that stops at 4.1 signals abandonment, and buyers do read it. This is also what users are told to check before buying.
Do not check on every startup. The module already checks once per session and off the main thread. If you write your own, do the same — an add-on that adds a network round trip to every launch becomes part of somebody's startup time problem.
On the incentives
I run this and I also sell add-ons, which is a fair thing to be suspicious about. The honest version:
I make about thirty add-ons, most sold as .zip downloads, so most of my own customers have never been told when I shipped a fix. I built this because I needed it. Making it free and open to everyone costs me nothing I was otherwise earning, and a service only I used would not have been worth building.
There is no paid tier, no plan for one, and nothing about your add-on's price, licence, or storefront is any of the service's business. If that changes I would rather you read it here than discover it.
Getting started
Create a free account, then follow the quick start. The integration guide and API reference are linked from there.