1. Paste your __init__.py
2. Your blender_manifest.toml
Save this next to your __init__.py, at the root of the add-on folder.
3. Build it
blender --command extension build blender --command extension validate your_addon.zip
This page reads your source text. Only Blender itself can confirm the
result actually installs — always run validate before uploading.
One question, if you have ten seconds
I’m a solo developer working out which Blender add-on to build next. Which repetitive Blender chore would you pay to never do again? Reply with one sentence — that’s the whole survey, and it decides what gets built.
Tell me on GitHub → (one line is plenty — no account of mine required, no newsletter, no follow-up)
What changed in 4.2, briefly
| Legacy add-on | Extension (4.2+) |
|---|---|
bl_info dict in __init__.py | blender_manifest.toml file |
version as a tuple | version as a "1.4.2" string |
category, one string | tags, a list from a fixed vocabulary |
| Licence unstated | license required, SPDX identifiers |
Plain import my_module | Relative from . import my_module |
| Any Blender version | blender_version_min ≥ 4.2.0 |
| Network access unannounced | Declared under [permissions] |
Official reference: Blender Manual — Extensions. Tag names and SPDX identifiers are validated at upload; check yours against the manual if this page marks one as unmapped.
What this does and doesn’t do
It reads your bl_info and writes the manifest fields it can honestly derive.
Where the manifest needs something bl_info never carried — a licence, a contact
email, a tagline under 64 characters — it fills in a marked placeholder and tells you, rather
than guessing and leaving you with a file that looks finished but is wrong. It does not
rewrite your Python, and it does not build the zip.