Canales

Un canal de Live Update apunta a una build específica del bundle JS de tu app que se compartirá con cualquier dispositivo configurado para escuchar actualizaciones en ese canal. Cuando instala el SDK de Capgo Live Updates en tu app, cualquier binario nativo configurado para ese canal buscará actualizaciones disponibles cada vez que se inicie la app. Puedes cambiar el build al que apunta un canal en cualquier momento y también hacer rollback a builds anteriores si es necesario.

Respuesta corta: para staging y producción en una app Capacitor, crea un staging y un production canal en Capgo, sube cada bundle a staging primero, pruébalo y luego promociona el mismo bundle a production.

Canales en acción

Piensa en un canal como un puntero con nombre a una actualización: production puede servir tu app publicada mientras beta sirve a los testers. Estos tres videos cortos muestran cómo un dispositivo termina en un canal. Cada uno tiene música de fondo opcional y no tiene narración; las explicaciones de abajo cubren los mismos pasos.

1. Usa el canal por defecto

Un dispositivo en ejecución v1.1.0 solicita a Capgo una actualización. Sin asignación de dispositivo ni canal configurado en la app, Capgo verifica el predeterminado en la nube, production, y devuelve su v1.2.0 bundle. El dev y staging los canales mantienen sus propios bundles sin afectar a este dispositivo.

Descargar video del canal por defecto (MP4).

Configura el default de producción en Información de la app. Los builds de producción normales pueden dejar defaultChannel sin definir para que puedas gestionar ese enrutamiento desde Capgo.

2. Deja que el dispositivo elija un canal

Este tutorial usa setChannel() y unsetChannel() de los @capgo/capacitor-updater en Android e iOS; estos métodos no son compatibles con el navegador. Usa el comportamiento de local-channel disponible en updater 5.34.0+, 6.34.0+, 7.34.0+, o 8.0.0+ para la versión mayor de tu plugin. Las versiones anteriores escribían un override en el backend; esas asignaciones siguen el la consola y API anulan las reglas de retención.

Un tester activa las actualizaciones beta en tu app. Tu app llama a CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true }). Capgo verifica que beta permite la autoasignación del dispositivo y luego el plugin guarda la elección localmente para futuras comprobaciones de actualización. Otros dispositivos mantienen su routing actual.

Descarga el video de autoasignación de dispositivos (MP4).

Activar Permite que los dispositivos se asocien o desasocien en el canal de destino antes de usar setChannel(). Esta elección local no crea un override en la consola. En Android e iOS con el updater 8.51.0 o posterior, persistDefaultChannelOnReinstall por defecto es true, por lo que la elección solo sobrevive a una reinstalación si el sistema operativo restaura los datos de la app y persistDefaultChannelOnReinstall se mantiene true. Llama a unsetChannel() para borrar la elección local; las anulaciones de la consola y de API seguirán la siguiente precedencia.

3. Asigna un dispositivo desde la consola

En la consola de Capgo, abre Apps, selecciona tu app y abre Dispositivos, y selecciona un dispositivo. Cambia su Override de canal a dev. Capgo ahora enruta ese dispositivo a dev, mientras que el default en la nube de la app sigue igual production.

Descargar el video de override de dispositivo de consola (MP4).

Usa un override para pruebas dirigidas o soporte. Tiene prioridad sobre el canal local del dispositivo y el default en la nube, a menos que haya un mapeo forzado. Overrides de consola y de API expiran 90 días después de la última escritura de override.

¿Listo para probarlo? Crea un canal en la consola, luego subir un bundle para que lo sirva.

Los canales no proporcionan confidencialidad

Los canales controlan la elegibilidad de las actualizaciones, no el secreto del bundle. Aunque un canal sea privado o la autoasignación esté desactivada, cualquier bundle sin cifrar subido a Capgo debe seguir tratándose como un recurso público que se entrega a los clientes. El cifrado protege la ruta de entrega y la autenticidad de las actualizaciones, pero los bundles distribuidos aún pueden someterse a ingeniería inversa desde la app distribuida con suficiente esfuerzo, ya que la clave pública forma parte del cliente. Ver Cifrado de Live Update para más detalles.

