OtaKitnpm scripts for Capacitor OTA releases
Wrap the release flow in package.json so shipping an update is one command everyone on the team knows. Copy-paste npm scripts for building and releasing Capacitor OTA bundles with the OtaKit CLI.
The fastest way to make a release process reliable is to make it boring: one command everyone on the team runs the same way. Wrapping the build-and-release flow in package.jsonscripts turns “how do I ship an update again?” into npm run release. Here are copy-paste npm scripts for Capacitor OTA releases with the OtaKit CLI.
The core scripts
{
"scripts": {
"build": "vite build",
"release:staging": "npm run build && otakit upload --release staging",
"release:prod": "npm run build && otakit upload --release production",
"release:hotfix": "npm run build && otakit upload --release production --force-immediate"
}
}Now shipping to staging is npm run release:staging, and an emergency fix is npm run release:hotfix. Swap vite build for whatever your framework uses (next build && next export, ng build, etc.).
Chaining npm run build into the release scripts guarantees you never upload a stale dist/. It's a small thing that prevents a very common mistake: shipping yesterday's build because you forgot to rebuild.
Add a promote step
If you validate on staging and then promote the same bundle, you don't rebuild — you re-release the validated artifact to production. Keep that as its own script so the intent is explicit:
{
"scripts": {
"promote": "otakit upload --release production"
}
}See channel promotion for the validate-then-promote discipline this encodes.
Wire it into CI
The same scripts run in CI unchanged — your workflow just calls npm run release:prod after tests pass. That keeps local and CI releases identical, which is exactly what you want when debugging “works locally, fails in CI.” See automate releases with GitHub Actions and CI automation.
Keep secrets out of scripts. The CLI reads its token from the environment, so CI injects it and your local shell has it from otakit login — never hardcode it in package.json.
Where to go next
See the CLI reference for every flag, and staging environments with channels for how the staging/prod split works.