DeployYourApp delivers over-the-air (OTA) updates to Capacitor and Electron apps. You build your web assets, upload them as a bundle, and devices download and activate that bundle on their next update check.
The problem it solves
A shipped mobile or desktop app carries its web assets inside the installed binary. Changing a single line of that code normally means a new build, a new store submission, and a wait for review before any user sees the fix.
DeployYourApp separates the two. The native binary stays in the store. The web assets it loads are served from your channel and can be replaced whenever you deploy. A fix reaches devices on their next check instead of on the store's schedule.
What an OTA update can and cannot change
This is the most important thing to understand before you build on the platform.
A bundle is a ZIP of one directory: your built web assets. Nothing else is transferred, and nothing else is replaced.
An update can change:
- HTML, CSS, and JavaScript in your web build output
- Images, fonts, and other static assets inside that directory
- Anything your app renders from those files
An update cannot change:
- Native iOS or Android code, including the Capacitor plugins compiled into the app
- The Electron main process and preload scripts — these ship in the installed application
- Native dependencies, entitlements, permissions, app icons, or the app name
- The native app version reported to the store
- The Capacitor plugin or Electron updater itself
Adding a new native plugin, requesting a new permission, or upgrading Capacitor still requires a native build and a store release. DeployYourApp is not a replacement for that path — it is a faster lane for the web layer that sits on top of it.
Bundles can be pinned to a range of native versions, so a bundle that depends on a newer native build is not served to devices still running the old one.
Components
| Component | Package | Where it runs |
|---|---|---|
| CLI | @deploy-your-app/cli (binary dya) |
Your machine and CI |
| Capacitor plugin | @deploy-your-app/capacitor-update-manager |
iOS and Android devices |
| Electron updater | @deploy-your-app/electron-update-manager |
Windows, macOS, and Linux desktops |
| Dashboard | — | https://app.deployyour.app |
| Server | — | https://api.deployyour.app |
CLI
dya is how bundles get created and released. It zips your web assets, computes a SHA-256 checksum, signs the bundle with your RSA-4096 private key, optionally encrypts it, uploads it, and points a channel at it. See the CLI command reference.
Capacitor plugin
The plugin checks for updates, downloads and verifies bundles, and activates them in the webview. With the default autoUpdate: true it runs the whole cycle without any code from you beyond one notifyAppReady() call. See the plugin API reference.
Electron updater
The updater runs in the main process, exposes a contextBridge API to your renderer, and reloads the window onto the new bundle when one is applied. See the Electron setup guide.
Dashboard
The dashboard is where you create apps and channels, review deployments and devices, roll back, manage your team, and handle billing.
Server
The server stores bundles, decides which bundle each device should receive, and records analytics. Devices talk to two public endpoints: POST /api/update and POST /api/stats.
Safety model
Three mechanisms limit the damage a bad bundle can do:
- Signature verification. Bundles are signed with an RSA-4096 private key that never leaves your machine. Clients configured with the matching public key reject anything that fails verification. See Encryption and bundle signing.
- Ready check. After activating a bundle, the client waits for your app to call
notifyAppReady(). If that does not happen withinappReadyTimeout(10000 ms by default), the client rolls back to the previous bundle on its own. - Staged rollout. A deployment can target a percentage of devices. The selection is deterministic, so a device does not flip in and out of the rollout between checks.
Who it is for
DeployYourApp fits teams that ship a Capacitor or Electron app whose logic lives mostly in web code and who want the fix-to-user delay measured in minutes. It fits less well if your changes are usually native, or if your app must run entirely offline and never contact an update server.
Next steps
- Quick start — from an empty project to a delivered update
- Core concepts — the vocabulary the rest of the documentation uses
- Plans and pricing — what each plan includes