Cómo un dispositivo elige un canal (precedencia)

Cuando un dispositivo busca una actualización, Capgo decide qué canal usar en este orden estricto (de mayor a menor prioridad):

1. Mapeo forzado de dispositivo (Dashboard) – Fija manualmente un ID de dispositivo concreto a un canal. Úsalo para depuración urgente o pruebas controladas con un único usuario real. Esto siempre tiene prioridad. Capgo elimina el mapeo 90 días después de la última escritura de la anulación. Ver Los overrides de Console y API caducan tras 90 días.
2. Override en la nube (por dispositivo) mediante Dashboard o API – Se crea cuando cambias el canal del dispositivo en el dashboard o a través de API. Úsalo para usuarios de QA que alternan entre canales de feature / PR o para reproducir un problema de usuario. Reinstalar el binario no lo borra; eliminar el override del dispositivo sí. Se aplica la misma retención de 90 días.
3. Plugin setChannel() canal local – Se crea cuando la app llama a setChannel() y el backend valida que el canal de destino permite la autoasignación. El canal seleccionado se guarda localmente en ese dispositivo, tiene efecto inmediato y no se muestra en la UI de Device Override.

Cambio instantáneo de canal con setChannel()

A partir de la versión del plugin 5.34.0, 6.34.0, 7.34.0 u 8.0.0 (según tu versión principal), setChannel() funciona de forma distinta: contacta al backend para validar que el canal esté permitido (comprobando si self-assignment está habilitado para ese canal) y luego guarda el canal localmente en el dispositivo como defaultChannel. Esto significa que el nuevo canal se aplica al instante en la siguiente comprobación de actualización, sin esperar la replicación.

Anteriormente, setChannel() guardaba la sobrescritura del canal en la base de datos del backend (como los cambios en el Dashboard o en API), y los dispositivos tenían que esperar a la replicación de datos (hasta 2 minutos) antes de que se reconociera el nuevo canal. El nuevo comportamiento solo lee del backend (para validación) y guarda localmente, lo que hace que los cambios de canal sean instantáneos.

Porque setChannel() es solo local, no necesitas crea una entrada de Device Override en el dashboard de Capgo. La interfaz de Device Override solo muestra las overrides creadas desde el dashboard o la API pública.

Nota: Aunque un canal quede deshabilitado después de configurarse localmente, el backend sigue validando el canal durante las comprobaciones de actualización, por lo que la seguridad se mantiene.

Importante: Cuando se realizan cambios de canal a través del Dashboard o API, existe un retraso de replicación de hasta 2 minutos antes de que todos los servidores de edge reflejen el cambio. Para cambiar de canal al instante, usa setChannel() desde tu app code: valida con el backend y luego establece el canal localmente para un efecto inmediato.

4. la config de Capacitor defaultChannel (build de test por defecto) – Si está presente en capacitor.config.* y no existe un canal de force/override/local, la app inicia en este canal (p. ej. beta, qa, pr-123). Destinado a TestFlight / builds internos para que los testers aterricen automáticamente en un canal pre-release. Las builds de producción suelen dejarlo sin configurar.
5. Canal predeterminado de Cloud (ruta principal ~99% de usuarios) – Si marcas un canal predeterminado en el dashboard, todos los usuarios finales normales (sin force, sin override de Dashboard/API, sin canal local del plugin, sin defaultChannel en config) se conectan aquí. Cámbialo para desplegar o revertir al instante, sin un nuevo binario. Si tienes predeterminados específicos por plataforma (por ejemplo, uno solo para iOS, otro solo para Android, otro solo para Electron), cada dispositivo aterriza en el predeterminado que coincide con su plataforma. Dejar el predeterminado en la nube sin configurar está permitido; en ese caso, el dispositivo debe coincidir en los pasos 1–4 para recibir actualizaciones.

