skip to content

In EAS Update, how do you promote an update tested on staging to production, and when would you use eas channel:edit versus eas update:republish?

level: middleimportance: should knowfreq 40%

answer

  1. move the pointer or copy the update
  2. channel:edit repoints a channel
  3. republish copies an update group
  4. --destination-channel production
  5. same bundle that was tested

basics

~10 s

Either repoint the production channel at the tested branch with eas channel:edit, or copy the tested update group onto production's branch with eas update:republish --destination-channel production. Both reuse the tested bundle without rebuilding.

solid answer

~40 s

There are two promotion mechanisms. `eas channel:edit production --branch version-2.0` **moves the pointer**: production builds now follow the branch testers used, including whatever is published there later. It suits version-named branches, and it is refused while a branch rollout is in progress. `eas update:republish --channel staging --destination-channel production` (or `--group <id>` with `--destination-branch`) **copies an update group**: the exact tested bundle becomes the newest update on production's branch, and the mapping stays put. Expo recommends republishing for a persistent staging and production setup, with identical environment variables and code-signing settings on both, because re-running `eas update --channel production` would export a new bundle that nobody tested. Either way, the runtime versions must match production builds.

code

bash · 5 lines
bash
# copy the tested update group from staging to production's branch
eas update:republish --group <update-group-id> --destination-channel production --message "Promote typo fix"

# or move production to follow the tested branch
eas channel:edit production --branch version-2.0

go deeper

for a junior

Recall that an update tested on staging can be moved to production without a new build, by repointing a channel or republishing.

for a middle

Explain the difference: channel:edit moves a pointer to a branch, update:republish copies one update group to a destination branch or channel.

for a senior

Choose the mechanism that matches the branch strategy, keep environments identical so the tested bundle is what ships, and verify with channel:view.

for a principal

Define the promotion policy: which flow the team uses, who may repoint production, and how promotions are audited.

## What promotion means in EAS Update A team tests an update on **staging** builds, then wants **production** builds to get the same thing. EAS Update's indirection — builds carry a **channel**, the server maps each channel to a **branch**, and branches hold **updates** — gives two ways to do that without a new binary: move the channel's pointer, or copy the update. ## Option 1: repoint the channel with eas channel:edit ```bash eas channel:edit production --branch version-2.0 ``` This changes the server-side link so that builds on the `production` channel follow the `version-2.0` branch. - **What moves:** the whole update stream. Production builds now get the newest compatible update on `version-2.0`, and every later update published there. - **What does not change:** no update is copied, and branch `version-2.0` is untouched. - **Where it fits:** the **branch promotion flow**, with version-named branches (`version-1.0`, `version-2.0`) that move from the staging channel to the production channel as each is verified. - **Limits:** `channel:edit` refuses while a branch-based rollout is in progress on that channel; that state is managed with `eas channel:rollout`. ## Option 2: copy the update with eas update:republish ```bash eas update:republish --channel staging --destination-channel production --message "Promote typo fix" ``` `update:republish` publishes an **existing update group** again as the newest update on a branch. - **Choosing the source:** `--group <update-group-id>` for an exact group, or `--branch` / `--channel` to pick from recent updates (interactive). - **Choosing the destination:** by default the same branch — a way to put an earlier update back on top — or another branch via `--destination-branch`, or the branch a channel follows via `--destination-channel`. - **What moves:** one update group. The mapping stays as it was, and later staging updates do not follow automatically. - **Where it fits:** the **persistent staging** setup, where `staging` and `production` channels each follow their own long-lived branch. ## Why not just run eas update again? Running `eas update --channel production` from the same commit produces a **new export**. It is usually equivalent, but not guaranteed to be: environment variables, the local bundler cache or a stray uncommitted file can differ. Republishing reuses the **exact bundle and assets** that were tested. Expo's guidance is to keep environment variables and code-signing configuration identical on staging and production so the republished update behaves the same on both. ## Choosing between them | Question | `channel:edit` | `update:republish` | |---|---|---| | Unit promoted | a branch (stream of updates) | one update group | | Mapping changed | yes | no | | Future updates on the source | follow automatically | stay on the source | | Fits | version-named branches | persistent staging and production branches | Both require the promoted update's **runtime version** to match production binaries; an update tested on a staging build with a different runtime version reaches nobody on production. ## Mistakes to avoid - Repointing production at a feature branch for a one-off fix, then forgetting that every later publish to that branch goes straight to production. - Republishing an update whose runtime version belongs to the staging build only, so no production binary matches it. - Promoting by re-running `eas update` from a different commit or environment and calling it the tested update. - Using `channel:edit` during a branch rollout, which EAS CLI refuses; finish or revert the rollout first. ## For the typo hotfix 1. Publish the fix: `eas update --channel staging --environment production --message "Fix typo"`. 2. Open a staging build, confirm the text. 3. Promote: `eas update:republish --channel staging --destination-channel production`. 4. Check with `eas channel:view production` that the newest update on production's branch is the republished group. Gradual exposure of the promoted update — a percentage rollout — and reverting it are separate tools with their own commands.

  • After eas channel:edit production --branch version-2.0, what happens when someone publishes another update to version-2.0?
    Production builds with a matching runtime version receive it too, because the channel now follows that branch. Repointing promotes the whole stream, so version-2.0 must be treated as production from that moment.
  • Why does Expo recommend identical environment variables and code-signing settings on staging and production when promoting by republish?
    Republishing copies the tested bundle byte for byte. Values baked in at export time and the update's signature must be valid for production builds too, otherwise the copy that worked on staging misbehaves or is rejected on production.

saying these in an interview costs you the question

  • channel:edit copies the staging update into the production branch
  • update:republish rebuilds the bundle from the current commit
  • Re-running eas update for production is identical to promoting the tested update
  • Promotion requires shipping new production binaries
  • channel:edit can be used freely during a branch rollout