Cursor Build Live Apps: cosa offre, quanto costa e quali limiti ha

Quante app valide restano bloccate su localhost? Cursor punta a risolvere proprio questo problema con Build Live Apps, rilasciato il 5 novembre. Dopo aver esaminato il changelog, la documentazione e le prime domande degli utenti, il verdetto è questo: ottimo per tool interni e prototipi protetti da Cursor SSO, ancora prematuro per backend di produzione complessi o soggetti a requisiti di conformità.

Come funziona Cursor Build Live Apps

Build Live Apps è un flusso basato su cloud agent che trasforma una richiesta in linguaggio naturale in una web app già distribuita. Cursor ha annunciato la funzione il 5 novembre 2026 nel changelog; la documentazione di Apps descrive lo stesso percorso: si dà un prompt al cloud agent, si controlla l'anteprima nel tray, si sceglie un URL, si superano i controlli di sicurezza e infine si pubblica un link live.

Il prompt deve essere esplicito. La documentazione Cursor indica di chiedere all'agente di build an app. Si può partire da zero con Cursor Origin, che crea un nuovo repository, oppure da un repository esistente su GitHub, che Cursor provvede a distribuire. Solo i cloud agent possono creare app.

Quando serve persistenza, Cursor crea un database PostgreSQL. L'hosting viene eseguito in un account di hosting dedicato e isolato per ogni utente o team. Per le app di team, l'autenticazione è affidata a Cursor SSO: chi riceve il link deve quindi accedere a Cursor prima di aprire l'app. Gli utenti dei piani individuali possono anche pubblicare app pubbliche senza richiesta di accesso.

Ci sono limiti da considerare fin dal primo giorno. Il supporto GitLab è previsto, ma non ancora disponibile. I domini personalizzati non sono confermati. Cursor afferma che chi pubblica sceglie un dominio univoco e la documentazione aggiunge che l'URL può essere modificato in seguito, ma nessuna delle due pagine illustra una procedura per collegare un dominio personalizzato.

Nessuna pagina specifica framework, runtime, regioni, versione di Postgres, backup, comportamento di scalabilità, quote di banda o SLA. L'hosting è legalmente separato dai servizi Cursor ed è fornito "as is" e "as available"; Cursor si riserva inoltre il diritto di revocare o sospendere un sottodominio o un'app.

Pubblicazione protetta: 4 controlli obbligatori e revisione AI

Niente viene esposto online senza una pubblicazione esplicita da parte dell'utente. La sola fase di preparazione non rende accessibile l'app. A ogni pubblicazione vengono eseguiti quattro controlli obbligatori, che restano attivi anche se il team disabilita la revisione AI separata:

• Blocco della pubblicazione se i file dell'app contengono una chiave API o un token di accesso.
• Blocco dei file di credenziali, come chiavi private o chiavi di service account.
• Esclusione dei file .env dal bundle pubblicato.
• Rimozione delle source map, così i visitatori non possono ricostruire il sorgente originale dal browser.

Se un controllo fallisce, Cursor mostra il problema; l'utente può chiedere all'agente di correggerlo e riprovare.

La revisione di sicurezza AI aggiuntiva legge i file dell'applicazione e può bloccare problemi gravi prima della pubblicazione. Gli amministratori del team possono aggiungere istruzioni specifiche dell'organizzazione al prompt di revisione. Le istruzioni personalizzate possono introdurre regole, ma non eliminare né indebolire i controlli integrati di Cursor. Gli amministratori possono ignorare alcuni blocchi di pubblicazione, ma non quelli relativi a codice malevolo, segreti hardcoded o credenziali esposte. Le modifiche a queste impostazioni compaiono nel log di audit del team.

Ciò che questo filtro non dimostra conta più di ciò che riesce a intercettare:

"Il punto è che superare i controlli di sicurezza non dimostra che l'app conceda alle persone giuste gli accessi giusti." — @0node0, utente reale

Cursor cita come esempi i segreti e le credenziali esposte. Non afferma però che ogni app riceva test di autorizzazione, verifiche dei permessi a livello di riga, copertura contro SQL injection, scansione delle dipendenze o una revisione della logica di business. Anche l'analisi di TechRepublic del 6 novembre arriva alla stessa conclusione: bisogna testare con più account e diversi livelli di autorizzazione, perché non è dimostrato che sia coperto il caso di un utente autenticato che legge i record di un altro.

Le tre domande più comuni: prezzo, Vercel e segreti

L'hosting costa a parte? Cursor non ha pubblicato un prezzo separato per hosting o database. Build Live Apps non ha un abbonamento autonomo: è incluso nei piani a pagamento che danno accesso ai cloud agent. Le cifre disponibili arrivano dalla tabella dei piani di TechRepublic, non dalle pagine della funzione di Cursor:

Cursor usa una quota settimanale condivisa per l'utilizzo dell'AI (riepilogo dei piani di TechRepublic), ma su queste pagine non pubblica numeri relativi a token, richieste o capacità di calcolo per fascia. I modelli di terze parti possono comportare costi separati (TechRepublic). Restano ignoti i limiti per database, storage, traffico e concorrenza. Considerate i $30 come la soglia di ingresso, non come il costo operativo totale, e verificate le quote prima di mettere un carico rivolto ai clienti sull'hosting integrato.

Build Live Apps sostituisce Vercel? Non ancora, se parliamo di backend di produzione complessi o sensibili alla conformità. Il percorso integrato è adatto a Postgres, SSO e un link da condividere. Il flusso tradizionale, da GitHub a Vercel, Netlify, Railway, Render o un VPS, resta la scelta per architetture personalizzate e dati regolamentati; la tabella seguente distingue nel dettaglio gli scenari. Nelle discussioni Reddit sull'hosting ricorre sempre lo stesso criterio: a decidere l'host è quanto il carico sia stateful o di lunga durata.

