Deployment

A deployment builds your app from its default branch for iOS, Android or both, signs it and uploads it to the stores. Each one gets a number per application (#12) and a page with three tabs: Deployment, Release and Test.

Start a Deployment

Click Deploy on the application page, or press ⌘D (Ctrl+D on Windows and Linux) while you are on it, to open the deploy dialog:

• Source: the app's default branch. Blaze builds the latest commit on it, resolved when the deployment starts.
• Platforms & targets: tick iOS, Android or both (the platforms the app builds for), and choose a target for each. See Choose Targets.
• Version: read from pubspec.yaml on that branch when the deployment starts. Blaze assigns the build number.

The footer estimates what the deployment will cost in build credit, from this app's recent builds on its runners, next to the credit you have free to spend. The deployment holds that much credit while it builds and is charged for the minutes it actually uses. Without enough credit it is refused, unless auto-refill can add it. Click Start deployment and the deployment page opens.

Your plan runs a number of deployments at a time: one on Starter, three on Pro and ten on Team. A deployment started while they are all running waits for a slot, says so on its page, and starts when the one before it finishes.

When iOS and Android are both ticked, they build at the same time on separate runners, under one deployment number.

Targets that cannot run are disabled. A store target stays disabled until the connection it needs exists, and the dialog says which connection and links to Signing & keys. If the target the app normally uses is locked, the dialog selects the first one that can run and says so. The dialog starts on the target last deployed for the app, then the default target from the app's iOS settings or Android settings, then TestFlight (Internal) or Internal testing.

A known-broken key is flagged before you start. If a platform's key is already known to be broken, the dialog warns that the platform will fail, and offers to fix the key or to deploy only the other platform.

Choose Targets

Every iOS target builds, signs and uploads the same way. The target decides what happens after the upload:

Each Android target uploads to one Google Play track, shown here by the name Play Console gives it:

Android releases are full releases, with no staged rollout. Releases to Internal testing, Closed testing and Open testing contain arm64 code only; production releases and draft uploads contain every architecture.

Upload only still needs the store connection for its platform: iOS builds sign and upload with the App Store Connect key, and Android builds check the Play service account before compiling.

Blaze does not submit apps for App Review, set staged rollouts, or send release notes, screenshots or store listings to either store.

Deploy on Push

Turn on Deploy on push in the Repository card's Branch & repository… dialog. A push to the default branch then deploys every platform the app builds for, iOS and Android alike, when it changes the version: line of pubspec.yaml.

A pushed deployment uses the default target from iOS settings and the default track from Android settings, or TestFlight (Internal) and Internal testing when none is set. Pushes to other branches, and tags, never start a deployment.

Follow a Deployment

The Deployment tab shows the commit, branch, version and build number, platforms and targets, who started the deployment and how, and the build minutes and credit it was charged.

Each platform moves through five steps, each with its own duration:

1. Prepare runner: Blaze reads your project from GitHub and checks it before any runner time is spent. iOS deployments also check the App Store Connect key with Apple.
2. Clone & pub get (on iOS, Clone, pub get & pods): the runner checks out the commit and fetches dependencies. On iOS this is also where the CocoaPods dependencies are installed, which is most of this step on a cold runner.
3. Compile: the release build.
4. Code sign & export: the signed .ipa or .aab.
5. Upload → TestFlight or Upload → Play Console.

For an iOS and Android deployment, a step lists each platform's state when they differ.

The Log card streams while the deployment runs. Filter it to errors or to one step, search it with ⌘F, copy it, or click Download logs for a text file.

While a deployment is queued or running, Cancel build asks for confirmation, then stops every platform that is still queued or building. Runner minutes already used still count, and a cancelled deployment cannot be resumed: start a new deployment instead.

When a Deployment Fails

A failed deployment shows a Likely cause card: the cause, the step and platform it failed on, the error, and a button to the setting that fixes it when the fix is a setting in Blaze. When the cause is a key, the card also offers a free credential check that uses no build minutes. When the cause is in your code, the card says so and the log has the line.

Retry deploy opens the deploy dialog, which repeats any warning about a broken key. The platform guides list common causes: iOS Setup, Android Setup and Build Configuration.

Release Tab

The Release tab opens once a deployment finishes successfully. Until then it is locked, and says why. It starts with what still stands between the version and App Review, then What's New, then what happens once Apple approves the version, then Submit.

• What's New belongs to the version, so every build of a version shares it until one ships. It takes up to 4,000 characters in each language, saves as you type, and reaches App Store Connect when you submit. Translate drafts the listing's other languages from the primary one.
• Fill from commits lists the subject lines of the commits since the version that's live on the App Store.
• ✦ writes What's New with AI from those same commits, in the app's template. It leaves out work people using the app never see, such as dependency updates and CI changes, and asks before replacing notes you've written. Read the draft before you submit. Write another asks for a new draft.
• The ··· beside ✦ opens the What's New template. A placeholder is a name in double curly braces. CHANGES_BULLET_LIST, CHANGES_ASTERISK_LIST and CHANGES_INLINE_LIST are the changes written from the commits, as a list or as one phrase, and SHORT_SUMMARY and LONG_SUMMARY are a sentence and a paragraph about them. APP_NAME and VERSION come from Blaze. Everything else in the template stays as you write it, and the preview shows the result with example text or with this version's commits. Style notes set the tone. The app's creator and the workspace's owners and admins can change the template.
• Writing from commits sends their messages to Anthropic, the AI provider Blaze uses. Co-authored-by and Signed-off-by lines are removed first. Translate sends What's New to Anthropic in the same way.
• For a deployment that built Android, a Google Play card shows the track, the package name and the version. Promoting the release to another track happens in Play Console.
• What to Test is on the Test tab, because it describes one build. The files a deployment produced are on its Deployment tab.

Test Tab

The Test tab lists the app's tester groups and their testers. Blaze does not report a tester's device, installed build or last session, so those columns say not reported.

Tester groups are managed from the application page's ··· menu, under Testers…. An iOS group is an Internal group (App Store Connect users, up to 100, no review) or an External group (email invites, up to 10,000, Beta App Review). Syncing a group is on demand. After a TestFlight (External) deployment, Blaze adds the build to the app's External groups; iOS tester groups need the App Store app ID in iOS settings.

Blaze's Android groups do not change the testers Google Play has for a track: add Android testers to the track in Play Console. See Google Play Console.

Next Steps

• iOS Setup and Android Setup: what each platform's build needs
• Build Configuration: Flutter and Xcode versions, branch and repository
• Environment Variables: values your Dart code reads at build time