Mejor práctica:

• Trata 1–4 como capas de excepción / pruebas; cuando configures un predeterminado en la nube, los usuarios reales deberían fluir hacia él. Si decides no configurar uno, sé deliberado sobre cómo se conectan los usuarios (típicamente vía defaultChannel en config o overrides por dispositivo).
• Configura solo defaultChannel en binarios que envíes explícitamente a testers. Dejarlo sin configurar mantiene la lógica de producción centralizada en el dashboard.
• Usa setChannel() con moderación en producción, principalmente para QA o diagnósticos dirigidos.

Si un canal está deshabilitado para la plataforma (interruptores iOS/Android/Electron) cuando de otro modo sería elegido, el proceso de selección lo omite y continúa por la lista.

Resumen: Force > Dashboard/API Override > Plugin setChannel() canal local > Config defaultChannel > Predeterminado en la nube.

Los overrides de Console y API caducan tras 90 días

Las asignaciones forzadas y las sobrecargas de canales del Dashboard o públicos API se guardan como asignaciones por dispositivo en Capgo. Un trabajo de limpieza elimina esas asignaciones 90 días después de la última escritura de la anulación. Consultar una actualización no reinicia ese contador. Solo volver a escribir la anulación (o eliminarla tú mismo) cambia la marca de tiempo.

Esto no es lo mismo que la retención del inventario de dispositivosEl inventario elimina los dispositivos que no se han conectado a Capgo en 90 días. El override de limpieza elimina el mapeo aunque el dispositivo siga activo.

Para una asignación que no se elimine con esta limpieza:

• Configurar defaultChannel en capacitor.config.* (sobrevive a la reinstalación; requiere un nuevo binario nativo para cambiarlo después).
• Llama a setChannel() de la app. En los plugins 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 y posteriores, esa asignación es local y no se elimina con esta limpieza. En Android e iOS con el updater 8.51.0 y posteriores, persistDefaultChannelOnReinstall por defecto es true, por lo que la asignación solo sobrevivirá a una reinstalación si el sistema operativo restaura los datos de la app y persistDefaultChannelOnReinstall se mantiene true. Usa unsetChannel() para borrarla explícitamente.

La pestaña Dispositivos pestaña y la UI de Override del dispositivo solo listan las asignaciones de consola y públicas de API. No listan todos los dispositivos del canal ni las setChannel() asignaciones.

Aviso de retención de Override en la pestaña Devices del canal.

Comportamiento por defecto del canal

Configurar un default en la nube es opcional, pero suele servir como ruta comodín para dispositivos nuevos. Sin uno, solo los dispositivos que coincidan con mappings forzados, overrides o un defaultChannel en la config de Capacitor recibirán actualizaciones. Cuando decidas marcar defaults, ten en cuenta estos patrones:

• Default único (lo más común) – Si un canal tiene iOS, Android y Electron habilitados, se convierte en el único default; cualquier dispositivo sin overrides se vinculará aquí.
• Valores predeterminados específicos de la plataforma – Si divides los canales por plataforma (por ejemplo, ios-production con solo iOS habilitado, android-production con solo Android habilitado, y electron-production con solo Electron habilitado), marca cada uno como predeterminado para su plataforma. Los dispositivos iOS irán al predeterminado de iOS, los dispositivos Android al de Android, y las aplicaciones Electron al de Electron.

Recuerda que el valor predeterminado de la nube y defaultChannel en capacitor.config.* ambos ocupan la misma capa de decisión. Si configuras un valor predeterminado en la nube, no necesitas duplicar el valor en tu configuración de Capacitor: deja defaultChannel vacío para las compilaciones de producción. Reserva defaultChannel para los binarios que envías intencionalmente a testers o QA cuando quieres que comiencen en un canal no de producción, incluso si el valor predeterminado de la nube es diferente.