"La maggior parte delle demo di Cursor che vedo nella mia timeline è concentrata sulla UI… e quasi nessuna è distribuita a veri utenti paganti." — @mayowaoshin, utente reale

Dove risiedono i segreti e l'agente li vede? La documentazione di Cursor afferma che l'agente di coding non vede mai i valori dei segreti. Se un'app ha bisogno di un data warehouse o di un'API esterna, Cursor chiede all'utente i segreti necessari. Di norma, i segreti del team vengono creati da un amministratore nella dashboard Apps, oppure aggiunti in seguito dalla stessa dashboard.

Gli amministratori del team possono vedere ogni app e ogni segreto del team. È un elemento utile di governance, ma anche un confine di fiducia da comprendere prima di incollare chiavi di produzione. Client automatizzati come script, job CI e Grok Bot accedono alle app protette tramite una chiave nell'header (x-cursor-app-token), non tramite cookie o parametri query.

Quando scegliere Live Apps e quando restare sul deploy classico

Il percorso tradizionale conserva comunque il proprio lavoro di configurazione: setup MCP, credenziali di hosting, variabili d'ambiente e hardening RLS, come mostra il percorso di quattro settimane di un builder, dalla landing page a Vercel e all'autenticazione Supabase.

Checklist prima della prima condivisione

I controlli di Cursor intercettano segreti esposti e file di credenziali. Restano però i rischi legati a permessi, configurazione degli ambienti, effetti collaterali asincroni e codice che nessuno ha letto. Seguite questa lista prima della prima condivisione, anche per un tool interno.

1. Ricostruite da zero, poi leggete il diff. Chiedete all'agente di eseguire la build reale di produzione, non il server di sviluppo. Aprite ogni file modificato relativo a pagamenti, autenticazione e scritture sui dati. Se il progetto è già cresciuto oltre il punto in cui il diff è revisionabile, ripristinate un checkpoint e dividete il lavoro invece di continuare a dare prompt nel caos.
2. Testate i permessi con due account. Accedete come amministratore e come membro con privilegi limitati. Create un record come utente A e provate a leggerlo, modificarlo ed eliminarlo come utente B. Un report di sicurezza superato non dimostra che la proprietà a livello di riga sia corretta.
3. Verificate i segreti da un capo all'altro. Controllate che nessuna chiave sia inclusa nel codice frontend, che non sia stato pubblicato alcun .env e che ogni credenziale esterna disponga dello scope minimo necessario. Rimuovete gli URL diretti del database di produzione dall'ambiente raggiungibile dall'agente. Un post su r/cursor descrive Cursor che distribuisce direttamente su Supabase in produzione anziché passare da GitHub.
4. Mettete alla prova i flussi asincroni. Inviate un webhook reale, ripetetelo e interrompetelo a metà esecuzione. Verificate il comportamento del connection pool sotto uso concorrente. Webhook che falliscono silenziosamente e pool esauriti sono problemi che gli utenti riferiscono di scoprire solo dopo il lancio.
5. Definite aggiornamenti e rollback. Stabilite chi può pubblicare, chi può ignorare un blocco, chi può ritirare un'app e dove finisce il log di audit. Documentate come ripristinare una pubblicazione errata e come eseguire una migrazione dello schema, perché la documentazione descrive la pubblicazione ma non lo storico delle versioni né il rollback.

"Quando un'app lascia localhost, i suoi segreti vanno con lei." — @1PasswordDev, utente reale sull'isolamento dei segreti per app

Se una qualsiasi delle voci precedenti non ha risposta, ad esempio perché manca un progetto di staging, un secondo account di test o un rollback, mantenete l'app su un link riservato al team o sullo stack tradizionale finché non li avrete.

FAQ

Build Live Apps richiede un piano Cursor a pagamento?

Sì. Build Live Apps funziona soltanto sui piani a pagamento con cloud agent abilitati. Plus da $8/month non è idoneo. Premium da $30/month è il piano individuale idoneo più economico.

Cursor può creare un'app dal mio repository esistente?

Sì, da un repository GitHub esistente oppure da zero su Cursor Origin. GitLab è previsto ma non disponibile, e gli agent locali non possono creare app.

Un'app di team può essere pubblica?

I piani Team ed Enterprise disabilitano per impostazione predefinita la condivisione pubblica. Un amministratore può abilitarla dalla dashboard Apps. I piani individuali possono pubblicare direttamente app pubbliche.

Cursor supporta i domini personalizzati?

Cursor afferma che chi pubblica sceglie un dominio univoco e può modificarlo in seguito, ma né il changelog né la documentazione confermano il collegamento di domini personalizzati. Finché Cursor non documenterà diversamente, assumete di usare un URL gestito da Cursor.

Come accedono script o bot a un'app privata?

Provisionate una chiave API Cursor e inviatela a ogni richiesta nell'header x-cursor-app-token. Le chiavi personali aprono tutto ciò che può aprire il proprietario. Le chiavi del team aprono solo le app del team a cui è stato concesso esplicitamente l'accesso.

Cosa accade dopo aver ritirato la pubblicazione di un'app?

Gli amministratori possono ritirare la pubblicazione di qualsiasi app del team; disabilitando le app pubbliche, quelle già pubbliche tornano visibili soltanto al team. Cursor non documenta il comportamento di conservazione, backup o esportazione dei dati dopo la rimozione dalla pubblicazione.

Build Live Apps elimina la configurazione di hosting che separa un prototipo funzionante da un link utilizzabile. Non elimina però il lavoro di revisione, test dei permessi e definizione delle responsabilità che stabilisce se il risultato possa essere usato in sicurezza da altre persone.

Approfondimenti correlati: Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained