Guides8 min read

Automate channel promotion for safe OTA releases

Promote the exact bundle you validated from beta to production automatically — on a schedule, a tag, or a manual approval gate. Channel-promotion patterns for Capacitor live updates with OtaKit.

Staged rollouts are safe, but they add a manual step: someone has to promote the validated bundle from beta to production. Automating that promotion — on a schedule, a tag, or an approval click — keeps the safety of staging without the babysitting. This guide covers the promotion patterns for OtaKit channels.

Mental model: releasing to beta is automatic. Promotion is the gate. Automating the gate means promoting the same bundle you validated — never a rebuild.

The core command

Promotion is pointing a channel at a bundle id you already released and validated. The bundle doesn't change; only its audience does:

otakit release <bundle-id> --channel production

Everything below is just different ways to decide when to run that command.

Pattern 1: soak-then-promote on a schedule

Release to beta on every merge, then a scheduled job promotes the latest healthy beta bundle after a soak window. In GitHub Actions, a scheduled workflow can look up the current beta bundle and promote it if your health checks pass:

on:
  schedule:
    - cron: "0 15 * * 1-5"   # weekday afternoons, after a morning soak

Gate the promotion step on your own health signal — crash-free rate, error budget — so a bad beta never auto-promotes. See staged rollouts for what to watch.

Pattern 2: promote on a tag

Make promotion an explicit human action tied to your release process. Merges go to beta; cutting a version tag promotes to production:

on:
  push:
    tags: ["v*"]

# job step:
#   otakit release "$BETA_BUNDLE_ID" --channel production

Pattern 3: manual approval gate

Keep automation for the mechanics but require a human to press go. GitHub Actions environments and GitLab manual jobs both support an approval step before a protected job runs — the promotion command runs only after someone approves the deployment.

# GitLab: a manual promotion job
promote:
  stage: promote
  when: manual
  script:
    - otakit release "$BETA_BUNDLE_ID" --channel production

Tracking the bundle id

Every pattern needs the beta bundle's id. Capture it from the upload step's output and pass it to the promotion step (an artifact, a job output, or a small state file). That's what guarantees you promote the exact artifact you tested, not a fresh build.

Automating promotion doesn't mean removing the gate — it means making the gate consistent. Health-check it, and a bad bundle stays on beta.

Where to go next

Combine with the GitHub Actions or GitLab release flows, and see the channels docs for the full API.

Related docs