Puedes cambiar los valores predeterminados en cualquier momento en el dashboard. Abre el canal y luego Gestionar en Ajustes de la app, lo que te lleva a Información de la app. El valor predeterminado ya no es un interruptor en la página del canal. Cuando cambias un valor predeterminado, los nuevos dispositivos siguen el nuevo enrutamiento de inmediato y los dispositivos existentes siguen las reglas de precedencia normales la próxima vez que se conecten.

Configurar un canal

Durante el onboarding creas el primer canal (la mayoría de los equipos lo llaman “Production”), pero nada queda bloqueado: puedes renombrar o eliminar cualquier canal en cualquier momento. Para añadir canales adicionales más adelante:

1. Ve a la sección “Channels” del dashboard de Capgo
2. Haz clic en el botón “New Channel”
3. Introduce un nombre para el canal y haz clic en “Create”

Los nombres de los canales pueden ser los que quieras. Una estrategia común es alinear los canales con tus etapas de desarrollo, como:

• Development - para probar Live Updates en dispositivos locales o emuladores
• QA - for your QA team to verify updates before wider release
• Staging - para pruebas finales en un entorno similar a producción
• Production - para la versión de tu app que los usuarios finales reciben de las tiendas de aplicaciones

Configurar el canal en tu app

Con tus canales creados, necesitas configurar tu app para que escuche el canal adecuado. En este ejemplo, usaremos el Development canal.

Abre tu capacitor.config.ts (o capacitor.config.json) de archivo. Debajo de la plugins sección, opcionalmente configura defaultChannel para builds de prueba (interno / QA). Para builds de producción, es preferible omitirlo para que los dispositivos usen Cloud Default, a menos que se anule explícitamente.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

A continuación, compila tu app web y ejecuta npx cap sync para copiar el archivo de configuración actualizado a tus proyectos de iOS, Android y Electron. Si omites este paso de sincronización, tus proyectos nativos seguirán usando el canal para el que estaban configurados previamente.

Precaución

Orden de selección de canal: Force > Dashboard/API override de dispositivo > Plugin setChannel() canal local > Config defaultChannel > Cloud por defecto.

Usa defaultChannel solo en builds de prueba/internos; omítelo en producción para que los usuarios sigan el Cloud Default (si está configurado) en lugar de duplicar el enrutamiento en la config nativa.

Aún puedes forzar (fijar) un dispositivo o aplicar un override después; esos valores tienen prioridad inmediata sobre la config.

Channel names are case sensitive.

Opciones y estrategias de canales

Los canales tienen varias opciones que controlan quién puede recibir actualizaciones y cómo se entregan. Las más importantes están a continuación. Puedes configurarlas desde la web app, el CLI o la API pública.

• Canal predeterminado: Marca opcionalmente el canal o los canales específicos de plataforma a los que se conectan los nuevos dispositivos. En la consola, esto se encuentra en App Information (Gestionar en Ajustes de la app de la página del canal). Consulta “Default Channel Behavior” para los escenarios de enrutamiento.
• Filtros de plataforma: Activa o desactiva la entrega a iOS, Android, o Electron dispositivos por canal.
• Deshabilitar auto downgrade en native: Evita enviar una actualización cuando la versión de la app nativa del dispositivo es más reciente que el bundle del canal (por ejemplo, dispositivo en 1.2.3 mientras el canal tiene 1.2.2).
• Permitir builds de desarrollo: Permite actualizar builds de desarrollo (útil para pruebas). CLI: --dev / --no-dev.
• Permitir builds de producción: Permite actualizaciones en builds de producción (store). Actívalo en canales destinados a usuarios reales. CLI: --prod / --no-prod.
• Permitir emuladores: Permite actualizaciones en emuladores/simuladores (útil para testing). CLI: --emulator / --no-emulator.
• Permitir dispositivos físicos: Permite actualizaciones en teléfonos y tablets reales. Déjalo activado para canales de producción. CLI: --device / --no-device.
• Permitir autoasignación de dispositivos: Permite que la app cambie a este canal en runtime usando setChannel. Si está desactivado, setChannel fallará para este canal. CLI: --self-assign / --no-self-assign.
• Formato de descarga: Elige si los dispositivos descargan un zip completo, solo los archivos delta modificados, o lo mejor de ambos (all, zip, delta, zip_from_builtin, delta_from_builtin). Consulta Formato de descarga para el desplegable de la consola y cuándo es útil cada modo.

