blender_manifest.toml
Version is read from the manifest on disk — the actual source of truth, not a constant someone forgot to bump.
A complete update pipeline for Blender add-ons. You publish a version; every client that has your add-on installed finds out on its next check.
Publishing a version writes one static JSON manifest per add-on to the CDN. Clients read that file and do the comparison themselves, on a background thread, so Blender never waits on the network — and a check still answers while the backend is down for maintenance.
Claim your ID once and it is bound to your account. If someone contests it, evidence goes to review rather than to whoever registered first. Verified add-ons carry a badge users can check.
Version spread across your installed base, and how quickly a release is taken up. Enough to know when an old branch can finally be dropped.
Reporters file straight from Blender — traceback pasted, auto-redacted, sent. You get a ticket to triage from the dashboard, duplicates to merge into one thread, and a message in Discord the moment it lands, if you have wired up a webhook.
A free desktop app, separate from the update service and useful without an account. It finds the versions already installed, installs new builds from blender.org with the checksum verified before anything is unpacked, and opens each .blend in the version that saved it.
Get the launcherVersion is read from the manifest on disk — the actual source of truth, not a constant someone forgot to bump.
One static JSON per add-on, read straight off the CDN. It is written when you publish, so it is cached, cheap to serve, and the same answer for everyone.
Versions are compared on the machine doing the checking, along with the channel that user is on and whether their Blender falls inside the compatibility window you declared.
Changelog attached, criticality flagged, one click to the download. Nothing installs itself.
One file. Async checks, no blocking, no third-party dependencies.
A static JSON per add-on: latest version, changelog, update URL, compatibility window.
Reads blender_manifest.toml directly.
For anything custom. Ask about one add-on or a batch and the comparison comes back done.
No account for the reporter — a ticket they can poll for your status and note.
Wire a webhook once; every new report pings the channel with the excerpt, ticket, and versions.
Users see what changed before deciding to update.
Mark a release users should not skip.
Prove an add-on is genuinely yours.
blender.org's installer, Steam, scoop — and portable builds you point it at.
Checked against the checksum blender.org publishes before anything is unpacked.
Reads a scene header and starts the Blender that saved it.
Copy or link an add-on into another version, with a backup taken first.
How long each release you run still gets fixes, and what is coming next.
Builds land in its own library folder, not Program Files.
What is waiting on you, in a panel you leave on the desktop. Reorderable sections, four sizes.
The same news as one strip of icons on any edge, magnifying under the pointer.
One per account, for programmatic publishing. Replace it from the dashboard and the old one stops working.
Unregistered add-ons still get version tracking from independent sources.
Nobody running your add-on signs up for anything. A check carries add-on ids, versions, and a random install id used to de-duplicate.
No tiers, no seat counts, no card on file.