Send an OTA update to specific users or groups

Not every update should reach everyone at once. You might want a beta group on the newest build, a single customer on a hotfix you're validating, or an enterprise tenant pinned to a stable stream. This guide covers how to target Capacitor live updates to specific users and groups with OtaKit — and the honest limits of a static-CDN model.

Set a device's channel at runtime

Your app decides which channel a device follows — based on a user flag, a plan tier, an opt-in toggle, whatever you know about the user. Set it from the app:

import { OtaKit } from '@otakit/capacitor-plugin';

// put beta opt-in users on the beta stream
if (user.isBetaTester) {
  await OtaKit.setChannel({ channel: 'beta' });
}

Now a release to beta reaches exactly those users, and everyone else stays on production. See Channels & runtime version.

Common targeting patterns

• Beta group — opt-in users on a beta channel get releases early; you promote to production once they look good.
• Single customer / tenant — a dedicated channel for a customer who needs a specific build or a slower cadence.
• Plan tiers — route free vs paid users to different channels if their feature sets diverge.
• Internal / QA — a staging channel your team's devices follow.

The honest limits

Because OtaKit serves a static manifest per channel rather than computing a per-device response, targeting is channel-grained, not arbitrary-per-user. That's a deliberate trade: it's what keeps delivery cheap, CDN-cacheable, and self-hostable. For the vast majority of targeting needs — beta, tenant, tier, internal — channels are exactly the right tool. If you need truly per-individual server-side logic, that's the one thing a static model doesn't do, and it's worth being upfront about.

Where to go next

See A/B testing with channels and staged rollouts for two ways to use targeting in practice.