Despliegues progresivos

Un canal puede mantener un bundle estable mientras expone gradualmente un objetivo de despliegue separado a una cohorte de dispositivos fijos. Puedes pausar, reanudar, promover, revertir y configurar una respuesta automática ante fallos sin cambiar el canal para todos. Ver Despliegues progresivos para el modelo de entrega, el flujo de trabajo del dashboard, los campos de API y los comandos de CLI.

Estrategias para desactivar Auto Update

Usa esto para restringir qué tipos de actualizaciones entregará automáticamente el canal. Opciones:

• major: Bloquea un bundle objetivo cuya versión mayor sea superior a la línea base nativa del dispositivo (version_build). Ejemplo: 1.2.3 -> 2.0.0 se bloquea; 1.2.3 -> 1.9.0 se permite.
• minor: Bloquea un bundle objetivo cuya versión mayor o menor difiera de version_build. Ejemplo: 1.2.3 -> 1.3.0 se bloquea; 1.2.3 -> 1.2.4 se permite.
• patch: Modo más estricto. Bloquea cualquier cambio en el número major, minor o patch. Solo se permiten cambios en el sufijo mientras MAJOR.MINOR.PATCH permanece idéntico. Ejemplos: 1.0.0-beta.1 -> 1.0.0-beta.2 se permite, 1.0.0+build.1 -> 1.0.0+build.2 está permitido, 1.0.0 -> 1.0.1 está bloqueado.
• metadata: Requiere un metadato de versión mínima de actualización en cada bundle. Configúralo mediante CLI usando --min-update-version o --auto-min-update-version. Si falta, el canal se marca como mal configurado y las actualizaciones se rechazarán hasta que se configure.
• none: Permite todas las actualizaciones según compatibilidad semver.

Estas estrategias comparan el bundle objetivo del canal con el baseline nativo enviado como version_build, no con el bundle descargado actual enviado como version_name.

Consulta más detalles y ejemplos en la estrategia Disable updates en /docs/cli/commands/#disable-updates-strategy.

Ejemplo (CLI). El canal ya debe existir (channel set does not create it):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

Uso de setChannel() en tu app

El @capgo/capacitor-updater método setChannel() permite que tu app de Android o iOS cambie de canal programáticamente en runtime. Esto es muy útil para:

• Menús de QA/debug para que los testers cambien de canal
• Flujos de opt-in para programas beta
• Implementaciones de feature flags
• Escenarios de A/B testing

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

Cómo funciona setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Cuando setChannel() se invoca:

1. Validación en el backend (solo lectura): Se envía una petición al backend de Capgo para validar que el canal esté permitido (verificando permisos de autoasignación)
2. Actualización del almacenamiento local: Si la validación es correcta, el canal se guarda en el almacenamiento local del dispositivo como defaultChannel
3. Efecto instantáneo: La siguiente comprobación de actualizaciones usa el nuevo canal de inmediato (sin esperar a la replicación)

Por qué es importante: En versiones anteriores, setChannel() se guardaba la anulación del canal en la base de datos del backend (igual que los cambios hechos desde el Dashboard o con API). Los dispositivos tenían que esperar a la replicación del backend (hasta 2 minutos) para que el cambio de canal surtiera efecto. Ahora, setChannel() solo lee del backend (para validación) y almacena localmente, logrando que el cambio de canal sea instantáneo.

Visibilidad en el Dashboard: Un canal configurado con el plugin no hace que el dispositivo aparezca como Device Override en la interfaz de Capgo. Ahí solo se listan las asignaciones de canal creadas desde el dashboard o desde el API público. Usa el dashboard o API cuando necesites una anulación visible para el admin.

