NitroPush CLI

nitropush is the command-line tool for pushing releases. The same flow works on a developer laptop and in CI — the only thing that changes is where the auth token comes from.

Install

The CLI is published as @nitropush/cli:

yarn add -D @nitropush/cli       # per-project (recommended for CI)
# or
npm install -g @nitropush/cli    # global, for laptop use

In a workspace project, run via:

yarn nitropush <command>
# or
npx nitropush <command>

Auth

Two auth paths:

Laptop (interactive) — run nitropush login and a browser tab opens to the admin console’s CLI authorize page. If you’re already signed in there, one click sends the session token back to the CLI’s loopback listener; if not, you sign in with the usual email + OTP flow first and the redirect picks up afterwards. The token lands in ~/.nitropush/config.json and is reused for every command after.

nitropush login

If you’re on a headless box (no browser), pass the token directly:

nitropush login --token nltk_…

CI (token) — generate a long-lived API token from the admin and pass it via env var. No login step needed:

NITROPUSH_TOKEN=nltk_… nitropush release upload …

Inspect & sign out

Once you’ve logged in, two commands manage the local session:

nitropush whoami          # who am I signed in as?
nitropush whoami --json   # same, machine-readable
nitropush whoami --offline  # decode local token without hitting the server
nitropush logout          # wipe local creds + revoke the server session
nitropush logout --keep-server  # only wipe local — leave the server session alive

whoami exits non-zero when you’re not signed in (or the server rejects the token), so it’s safe to gate scripts with nitropush whoami > /dev/null || nitropush login.

logout is idempotent — running it twice is fine. It clears token/orgId/userId from the config but keeps serverUrl so the next login still points at the right host.

Common flow

For most teams the daily workflow is one command:

nitropush release upload \
  --project       <project-id> \
  --environment   test \
  --platforms     ios,android \
  --app-version   "*" \
  --label         v1.4.2 \
  --bundle-path   ./dist

The CLI auto-detects whether --bundle-path points at a metro export output (Expo flow) or a single bundle file / dist dir (CodePush flow), hashes everything, dedupes against existing assets, and uploads what’s new.

For end-to-end “ship a release” walkthroughs, see Get started → Releases.

Bundle signing

Bundle signing is an opt-in integrity check. When a project has a bundle-signing public key configured in Settings, the server rejects any release that doesn’t carry a valid signature from the matching private key — so a leaked deployment key alone can’t push tampered JavaScript to your users.

You generate an ECDSA P-256 keypair once, upload the public key in the admin (Settings → Bundle signing), and keep the private key on the machine that runs the CLI. The CLI signs bundle:<sha256> of the JS bundle and sends the signature with the release; the server verifies it against the stored public key.

Point the CLI at your private key PEM with --signing-key:

nitropush release upload \
  --project       <project-id> \
  --environment   prod \
  --app-version   "*" \
  --label         v1.4.2 \
  --bundle-path   ./dist \
  --signing-key   ./bundle-signing.pem

On a successful sign the CLI prints Bundle signed ✓ before uploading. The same flag works on release create.

In CI, set the key path via env var instead of a flag — write the PEM from a secret to a temp file first:

export NITROPUSH_BUNDLE_SIGNING_KEY=./bundle-signing.pem
nitropush release upload …   # picks up the key automatically

The flag takes precedence over the env var. If neither is set and the project requires signing, the upload is rejected by the server.

Generate a keypair (if you don’t have one yet):

# private key — keep it secret, add to .gitignore
openssl ecparam -name prime256v1 -genkey -noout -out bundle-signing.pem

# public key (base64 DER) — paste this into Settings → Bundle signing
openssl ec -in bundle-signing.pem -pubout -outform DER | base64 | tr -d '\n'

Command map

Run nitropush <command> --help for the full flag list of any command.

Typical flow

1. nitropush login — one-time, gets you a session.
2. nitropush app list — find your project ID + environment list.
3. nitropush release upload — push a bundle.
4. (optional) nitropush release rollout — bump rollout %.
5. (optional) nitropush release promote — copy a release across environments.

Exit codes

The CLI follows standard Unix conventions so it’s safe to compose in shell scripts:

In CI: nitropush release upload … || exit 1 is enough.