Cutting a release

Cutting a release means building a lane and sending the result to one or more of its distributions, following a live checklist. Because build and distribution are decoupled, a release is really “run the build recipe, then run each chosen distribution recipe.”

Where releases start

You can kick off a release from two places:

• Overview — each lane card shows its current version and its distributions; start a release right there.
• Release view — a dedicated space to pick the lane, the destinations, and watch the run.

The release flow

1. Pick the lane and destinations. Choose which lane to ship and which of its distributions to run — one, several, or all.
2. Confirm the version. AppRelay shows the current version from the lane's version source and, if you're bumping, writes the new value back in the correct format.
3. Build. The toolchain's build recipe runs first, streaming output as a checklist of steps.
4. Distribute. Each selected distribution recipe runs against the produced artifact — uploading, deploying, or publishing to its channel.
5. Review. Each step reports pass or fail from its own signal; the log stays available so you can read exactly what happened.

Reading the step checklist

Every release renders as an ordered checklist. Each step has:

Store credentials

Distributions to stores use the signing and credentials configured on the lane's distribution — for example an App Store Connect API key or an Android upload key. These are stored as secrets and referenced by name; the recipe supplies them to the underlying tool at run time.

Ship one build to several places

Because the build runs once and each distribution consumes its result, selecting three destinations for a lane ships the same artifact to all three — no rebuild, no divergence. This is the practical payoff of Build ≠ Distribute.

Environments (staging → production)

Define named environments for a project in Project Settings → Deploy Environments — e.g. Staging then Production — each with its own variables and secrets. In the Release panel, pick an environment before you ship and AppRelay injects its variables and Keychain secrets into the run's environment (available in commands as $NAME, and the environment's name as $APPRELAY_ENV); the secret values never touch the command line or the project file.

Environments are ordered, and that order is a promotion path: after a green staging release, Promote to Production re-builds and re-ships the lane against the next environment in one click.

Automated runs can target an environment too — pick one when you create a trigger (or pass --env <name> to apprelay trigger add), so a nightly build ships to Staging with its variables and secrets injected.

Requiring approval before a ship

For a production channel, turn on Require production approval before shipping on the distribution (Project Settings → Lanes). The build runs, then the ship pauses at an approval gate until someone explicitly approves it — and the approver's name and the time are recorded in the run history.

Approval can only be given at the desktop console. A gated channel triggered on a schedule or webhook, or shipped from the CLI or the phone, blocks rather than publishing — so a production release never happens unattended.

Next steps

• Recipes — customize the steps a release runs
• Distribution channels reference