Nota de seguridad: Aunque los permisos de un canal cambien después de configurarlo localmente (por ejemplo, si se desactiva la autoasignación), el backend seguirá validando el canal en cada comprobación de actualizaciones, así que la seguridad se mantiene.

Comparativa de métodos para cambiar de canal:

Método	Tiempo de efecto	Persistido en	Mostrado en la UI de anulación del dispositivo	Expira	Caso de uso
setChannel() del plugin	Instantáneo	Solo dispositivo (local)	No	Sin caducidad automática; se limpia con unsetChannel() (la reinstalación puede conservarlo)	Cambio de canal iniciado por el usuario en la app
Sobrescritura de dispositivo en el dashboard	Hasta 2 min	Base de datos del backend	Sí	90 days after last override write	Admin-initiated changes for specific devices
Asignación de canal de API	Hasta 2 min	Base de datos del backend	Sí	90 days after last override write	Integraciones de backend automatizadas

Para una mejor experiencia de usuario al crear interfaces de cambio de canal, usa siempre el plugin de setChannel() seguro.

Versiones mínimas para el cambio de canal solo local: 5.34.0, 6.34.0, 7.34.0, o 8.0.0 (según tu versión principal). Cada número de versión menor corresponde al mismo conjunto de funciones en todas las versiones principales (p. ej., X.34.0 incluye las mismas funciones ya sea que X sea 5, 6, 7 u 8). Ver instalación del plugin para las etiquetas de versión.

Asignar un bundle a un canal

Para desplegar un live update, necesitas subir un nuevo build de bundle JS y asignarlo a un canal. Puedes hacerlo en un solo paso con el Capgo CLI:

npx @capgo/cli@latest bundle upload --channel=Development

Esto subirá tus assets web compilados y establecerá el nuevo bundle como la build activa para el Development canal. Cualquier app configurada para escuchar ese canal recibirá la actualización la próxima vez que compruebe si hay una.

También puedes asignar builds a canales desde la sección “Bundles” del dashboard de Capgo. Haz clic en el icono de menú junto a una build y selecciona “Asignar al canal” para elegir el canal de esa build.

Versionado de bundles y canales

Es importante tener en cuenta que los bundles en Capgo son globales para tu app, no específicos de cada canal. El mismo bundle puede asignarse a varios canales.

Al versionar tus bundles, recomendamos usar versionado semántico con el Semver Tester de Capgo e identificadores de pre-release para builds específicas de cada canal. Por ejemplo, una versión beta podría versionarse como 1.2.3-beta.1.

En CI, si la versión local ya se subió, usa npx @capgo/cli@latest bundle upload --auto-bump (opcionalmente major, minor, patch/fix, metadata, o ai) para que el CLI se incremente desde el bundle vinculado al canal hasta encontrar un nombre libre. Con ai, Workers AI infiere el nivel mediante el delta entre el manifiesto local y el anterior (si no hay patch una versión Capgo previa). No puedes combinarlo con --bundle. Integración CI/CD y la referencia a CLI.

Este enfoque tiene varias ventajas:

• Comunica claramente la relación entre builds. 1.2.3-beta.1 es obviamente una pre-release de 1.2.3.
• Permite reutilizar números de versión entre canales, reduciendo la confusión.
• Permite tener rutas de rollback claras. Si necesitas hacer un rollback de 1.2.3, ya sabes que 1.2.2 es la versión estable anterior.

Aquí tienes un ejemplo de cómo alinear tus versiones de bundle con una configuración de canales típica:

• Development canal: 1.2.3-dev.1, 1.2.3-dev.2, etc.
• QA canal: 1.2.3-qa.1, 1.2.3-qa.2, etc.
• Staging canal: 1.2.3-rc.1, 1.2.3-rc.2, etc.
• Production canal: 1.2.3, 1.2.4, etc.

Usando semver con identificadores de pre-lanzamiento es un enfoque recomendado, pero no estrictamente obligatorio. La clave es encontrar un esquema de versionado que comunique claramente las relaciones entre tus builds y se alinee con el proceso de desarrollo de tu equipo.

