Community publishing.

Community nodes share executable operations or packages. Community templates share workflow starting points. Inspect the listing's author, purpose, requirements, version, and applicable prices before using either.

#Follow package references and copies

Adding a community operation creates a graph instance using the published operation. Cloning, where offered, creates private source under separate terms. A published Station freezes its accepted package; a later community update does not silently replace it. Test and submit updates, then check approval and compatibility. Favorites and Node Kits organize browsing rather than changing those requirements.

The published operation.py and bundled palette feed a referenced graph instance or a separately cloned private source. A later package version leaves the already-frozen Station version unchanged; the figure makes no automatic-update promise for references.

#Use shared work

Find a community node in the node browser and inspect its details. Use Add to Graph or double-click to add an instance. An unapproved operation can show an Add Anyway warning; read it before proceeding. A package can contain several node files and supporting assets.

Open a community template from Templates to instantiate a project. Review the graph and save your project separately. Shared work can still require a provider key, credits, a plugin, or compatible input data.

#Understand prices and copies

A listing can describe a per-run fee and, where offered, cloning terms. Read the listing's current choices before adding, running, or cloning. A paid node and a template containing that node are different things; using the template does not remove the node's execution requirements.

#Publish your work

For a node package, open the Node Editor's script browser, open the package root's context menu, and choose Publish to Community. Review Author, Version, optional website, run and clone pricing, and cloning permission. The primary node's schema supplies its category and description, so correct those in the node metadata before publishing.

Templates have a separate details-panel flow: supply Author Name and Version, then choose Publish to Community. Existing publications offer their supported Update or Unpublish actions.

Review everything bundled with either publication. Remove credentials and private source material. Ensure you can distribute the code, dependencies, assets, and examples you include.

Publication and approval state affect availability. A submitted or updated package is not automatically an approved community node for every surface. Stations accept supported approved community nodes and freeze the package with their published version.

#Maintain an existing publication

Describe input, output, and dependency changes when updating. Retest a small example before sending users to the new version. A Station that froze an older package does not acquire later code changes automatically; its author needs to publish a compatible update when appropriate.

#Keep adding, cloning, and publishing separate

Add: use Add to Graph or double-click a community operation and inspect its requirements and any pending-approval warning. Clone: make a private source copy where offered, with its separate terms. Publish: submit your package or template and track its approval state. Favorites/Kits organize browsing, not executable Skill availability.

#Checks and next steps

A community graph instance can refer to a published operation without cloning its package into your private source. Cloning, where offered, creates a separate user copy and can have its own price. Read both run and clone terms before choosing the action. A package can contain several scripts and assets.

Favorites and Node Kits help you find operations; they do not enable Lab Skills, satisfy provider credentials, or change a package's approval state. For Stations, compatibility is checked in addition to approval, and community subgraphs are not currently accepted.

When publishing or updating your work, test the actual interface and include clear usage requirements. A pending submission or update is not approval, and an existing frozen Station version does not automatically adopt later package code. Keep a private working copy and verify the published listing separately.