Per pubblicare una web app si compila il codice in file statici, li si mette su un host che li serve in HTTPS, si danno all'host i segreti di cui l'app ha bisogno e si punta un nome di dominio verso di esso. Con un creatore di app con IA ci si può fermare al primo passo: è il creatore a pubblicare l'app. Se preferite un altro host, esportate il codice su GitHub e collegate il repository a Vercel o Netlify, oppure fatelo girare su un vostro server.
Questa guida parte da un'app con un backend Supabase, cioè quella che genera Cadrant, il nostro creatore. I prezzi degli host di terze parti non sono riportati: cambiano spesso, quindi controllate le pagine dei fornitori.
I tre modi per pubblicare una web app creata con l'IA
Ci sono tre posti dove ospitare l'app: l'hosting del creatore, un host come Vercel o Netlify, oppure un server che gestite voi. Si distinguono soprattutto per quanto lavoro fate in prima persona.
- L'hosting del creatore. Cliccate su Pubblica e l'app va online su un URL del creatore, o sul vostro dominio. Niente da configurare oltre al dominio. Il codice resta dentro la pipeline del creatore.
- Un host dopo l'esportazione su GitHub. Inviate il codice a un repository GitHub, collegate il repository a un host e l'host compila e pubblica a ogni push. Controllate voi le impostazioni di build e le variabili d'ambiente.
- Un vostro server. Noleggiate una macchina virtuale, installate un server web, copiate i file compilati e gestite certificato e aggiornamenti. È la soluzione che dà più controllo e più lavoro.
| Opzione | Come va online l'app | Cosa gestite voi | Limiti |
|---|---|---|---|
| Hosting del creatore (Cadrant) | Pulsante Pubblica, URL del creatore o vostro dominio | I record DNS del dominio, il progetto Supabase | Legato al creatore: andarsene significa esportare il codice, che su Cadrant richiede il piano Pro |
| Vercel o Netlify | Repository collegato all'host, pubblicazione a ogni push | Repository, impostazioni di build, variabili d'ambiente, DNS, il piano dell'host | Valgono i limiti del piano dell'host, e il codice si modifica in due posti a meno che il creatore non invii su GitHub al posto vostro |
| Un vostro server | Copiate i file compilati su una macchina che gestite voi | Tutto: server, server web, rinnovo del certificato, aggiornamenti di sicurezza, backup, monitoraggio | Tempo. Ha senso per conformità o esigenze particolari, raramente per un primo lancio |
Cosa comporta davvero la pubblicazione
Pubblicare significa quattro cose: una build, la configurazione di cui l'app ha bisogno in esecuzione, un database che resta dov'è e un certificato HTTPS. La prima e l'ultima sono automatiche su qualsiasi host moderno.
La build
Un'app React è scritta in file che un browser non può eseguire direttamente. La fase di build li compila in semplici file HTML, JavaScript e CSS, di solito in una cartella chiamata dist o build. L'host esegue il comando di build (spesso npm run build) e serve quella cartella.
Variabili d'ambiente e segreti
Esistono due tipi di valori, e confonderli è l'errore di lancio più comune. I valori pubblici, come l'URL del progetto Supabase e la sua chiave pubblica (anon), viaggiano dentro l'app e sono pensati per essere visibili. I valori segreti, come una chiave segreta di Stripe o la chiave di un provider di email, non devono mai finire nel codice dell'app né in una variabile che la build espone al browser. Il loro posto è lato server.
In un'app creata con Cadrant, i segreti stanno nella scheda Ambiente del pannello Database e vengono letti dalle edge function di Supabase, quindi non fanno mai parte del bundle del frontend. Vedete la documentazione sulle variabili d'ambiente. Se pubblicate altrove, l'host vi chiede di reinserire solo i valori pubblici; i segreti restano in Supabase. Vercel precisa che ciascuno dei suoi ambienti (anteprima, produzione) può avere variabili proprie, ed è così che si tengono le chiavi di test lontane da quelle reali.
Il database resta su Supabase
Spostare il frontend su un altro host non sposta i dati. Il database, gli account utente e i file restano nel progetto Supabase, che si trova nel vostro account Supabase. Per questo cambiare host richiede pochi minuti e non si perde nulla. Dopo qualsiasi cambio di indirizzo ci sono due cose da fare: aggiungere il nuovo dominio nelle impostazioni Auth e provare l'accesso. La documentazione di Supabase dice che il Site URL, che per impostazione predefinita è localhost, va cambiato con l'URL di produzione, e che gli URL di reindirizzamento formano una lista di consentiti a cui i reindirizzamenti dell'accesso devono corrispondere. Se non lo fate, le email di conferma e di reimpostazione della password puntano al posto sbagliato. I dettagli sono nella guida di Supabase sugli URL di reindirizzamento.
Il certificato HTTPS
I browser sconsigliano ai visitatori i siti senza HTTPS, e senza HTTPS l'accesso non funziona bene. Vercel, Netlify e Cadrant emettono e rinnovano il certificato al posto vostro una volta verificato il dominio. Su un vostro server il certificato lo installate e lo rinnovate voi, di solito con uno strumento di un'autorità di certificazione gratuita, e dovete ricordarvi di mantenere funzionante il rinnovo.
Come collegare un dominio personalizzato
Collegare un dominio significa aggiungere record DNS presso l'azienda dove gestite il dominio, in modo che il nome punti al vostro host. Ogni host indica i record esatti: copiateli così come sono, invece di prenderli da un tutorial.
- Acquistate il dominio se non ne avete uno. Per scegliere nome ed estensione, leggete come scegliere l'estensione del nome di dominio.
- Aggiungete il dominio nelle impostazioni dell'host. L'host mostra allora i record da creare.
- Create quei record presso il vostro provider DNS (il vostro registrar, Cloudflare e così via).
- Aspettate che l'host mostri il dominio come verificato, poi aprite il sito sul dominio e provate l'accesso.
Record A o CNAME
Un record A fa puntare un nome a un indirizzo IP, e un record CNAME fa puntare un nome a un altro nome. La documentazione di Vercel dice che un dominio apex come example.com si configura con un record A e un sottodominio come app.example.com con un record CNAME, e che ogni progetto ha un proprio valore CNAME. Quella di Netlify raccomanda, per il dominio apex, un record ALIAS se il vostro provider DNS lo supporta e altrimenti un record A, più un CNAME per www. I valori cambiano da host a host e da progetto a progetto, quindi usate quelli mostrati nella vostra dashboard.
Dominio apex o www
Il dominio apex (o radice) è example.com, senza niente davanti. Un sottodominio è qualsiasi cosa davanti, come www o app. Nel DNS standard un CNAME non può stare sull'apex, ed è per questo che le configurazioni apex usano record A, ALIAS o ANAME. Netlify raccomanda con decisione di fare di un sottodominio www il dominio principale, perché un apex come principale può penalizzare le prestazioni con alcuni provider DNS. Anche la documentazione di Cadrant dà lo stesso consiglio: preferite un sottodominio come app.mysite.com per evitare i limiti dei domini radice. Aggiungete entrambe le versioni e reindirizzate l'una verso l'altra, così i visitatori raggiungono l'app in ogni caso.
Propagazione del DNS
Una modifica DNS può richiedere da pochi minuti a un giorno o più per raggiungere tutti. La documentazione di Netlify dice di prevedere fino a 48 ore. Controllate l'avanzamento con uno strumento come dnschecker.org o con il comando dig, e cercate vecchi record in conflitto sullo stesso nome: un vecchio record A o CNAME è la causa più frequente di un dominio che non si convalida mai.
Come pubblica Cadrant
Cadrant pubblica dal pulsante Pubblica: scegliete uno slug per un URL Cadrant come your-app.cadrant.app, oppure selezionate un dominio personalizzato aggiunto nella sezione Domini. L'hosting HTTPS e un dominio personalizzato sono inclusi in ogni piano a pagamento, e un'app pubblicata non consuma crediti.
Per un dominio personalizzato, Cadrant mostra tre record DNS da creare presso il vostro registrar: un record TXT che dimostra la proprietà, un CNAME che convalida il certificato e ne consente il rinnovo automatico, e un CNAME per l'instradamento. Per un dominio radice, il record di instradamento richiede un ALIAS o un ANAME se il vostro provider lo supporta. La convalida richiede da pochi minuti a qualche ora; un pulsante Aggiorna rinfresca lo stato. Cliccare di nuovo su Pubblica sostituisce la versione online, e potete annullare la pubblicazione in qualsiasi momento. I passaggi completi sono nella documentazione sulla pubblicazione.
Il limite da conoscere: questo è l'hosting del creatore. Se volete un vostro host, l'esportazione del codice e il push su GitHub sono nel piano Pro. I prezzi sono nella pagina dei prezzi, e il creatore è descritto nella pagina del creatore di app con IA.
Testare su una copia di staging prima di toccare l'app online
Una copia di staging è una seconda pubblicazione dell'app, con un proprio indirizzo e propri dati di prova, dove si verifica una modifica prima che la vedano gli utenti reali. Quando delle persone dipendono dalla vostra app, testate prima lì.
Su un host è già previsto. Vercel crea una pubblicazione di anteprima, con un proprio URL, per ogni branch o pull request, e permette di assegnare un dominio di staging e variabili d'ambiente separate. La sua documentazione afferma che le anteprime non usano le variabili di produzione e che una build di produzione può anche essere tenuta in attesa finché non la promuovete. Netlify offre deploy preview analoghe. Il senso delle variabili separate è avere un progetto Supabase separato per lo staging, così un test non tocca mai i clienti reali.
In un creatore, la copia di staging più semplice è un progetto duplicato collegato a un secondo progetto Supabase, pubblicato su un secondo sottodominio come staging.vostrodominio.com. Modificate e testate lì, poi ripetete la modifica sul progetto online. Costa un posto progetto, e le due copie possono divergere, quindi tenete corta la lista delle modifiche. Applicate prima allo staging le modifiche al database e verificate le policy come spiegato nella nostra guida alla row level security di Supabase.
Come tornare indietro dopo una pubblicazione sbagliata
Fare rollback significa riportare l'app online all'ultima versione che funzionava, ed è rapido solo se la versione precedente è stata conservata. Decidete come farlo prima di averne bisogno.
- In Cadrant. Ogni prompt crea una nuova versione, conservata a tempo indeterminato. Potete visualizzare in anteprima qualsiasi versione passata e ripristinarla. Il ripristino non elimina le versioni successive, quindi si può tornare avanti. Dopo il ripristino, cliccate Pubblica per mettere online quella versione. Il ripristino riporta l'app, non i dati già modificati nel database. Vedete la documentazione sul versionamento.
- Su un host. Gli host conservano le pubblicazioni precedenti e possono riassegnare il dominio di produzione a una più vecchia, oppure annullate il commit in Git e lasciate che l'host ripubblichi.
- Su un vostro server. Tenete la cartella della build precedente accanto a quella attuale e tornate a essa.
Checklist prima del lancio
Prima di dire a chiunque che l'app è online, controllate questi dieci punti. La maggior parte dei problemi di lancio è in questa lista.
Per approfondire la parte di sicurezza, vedete la nostra guida alla sicurezza del vibe coding. Per confrontare cosa sa fare l'app prima di scegliere un creatore, partite dall'elenco dei creatori di app con IA.