Rollback de un Live Update

Si despliegas un live update que introduce un bug o necesita revertirse, puedes deshacerlo fácilmente volviendo a un build anterior. Desde la sección “Channels” del dashboard:

1. Haz clic en el nombre del channel que quieres revertir
2. Encuentra el build al que quieres volver y haz clic en el icono de corona
3. Confirmar la acción

El build seleccionado volverá a ser el build activo para ese channel de inmediato. Las apps recibirán la versión revertida la próxima vez que busquen una actualización.

Automatización de despliegues

Para flujos de trabajo más avanzados, puedes automatizar tus despliegues de live update como parte de tu pipeline CI/CD. Al integrar Capgo en tu proceso de build, puedes subir nuevos bundles automáticamente y asignarlos a channels cada vez que hagas push a ciertas ramas o crees nuevas releases.

Consulta la Integración CI/CD docs para aprender más sobre la automatización de actualizaciones Capgo.

Previews de PR con privilegios mínimos

Usa una Preview de app clave API cuando la CI necesite un canal temporal por pull request, pero no debe gestionar los canales main/default existentes. La clave permanece vinculada a la organización propietaria y a la app seleccionada; simplemente no tiene un rol a nivel de organización. Cada canal de vista previa no público que cree recibe su propio permiso de ciclo de vida automático y limitado al canal.

1. Que un administrador de la organización cree una clave segura de API limitada a la app de previsualización y seleccione Preview de app. Claves de API.
2. Usa un canal único y no público como pr-123. No pases --default, --self-assign, opciones de rollout o --delete-linked-bundle-on-upload.
3. Sube y promociona el bundle del PR con un solo comando, y luego elimina el canal y el bundle cuando se cierre el PR:

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel crea el canal si falta, sube el bundle y lo promociona en un solo flujo. La limpieza es atómica y verifica la propiedad: la clave solo puede eliminar un canal que haya creado y su bundle vinculado y no compartido. No puede cambiar, promocionar ni eliminar un canal principal/default existente, el canal de otra clave de preview o el bundle de otra clave.

Si los revisores necesitan un QR code o una URL de preview, un administrador debe habilitar las previews una vez para la app:

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

Una clave de App Preview no puede habilitar previews por sí misma porque no tiene permiso de app-settings. En GitHub Actions, ejecuta jobs de preview con secretos en pull_request, no pull_request_target, y restríngelos a PRs del mismo repositorio con github.event.pull_request.head.repo.full_name == github.repository.

Despliegue en un dispositivo

Ahora que entiendes los canales, estás listo para empezar a desplegar actualizaciones en vivo en dispositivos reales. El proceso básico es:

1. Instala Capgo SDK en tu app
2. Configura la app para escuchar el canal deseado
3. Sube un build y asígnalo a ese canal
4. Lanza la app y espera la actualización

Para una guía más detallada, consulta la Despliegue de Live Updates guía. ¡Feliz actualizando!

Uso avanzado de canales: segmentación de usuarios

Los canales no solo sirven para etapas de desarrollo. Son una herramienta potente para la segmentación de usuarios, lo que permite funciones como:

• Feature flags para diferentes niveles de usuarios
• Pruebas A/B
• Despliegues graduales de funciones
• Programas de pruebas beta

Aprende a implementar estos casos de uso avanzados en nuestra guía: Cómo segmentar usuarios por plan y canales para feature flags y pruebas A/B.

Continuar desde Channels

Si estás usando Canales para planificar el enrutamiento de canales y el despliegue gradual, conéctalo con Canales para los detalles de implementación en Channels, Canales para los detalles de implementación en Channels, Solución de beta testing para el flujo de trabajo del producto en Beta Testing Solution, Solución de segmentación por versión para el flujo de trabajo del producto en Version Targeting Solution, y Buenas prácticas de entornos Capgo: Staging con un único App ID móvil para el contexto práctico en Capgo Buenas prácticas de entornos: staging con un solo ID de app móvil.