Applications & environments

NitroPush uses two layers to organise your releases:

• Projects — one per app. e.g. NitroPush iOS, NitroPush Android. If your iOS and Android apps share the same JS bundle, one project with both platforms enabled is enough; if they ship independently, create two.
• Environments — test, stage, prod. Each environment has its own rolling release timeline + its own deployment key.

A release always lives in one project + one environment + one or more platforms. Promoting a release means “create the equivalent release in a higher environment”.

Create a project

Click New project and fill in:

• Name — what shows up in the dashboard. e.g. NitroPush Mobile.
• Platforms — pick ios, android, or both. The CLI rejects releases that target a platform the project hasn’t enabled, so this is a real guardrail.

When you create a project, NitroPush automatically scaffolds the three default environments (test, stage, prod) for you. Each gets a fresh deployment key — you’ll need those in a moment.

Environments + deployment keys

Open a project to see its environments. Each row shows:

• Name — test, stage, or prod.
• Deployment key — opaque string like TEST-KEY-Q1IEQH. The SDK authenticates with this. Treat it as a secret (don’t commit to git); pass via env var at app build time.

Wire the deployment key into the SDK. The simplest path is the no-arg configure(), which reads the NITROPUSH_* keys from Info.plist / AndroidManifest.xml:

import { configure } from '@nitropush/react-native';

const client = configure();

Targeting a self-hosted server or custom CDN? Pass an explicit config with configureWith() instead — handy for sourcing the key from Expo env vars:

import { configureWith } from '@nitropush/react-native';

const client = configureWith({
  serverUrl:       process.env.EXPO_PUBLIC_NITROPUSH_SERVER_URL!,
  deploymentKey:   process.env.EXPO_PUBLIC_NITROPUSH_DEPLOYMENT_KEY!,
  storageBaseUrl:  process.env.EXPO_PUBLIC_NITROPUSH_STORAGE_BASE_URL!,
});

See Installation for the full native + JS setup.

Different builds use different keys. The convention most teams settle on:

Rotating a key invalidates all in-flight devices using it — they fall back to the binary-shipped bundle on next launch. Useful for kill-switch scenarios.

Why two layers?

Because environment ≠ platform. You might want:

• A bug fix that lands in test/ios first, then promotes to test/android, then to stage (both platforms), then to prod (5% rollout, then 25%, then 100%).
• A platform-specific hotfix that touches only iOS, never Android.

Both flows compose naturally: project + environment + platforms.

Configure storage (one-time setup)

Releases get uploaded to your S3 bucket (or GCS, or local disk for dev). NitroPush is the control plane; your bucket is the data plane. No bandwidth markups, no vendor lock-in.

Pick a provider and paste credentials. Defaults work out of the box:

• Local — for dev only. Releases sit on the admin server’s filesystem.
• S3 — bucket, region, access key, secret. Optional endpoint for MinIO / Cloudflare R2 / DigitalOcean Spaces.
• GCS — service account key.

The configured bucket is shared across every project + environment in the org. If you need separate buckets per env (compliance, region split), open a support request.

Manage members per project

Want a viewer who can see iOS releases but not Android ones? Open a project’s settings tab and add per-project members. By default everyone in the org sees everything; per-project ACLs are opt-in.

Next: Notifications →