Publish and manage app releases

Register and publish

octonodes app publish --workspace user:<id> builds and validates the current octonode.app.json, then creates an immutable app release under a publisher workspace. Use team:<id> or org:<id> for those workspaces. Sign in with octonodes login first and ensure you have publisher access. For an extension-only release, the CLI uploads the compiled verified bundles. For a self-hosted release, the CLI registers metadata and remote asset digests; see hosting for deployment.

Choose distribution at registration

Omitting --distribution defaults to the publisher workspace kind. The CLI also accepts --distribution user, team, org, or public; Partner offers the same audience choice. Choose the intended audience before the first registration because it cannot be changed on that app ID. A public listing is discoverable outside the owner workspace, but this release has no separate public app review or billing workflow. Register another app if the audience needs to change.

The first publication returns the registered app ID and revision. Keep both for an update. Increment version in octonode.app.json, build and test, then run:

npm test
octonodes app publish --workspace user:<id> --app-id <registered-app-id> --revision <current-revision>

The revision guards against overwriting another publisher's concurrent edit. Use the latest revision displayed in Partner → Apps → [your app] when your local value is stale. An existing version cannot be replaced. Releasing a new version updates discovery; existing installations remain pinned until an administrator approves an update.

Partner also has a registration and publish form, app configuration, immutable version history, analytics, and development guidance. The app can be saved as an unpublished private draft before its first release. An unpublished draft is visible only to its publisher workspace and can be edited or deleted. Published app identity and releases cannot be deleted.

Install and operate

In Studio → Apps, select the destination workspace, inspect the version, origin, permissions, privacy/support links, and extension details, then install. Project access is optional during installation, including in an empty workspace. The consent step can grant requested actions to specific projects. An administrator can later update, disable, or uninstall the app. A block appears on workspace home; a page-capable app appears beneath Apps in Studio navigation. Block-only apps still appear in Apps → Installed. Uninstalling or changing consent revokes subsequent app access. Installed versions are not silently upgraded when a publisher releases a new version.

Publishers may deprecate an app to prevent new installs while existing pinned installations continue, then restore discovery later. Publishing a new release does not itself restore a deprecated app. The Partner analytics view shows installs, current active installations, reviews, ratings, and version adoption. Its date filter covers the last 7, 30, or 90 days, or an inclusive UTC custom range up to 366 days. Install counts include reinstalls; updates count separately. Active installations and version adoption reflect current state.

This release supports private app authoring and distribution. Public app moderation, payments, background service identities, webhook delivery, and managed hosting need separate platform contracts. See quickstart and configuration before publishing an app.