Release an App

Submit an App you have checked in the sandbox using a GitHub version tag. Each submission contains one version of one App. Approval, publication, and installation are separate stages.

Automated checks and administrator approval

After source, build, contract and migration checks, AI reviews executable source in bounded parts for authorization, tenant isolation, reads and writes, data preservation, external communication and SDK usage. Documentation, dependency lock data and JSON translation dictionaries are inventoried separately rather than repeatedly reviewed as executable code.

The Console shows AI review progress. Completed parts are retained while subsequent parts are processed. Missing checks, errors and unresolved risks are not passes. After all required checks pass, an administrator must review the results and explicitly approve with a review note. AI cannot approve or publish an App. Publication, runtime deployment and tenant installation remain separate steps after approval.

Submit a version

In the App folder, run nexia check and composer test. Verify saves, reloads, and denied access in the sandbox. Use Test an App for checks specific to your change.
Connect GitHub under Project Apps → your App → Version submission in Console. First-time connection steps are below.
Commit and push checked source and dependency locks. From the App folder, run these commands with your actual version:

Code example

Shell

git tag v1.0.0
git push origin v1.0.0
nexia submit --tag v1.0.0123

With automatic submission enabled, check Console history after pushing the tag before submitting manually.

Developer responsibility

App developers prepare and verify the source, push a version tag, submit it, and follow up on review feedback. Nexia administrators approve and publish the reviewed release; operators deploy it. Developers do not deploy directly to production. Customer installation is separate, and a submission receipt or published status does not prove deployment or installation.

Follow your repository's merge policy before tagging the verified release commit. In the official workspace, this means a task PR into develop, followed by a release PR from develop into main. Nexia submits the remote tag's commit, not uncommitted changes or the current sandbox source.

Choose the App

Inside an App folder or its subdirectory:

Code example

Shell

nexia submit --tag v1.0.01

At the connected project root, the same command prompts you to choose an App when there are several. One App is selected automatically; no Apps produces an error. A noninteractive run with multiple Apps requires --app. You can explicitly select a folder or App key:

Code example

Shell

nexia submit --app people --tag v1.0.0
nexia submit --app people --tag v1.0.0 --no-interactive --yes --json12

Automation requires an existing repository connection. --yes accepts confirmation; it does not bypass access checks. Git tag commands must still run in the owning App repository, not the project root.

Verify receipt and review results

You do not need to copy a UUID. List submissions or select one by App, tag, state and creation time:

Code example

Shell

nexia submit list
nexia submit status
nexia submit list --page 2123

From an App folder, the list is scoped to that App. From the project root, it covers the project. In an interactive terminal, use ↑/↓ and Enter to select. Without a terminal, status without an ID returns a list. Automation can use nexia submit status <submission-id> --json.

The matching CLI shows check states, analysis progress when available, the review note, and a next action. Full feedback remains under Version submission in Developers.

Result	Next action
Already submitted	Inspect the existing submission. No new submission is created, including when automatic submission already received the tag.
Waiting / queued / running	Check status later. A preceding review can delay source processing or build work; do not submit duplicates.
Checks incomplete	Inspect failed, blocked or stale checks in Developers. Missing evidence is not a pass.
Ready for human review / approved	Wait for administrator review or publication respectively.
Published	Check `nexia status` and operator confirmation for deployment availability. Publication is not deployment or installation.
Retryable source failure	Use `nexia submit retry` to select the existing submission. Automation requires its ID and confirmation.
Build needs review / uncertain outcome	Contact developer support with the request or submission ID. Do not reset data or create duplicates to bypass it.
Rejected / cancelled / changed code	Address feedback and submit a new version tag.
Existing version points to different code	Submission is rejected. Do not move the old tag; use a new version tag.
Response lost	Repeat the original tag and printed `--request-id`; Nexia returns the original submission, even if the remote tag has since moved.

Repeated submission returns the existing receipt. Inspect its status before deciding whether a retry or a new version is needed.

Receipt does not mean publication. Cancelled or rejected versions cannot be reused for different code. Publication does not replace your current sandbox source.

Submission and version boundaries

Each submission targets one App and one specific version. Submit Apps separately even when you develop several in one project. An App has at most one review in progress. Submitted files are immutable: prepare a new version for changed code. Renaming a project or directory does not create a new identity or bypass version constraints.

