OtaKitSelf-hosted live updates for Capacitor apps
Own your update infrastructure end to end. How to self-host Capacitor live updates with OtaKit — a fully MIT-licensed stack, static CDN delivery, and no per-device metering or vendor lock-in.
For some teams, “send your users' update traffic through a vendor” is a non-starter — compliance, data residency, or just a hard rule against critical infrastructure you don't control. The usual catch is that “self-hosting” turns out to be a gated enterprise SKU. With OtaKit it isn't: the whole stack is MIT-licensed, and self-hosting is a first-class path, not a sales conversation.
What makes this practical is OtaKit's delivery model. Updates are served as a static, signed manifest from a CDN or object store per (app, channel, runtimeVersion)— there's no per-device dynamic endpoint to operate. That's the difference between hosting a web server and hosting a database-backed service under your users' launch traffic.
What “self-hosted” actually means here
Two independent pieces, and you can self-host either or both:
- Update delivery — the signed bundles and manifest. Because these are static files, hosting them is just object storage plus a CDN. Cheap, cacheable, and effectively unbreakable under load.
- The control plane — the API and console you use to cut releases and manage channels. Run it on your own infrastructure alongside your other services.
Why the static model matters
A lot of update services route every device check through a dynamic per-device endpoint that computes what to serve. That's powerful, but it means self-hosting is operating a request-per-launch backend — with all the scaling and reliability burden that implies. OtaKit precomputes the manifest per lane and serves it statically, so your self-hosted setup inherits the reliability of a CDN, not the fragility of a hot path.
The moving parts
- Object storage (S3-compatible) plus a CDN in front of it for bundle delivery.
- The OtaKit control-plane service and its database, on your infrastructure.
- Your signing keys, generated and held by you:
otakit generate-signing-key otakit generate-encryption-key # optional, for end-to-end encryption
Because you hold the signing key, bundles are cryptographically yours end to end — the device only activates a bundle whose hash matches your signed manifest. See OTA update security for the model.
Self-host vs managed: how to choose
- Managed if you want zero infrastructure and are comfortable with CDN-direct delivery from OtaKit's hosting. Still no MAU/bandwidth metering.
- Self-hosted if you have data-residency, compliance, or control requirements — you own the storage, the CDN, and the keys.
The comparison of both against a roll-your-own approach is in hosting options compared, and the licensing angle in open source vs proprietary.
Self-hosting an open-source stack also means no lock-in: if you ever want to move delivery to a different CDN or bring the control plane fully in-house, nothing about the format stops you.
Where to go next
The self-hosting docs have the deployment specifics; start there, then Security for key management.