Package and deliver your add-on

Deliver the package and retain editable source

Packages contain application code, built web assets, and manifest-permitted framework files. Keep source for maintenance and install runtime components separately. Do not ZIP the repository or frontend development directory for users.

This guide targets your own add-on. Official examples ship with complete source for learning/experience, without a separate example ZIP or packaging requirement. Their internals are not your runtime dependencies.

Pre-package checklist

• Disable development auto_reload and check identity, version, and minimum requirements.
• Include offline scripts, fonts, and images locally. Explain online dependencies and retain licensing/attribution.
• Declare actual platforms, maintainer, and file/network/clipboard purposes.
• List Python, pages, and assets individually. Use framework paths from the matching release.
• Exclude node_modules, caches, source maps, frontend development projects, local configuration, and private files.
• Root CEF is local payload and excluded. nexus_web/cef is framework source retained by manifest.
• Deliver runtime ZIPs separately or use installation guidance; never nest them in the add-on ZIP.

Use official build and validation entry points

Use Blender's extension build command in your add-on project. Paths below are placeholders; substitute your executable and source directory. The website does not execute them.

blender --factory-startup --offline-mode --command extension build --source-dir /path/my_addon --output-dir /path/output
blender --factory-startup --offline-mode --command extension validate /path/output/my_addon-0.1.0.zip

Keep --factory-startup --offline-mode before --command. Building and validating do not need your normal scene, preferences, enabled add-ons, or network access. Do not save over your normal preferences.

Package names follow manifest identity/version. Validate the actual built filename. Manual directory compression does not replace manifest-controlled builds and checks.

Inspect the ZIP, not just the manifest

1. Check entry points, scripts, styles, fonts, images, and helpers are included.
2. Look for accidentally included dependencies, caches, and development-only files.
3. Identify major size contributors; unexpectedly large packages may include entire font, texture, or library collections.
4. Trace relative paths from the packaged entry and exclude developer-specific absolute paths.

Install in an isolated test environment

Use a configuration that preserves everyday add-ons and work. Install the actual ZIP and check runtime guidance, page loading, main operations, cancellation, closing, and reopening. Do not overwrite or uninstall daily work merely to test a same-named add-on.

Build success proves artifact checks only. State unperformed installation/application checks and record target-platform results separately.

What do end users need?

Recipients need a supported Blender version, your add-on package, and matching runtime components. They do not need development tools or a frontend development environment. If the add-on connects to online services, follow its instructions for accounts and network access.

Deliver the add-on package and runtime components separately, with their respective license materials. Development tools and the full framework repository are not add-on packages for end users to install. Costs and commercial distribution lists the checks to confirm separately.

Tell users how to begin

• Explain name, supported environment, entry point, and expected first result.
• Use Download & Install for missing runtime components; offline, supply a matching package for Local Package….
• Explain online service requirements; local pages do not imply every feature works offline.
• Supply matching editable source and rebuild materials separately, or an accessible fixed-version source link. Keeping a private copy yourself does not fulfill source delivery.
• Copied frameworks include native compiled files but not complete rebuild source. Supply the full repository, native tools, and pinned dependencies matching build identity and file digests. Matching version labels alone do not establish correspondence.

Related prerequisites: Requirements, Runtime components, Verify in Blender. Building and local delivery do not mean public release or server upload.