Target	Declaration and meaning
App version	Identifies the immutable submission artifact. A Git tag alone does not publish it.
PHP SDK	Declare the supported public SDK range in Composer `require`.
React SDK	Declare the frontend SDK range in `peerDependencies`. PHP and React SDK versions are independent.
Core compatibility	`nexia.json` → `core_version` declares the supported platform range; it is not an installation command.
Initialization version	`VersionedTenantAppSeederContribution::versions()` identifies required default-data work. Bumping only the App release does not rerun completed seeding.
Resource contract	`ResourceDescriptor::version` identifies the contract used by other Apps.
Event schema	Event and subscription payload versions are independent of the App release.

Start from the generated dependency declarations and claim only tested ranges. If a new SDK capability needs a new Host implementation, raise both minimum versions. Do not add an arbitrary Composer version field or leave local SDK path/link: dependencies in release configuration.

Publication does not activate the version for every customer. Verify fresh installation and upgrades from existing data, including previously disabled installations. Required defaults must preserve user edits on repetition; update the initializer version when those defaults change.

Check the candidate

Record your sandbox observations and the following change impacts.

Verify both a fresh installation and upgrades with existing data.
Retain applied migration files and add new migrations. Uninstall, disable and failed updates must not automatically delete migration history or data.
Required initialization runs during installation and must preserve user edits and existing data on repetition. Demo fixtures are explicit development operations.
Review public fields, filters, events, permissions and commands. Bumping a version number does not make a breaking change compatible with existing consumers.
Verify required Apps exist and their versions are usable. Exclude secrets, customer data, Core code and other Apps' private source from the submission.

Record the App revision, dependency locks, executed checks and affected consumers. Do not report unrun checks as successful.

Connect a GitHub repository

Formal submission requires the Nexia GitHub App to be installed with access to the repository. This installation is separate from the GitHub login OAuth App. Reuse an existing installation if it already has access to the repository.

In Console, open the App's Version submission → Connect or change repository and authorize with GitHub. Interactive nexia submit opens the same page when repository access is missing.
Choose Install Nexia GitHub App or manage access, then select your account or the organization that owns the repository.
Select the repository and install the App, or add repository access to its existing installation. Request approval from an organization administrator when organization policy requires it.
Return to Console, refresh the repository list, and choose Connect this repository. You must have administrative permission on the repository to connect it.

If the repository is not connected or access has been revoked, nexia submit directs you to check installation and access and approve repository access in Console. App developers do not create a GitHub App or configure webhook URLs.

Connect one repository to one App. A current standard PHP/React App with nexia.json must be at the root. Monorepos, subdirectories, submodules and Git LFS are unsupported. Registration and sandbox development do not require GitHub; formal submissions do.

After enabling Automatic submissions, pushing a new v + SemVer tag submits it for review. Select existing tags in Console or submit them with the CLI. GitHub Releases are unnecessary; lightweight and annotated tags are supported. No branch selection is stored.

Cancel or recover a submission

Use nexia submit cancel <submission-id> for a cancellable submission. Deleting its tag does not cancel it.

Retry a transient source-collection failure with nexia submit retry <submission-id>. Ask developer support about uncertain builds or review-required states, including the request ID and error. If only the original submission response was lost, recover with the same printed --request-id.

Submission reads an existing tag on GitHub. Uncommitted or unpushed files are excluded, and your personal sandbox need not be running. A later version waits rather than replacing the active review.

See the public CLI documentation for command and option details.

Wait for inspection updates and retry checks

Core 0.8.169 retains a submission and its pinned commit while inspection tools are being updated. Inspect the submission's wait reason instead of changing its tag or repeatedly creating requests. Once a compatible inspection tool is ready, the retained submission can proceed. Receipt does not imply review success.

With Core 0.8.172, the server can also mark a transient platform test failure as retryable. Check status, then use the existing submission ID:

Core 0.8.185 also records completed compatibility failures instead of leaving the submission waiting for its results. These failed checks continue to block review and publication. Retry only when the server reports that the submission is ready; the original failure evidence is retained.

Code example

Shell

nexia submit status <submission-id> --json
nexia submit retry <submission-id>12

Retry is subject to current state and permission. It keeps the submitted source and original check evidence, and must pass all mandatory checks. Source fixes require a new tag; retry cannot bypass an App failure, administrator approval, deployment or installation. See GitHub submission recovery and Nexia CLI.