Upload and Manage Releases

Upload an existing bundle

nitropush release upload \
  --project PROJECT_ID \
  --environment prod \
  --runtime-version 1.0.0 \
  --label 1.0.1 \
  --bundle-path ./dist-ios

NitroPush detects Expo output from metadata.json and CodePush output from Hermes .hbc bundles. Use --kind expo or --kind codepush when detection needs an override. For NativeScript, use explicit --kind nativescript, the complete built app directory, an exact runtime fingerprint, and a signing key. See the NativeScript release workflow.

The dashboard version is the automatic integer sequence, starting at 1 for each project/environment/runtime target. Labels and runtime fingerprints are stored separately. Do not use a fingerprint as a release label. Failed/expired upload reservations can leave gaps; never renumber signed releases.

Let the CLI build

nitropush release upload \
  --project PROJECT_ID \
  --environment prod \
  --runtime-version 1.0.0 \
  --label 1.0.1 \
  --bundle

Add --project-dir or --entry-file when the current directory and index.js defaults do not match your app. Automatic bundling is for RN/Expo only; build NativeScript with its own Webpack/native pipeline.

Common options

Rollout and promotion

nitropush release rollout --release-id RELEASE_ID --percentage 25
nitropush release promote --release-id RELEASE_ID
nitropush release list --env ENVIRONMENT_ID --platform ios --runtime-version 1.0.0

Start with a limited rollout, watch application health, then increase the percentage. Promotion moves a release to the next environment.

Signed release context cannot be rewritten during promotion. For signed releases (including every NativeScript release), upload and sign a fresh release for the destination environment instead of using release promote.