Vai al contenuto

Dominio personalizzato

Usa il tuo hostname, ad esempio updates.example.com, per le richieste API di Live Update della tua app, mentre Capgo continua a gestire canali, bundle e rollout.

I domini personalizzati sono disponibili nel piano Enterprise. Gli admin dell'organizzazione possono aggiungere un hostname API di Live Updates nella Console, pubblicare i record DNS forniti e verificarne lo stato di attivazione.

  1. Apri la Console Capgo e seleziona la tua organizzazione.
  2. Vai su Impostazioni → Organizzazione → Generale e trova Dominio personalizzato. Ti serve il permesso per modificare le impostazioni dell'organizzazione e un piano Enterprise attivo per aggiungere un dominio.
  3. Inserisci un hostname come updates.example.com, senza https://, un path o un wildcard.
  4. Clicca su Aggiungi dominio. La Console mostra i record DNS da pubblicare e un In attesa di verifica stato.

Puoi configurare un hostname API per Live Update per organizzazione. Devi avere i permessi per modificare i record DNS.

Se l' Dominio personalizzato opzione non è disponibile, contatta il tuo referente Enterprise o scrivi a support@capgo.app indicando l'organizzazione, gli app ID, l'hostname desiderato e il provider DNS. Contatta il supporto prima del setup se ti serve una regione specifica per la data residency o un hostname personalizzato per il download dei bundle.

Nel tuo provider DNS, aggiungi i record mostrati nella Console o forniti dal supporto. Copia esattamente il tipo di record, il nome e il valore, inclusi il CNAME e i record TXT per la verifica di proprietà o certificato. Clicca su un valore nella Console per copiarlo. Se usi il DNS di Cloudflare, mantieni il CNAME solo DNS a meno che il supporto non confermi un'impostazione diversa.

Usa il target fornito invece di dare per scontato che un CNAME verso plugin.capgo.app sia sufficiente. Mantieni i record DNS attivi finché il dominio è in uso.

Dopo la propagazione del DNS, clicca su Aggiorna stato. La Console mostra Attivo solo quando sia l'hostname che il certificato HTTPS sono attivi; a quel punto offre Copia la configurazione dell'updater. Per una configurazione assistita, contatta il supporto per confermare l'attivazione. Puoi anche ispezionare il DNS e verificare la connettività TLS con:

Finestra del terminale
dig updates.example.com
curl -v https://updates.example.com/updates

Sostituisci updates.example.com con l'hostname fornito. Il curl comando controlla la connettività DNS, TLS e HTTP; una richiesta GET a /updates non è un controllo di aggiornamento valido e potrebbe restituire un errore API. Verifica il flusso di aggiornamento effettivo con un Native Build di test al punto 4.

Una volta che il dominio è attivo, copia la configurazione dell'updater dalla Console e unisci i tre URL in capacitor.config.ts. Per un hostname configurato con i percorsi standard Capgo API, usa:

import type { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
appId: 'com.example.app',
appName: 'My App',
webDir: 'dist',
plugins: {
CapacitorUpdater: {
autoUpdate: 'atBackground',
updateUrl: 'https://updates.example.com/updates',
statsUrl: 'https://updates.example.com/stats',
channelUrl: 'https://updates.example.com/channel_self',
},
},
};
export default config;

Sostituisci gli URL di esempio con quelli esatti mostrati nella Console o confermati dal supporto. Mantieni le impostazioni dell'app e le altre opzioni dei plugin.

ImpostazioneScopo
updateUrlVerifica la disponibilità di un bundle.
statsUrlRiporta le statistiche degli update.
channelUrlGestisce le operazioni sui channel del dispositivo.

Sincronizza la configurazione nei tuoi progetti nativi:

Finestra del terminale
npx cap sync

Compila e installa una versione nativa di test, quindi:

  1. Carica un bundle di test su un canale di test usando il tuo normale workflow Capgo.
  2. Controlla i log del dispositivo nativo per verificare che le richieste di update raggiungano il tuo hostname personalizzato e che il bundle venga scaricato e installato correttamente.
  3. Conferma che le statistiche degli update compaiano nella Console e prova le operazioni del canale se la tua app le utilizza.
  4. Rilascia una nuova versione nativa dell'app tramite il tuo consueto processo di distribuzione sugli store.

Le vecchie installazioni native continueranno a usare gli endpoint URL configurati finché gli utenti non installeranno la nuova versione nativa. L'hostname predefinito dell'updater è plugin.capgo.app, che viene gestito da Capgo. Se stai migrando da un altro custom hostname sotto il tuo controllo, mantieni attivi i record DNS e il servizio finché quegli utenti non si saranno migrati. Channels, bundle upload e rollback continueranno a usare la tua normale Capgo Console e il workflow CLI.

Per rimuovere un dominio, usa Rimuovi dominio → Conferma rimozione nelle impostazioni dell'Organization. Prima rilascia una versione nativa dell'app usando gli endpoint sostitutivi e permetti agli utenti di migrare: le vecchie installazioni perderanno l'accesso tramite l'hostname rimosso. Rimuovi il dominio prima di eliminare la relativa organization.

  • Il DNS non risolve: verifica il nome del record e il target rispetto ai valori forniti dal supporto, e controlla la propagazione con il tuo provider DNS.
  • HTTPS fallisce: chiedi al supporto di verificare l'attivazione dell'hostname e il provisioning del certificato prima di rilasciare il Native Build.
  • Le richieste usano ancora plugin.capgo.app: conferma tutti e tre gli URL, esegui npx cap sync, ricostruisci e installa la nuova versione nativa.
  • Il download del bundle usa un altro hostname: la risposta dell'update fornisce l'URL di download. Chiedi al supporto informazioni sulla consegna di bundle personalizzati, o consulta Storage personalizzato se preferisci gestire autonomamente lo storage dei bundle.
  • Updates fail despite valid HTTPS: condividi l'app ID, il canale, la versione native, il timestamp della richiesta e i log native con il supporto di Capgo.

Vedi Impostazioni Updater per il riferimento completo alla configurazione e Ubicazione dati per i requisiti degli endpoint regionali.