Serverpod App Studio è un ambiente di sviluppo per app Flutter, in beta pubblica su macOS dal 14 settembre 2026. Fa una scelta controcorrente: non ha nessuna intelligenza artificiale propria. Porti l'agente di coding che usi già (Claude Code, Cursor o Antigravity) e lui ti dà il resto: ambiente completo, backend, database e un server MCP che fa leggere all'agente i log dell'app mentre gira. Lo firma Serverpod, startup svedese guidata da Viktor Lidholt, ex ingegnere del team Flutter di Google. Lo stesso giorno sono usciti anche Serverpod 4 e il servizio di hosting Serverpod Cloud.
Sviluppo app e web app per clienti da più di dieci anni, quasi sempre con Laravel o Node dietro e React davanti. Non sono un utente Flutter quotidiano. Proprio per questo il lancio mi ha incuriosito. Dopo un anno di app builder che promettono di fare tutto con un prompt, arriva uno strumento che dice il contrario: l'AI la scegli tu, il valore sta nell'infrastruttura sotto.
In questo articolo ti spiego cosa contiene davvero Serverpod App Studio, cosa cambia con Serverpod 4, cosa dice la licenza (e dove non è open source) e in quali progetti lo prenderei in considerazione.
Cos'è Serverpod App Studio e cosa contiene
Serverpod App Studio è un'applicazione desktop da scaricare. Dentro c'è tutto quello che serve per creare ed eseguire un progetto Flutter e Serverpod, senza installare a mano Flutter, Dart, Xcode o gli SDK. Il flusso descritto da Serverpod è breve: si scarica, si apre con un doppio clic, si collega l'agente AI preferito, si costruisce.
Il pacchetto include due pezzi che fanno la differenza rispetto a un semplice installer:
- Agent skills: istruzioni pronte che spiegano all'agente come si lavora con Serverpod, i modelli dati, gli endpoint, le convenzioni. In pratica trasformano un agente generico in uno che conosce il framework.
- Server MCP: il protocollo con cui un agente si collega a strumenti esterni. Qui è collegato all'ambiente in esecuzione. L'agente legge i log del server e dell'app mentre girano e capisce cosa succede davvero, invece di indovinarlo dal codice.
La beta è solo per macOS, con un pacchetto arm64 (versione 0.1.2 al momento in cui scrivo). Serve quindi un Mac con chip Apple. Per Windows Serverpod parla di uscita "prossimamente".
Non c'è un formato progetto speciale. Quello che costruisci con Serverpod App Studio è un normale progetto Flutter e Serverpod. Si apre anche da altri editor, se un giorno vuoi installare l'ambiente tradizionale.
Serverpod 4: l'hot reload che attraversa tutto lo stack
Il motore di Serverpod App Studio è la novità principale di Serverpod 4. Il comando serverpod start avvia insieme backend, database e app Flutter e li tiene allineati. Cambi un modello dati? Serverpod rigenera il codice e aggiorna il database. Aggiungi un endpoint? Il server già in esecuzione lo raccoglie. Tocchi l'interfaccia? L'app si aggiorna. Nella maggior parte dei casi lo stato di app e backend si conserva durante il ricaricamento.
Chi ha lavorato con Flutter conosce il valore dell'hot reload lato client. Estenderlo a backend e database è la parte che mi ha colpito di più. È esattamente il ciclo in cui un agente AI rende meglio: cambia una cosa, vede il risultato subito, corregge. Con uno stack tradizionale quel ciclo si allunga tra migrazione, riavvio del server e ricarica del client, e l'agente perde il filo.
Postgres incorporato e niente Docker in sviluppo
Il database locale è un Postgres incorporato. In sviluppo non serve più Docker: crei il progetto, lanci il comando e il database c'è. Anche dart test gira senza un database separato. In produzione Serverpod continua a collegarsi a un Postgres esterno. Il database embedded serve solo a semplificare il ciclo locale.
Sincronizzazione offline (sperimentale)
La funzione più giovane è la sincronizzazione offline, marcata come sperimentale nella 4.0. Aggiungi database: sync a un modello e l'app Flutter tiene una copia locale in SQLite. La sincronizza in entrambe le direzioni con il backend, con aggiornamenti in tempo reale grazie alle API di streaming. Serverpod ci ha lavorato diciotto mesi e prevede di renderla stabile nella 4.1. Per app critiche io aspetterei quella.
Sono oltre 100 le novità accumulate dalla versione 3: modelli condivisi in un pacchetto Dart separato, future call dichiarate come normali metodi, autenticazione con email, Google, Apple, Facebook, GitHub, Microsoft e Firebase, storage esteso.
Perché l'AI resta fuori da Serverpod App Studio
La scelta di non avere un modello proprio è la più discussa del pacchetto, ed è quella che condivido di più. Serverpod dichiara di aver testato la configurazione di default con Antigravity, Cursor e Claude Code. Il vantaggio pratico per chi sviluppa è che si cambia agente senza toccare lo stack. Il costo dell'abbonamento all'agente resta separato.
La tesi di Lidholt è questa. Quando un'app nata da un prompt comincia a crescere, saltano fuori le magagne: sicurezza, controlli di accesso mancanti, database non ottimizzati. A quel punto serve un progetto che un ingegnere possa aprire, leggere e correggere. È la stessa cosa che vedo quando un cliente mi porta un'app "fatta con l'AI" da sistemare. Il problema non è mai il prompt, è che sotto non c'è un'architettura.
Ho fatto una scelta simile quando ho costruito un'app su un motore agentico. Ho preferito un agente minimale come Pi a cui aggiungere strumenti, invece di un prodotto chiuso con l'AI dentro. Il ragionamento di Serverpod App Studio è lo stesso, applicato a Flutter.
Il rovescio della medaglia: la qualità del risultato dipende da un agente che Serverpod non controlla. Se Claude Code o Cursor cambiano prezzi, limiti o consumi di token, il conto lo sente chi sviluppa. Ne ho scritto a proposito dei prezzi di Claude Opus 5.5: l'agente è una voce di costo che si muove.
Serverpod vs Supabase e Firebase: dove si colloca
La domanda che leggo più spesso è "qual è il miglior backend per Flutter". La risposta onesta è che Serverpod gioca in una categoria diversa da Supabase e Firebase.
- Firebase e Supabase sono backend-as-a-service: ti danno database, autenticazione e storage pronti, con SDK Flutter. Scrivi poco codice lato server. In cambio dipendi dal fornitore e la logica di business finisce spesso nel client o in funzioni serverless.
- Serverpod è un framework: il backend lo scrivi tu, in Dart, con lo stesso linguaggio dell'app. Ottieni tipizzazione end-to-end dal database a Flutter, codice generato per client ed endpoint, e un server che puoi ospitare dove vuoi.
- Dart Frog, l'altro nome che gira, è più leggero: un framework HTTP minimale in Dart, senza ORM, code generation o sincronizzazione. Va bene per API semplici, non è un backend completo.
Sulla produzione, Serverpod dichiara di essere usato da startup, agenzie, banche, aziende mediche e governi, con oltre mille nuovi progetti al mese. Non ho verificato questi numeri sul campo. Ma la versione 3 era dedicata proprio a sicurezza, autenticazione e robustezza, e la 4 ci costruisce sopra. Per un backend Dart che deve crescere, oggi è la scelta più completa.
Serverpod Cloud: il conto parte da 5 dollari
Serverpod Cloud è la piattaforma di hosting costruita per i progetti Serverpod. Con un comando, da terminale o da una pipeline CI, compila l'app, esegue le migrazioni, configura l'infrastruttura e mette online la nuova versione. Gestisce server, Postgres, domini con certificati e storage dei file. Include Serverpod Insights per monitorare CPU e memoria.
Il piano Starter costa 5 dollari al mese, comprende Postgres e CDN, e c'è un mese di prova gratuito senza carta di credito. Serverpod dice di averlo testato fino a 5.000 richieste al minuto.
Chi non vuole il Cloud può ospitare il backend dove preferisce. Io, per esempio, metterei tutto sui miei server Hetzner con Coolify, come faccio per il resto dei progetti. Postgres e un server Dart sono standard.
Open source sì, ma con un asterisco sulla licenza
Serverpod descrive framework e App Studio come gratuiti e open source. La realtà è a due velocità:
| Componente | Licenza | Cosa comporta |
|---|---|---|
| Pacchetti client e condivisi (serverpod_client, serverpod_shared) | BSD-3-Clause | Uso libero nelle proprie app, anche commerciali |
| Pacchetto server serverpod (4.0.1) | SSPL v1 | Uso e self-hosting liberi; chi lo offre come servizio a terzi deve rilasciare il codice del servizio |
| App Studio | Dichiarato gratuito e open source | Scaricabile gratis; il sorgente non risulta nel repository principale |
| Serverpod Cloud | Servizio commerciale | Piano Starter da 5 dollari al mese |
La SSPL è nata nel 2018 per proteggere MongoDB dai fornitori cloud e non è approvata dall'Open Source Initiative. Il suo articolo 13 obbliga chi offre il programma come servizio a rilasciare il codice dell'intero servizio con la stessa licenza. Il README di Serverpod delimita il campo: puoi ospitare il tuo server senza limiti, purché non venda Serverpod come servizio cloud a terzi.
Per un'app, un'agenzia o un'azienda che usa Serverpod dietro le proprie API non cambia nulla. Cambia se qualcuno pensa di rivendere un "Serverpod gestito". A rigore, open source è solo la parte BSD-3. Il core del server è consultabile e modificabile, ma con una licenza che l'OSI non riconosce. È un dettaglio che nei preventivi ai clienti io metto per iscritto.
Si può usare in Europa? La domanda che i clienti mi fanno
Il framework e Serverpod App Studio si possono usare in Europa senza restrizioni geografiche. Sede a Stoccolma, self-hosting libero, nessuna delle due licenze vieta l'uso nell'Unione europea. Il punto aperto riguarda Serverpod Cloud.
Nelle pagine ufficiali che ho consultato (blog, pagina di App Studio, documentazione) non compaiono le regioni dei data center né un DPA. Il DPA è il Data Processing Agreement che il GDPR richiede quando un fornitore tratta dati personali per conto di un'azienda. Chi deve ospitare dati di utenti europei ha due strade: chiedere a Serverpod regione e DPA prima di firmare, oppure ospitare il backend su un provider europeo. Per i miei clienti sceglierei la seconda senza pensarci.
C'è poi il capitolo agenti. Il codice e i dati che App Studio passa all'agente scelto seguono le regole del suo fornitore. Vale quello che ho scritto sulla differenza tra Claude Cowork e Claude Code: cosa esce dalla macchina lo decide l'agente, non l'ambiente.
Quando userei Serverpod App Studio (e quando no)
Non cambierò stack per Serverpod App Studio. Ci sono però tre situazioni in cui lo metterei sul tavolo con un cliente:
- App mobile nativa con backend semplice, che oggi farei con Flutter più un backend separato. Avere tutto in Dart, con un unico ciclo di hot reload e un solo linguaggio, riduce le persone e i contesti da tenere allineati.
- Prototipo da far crescere. Il progetto resta un progetto Flutter e Serverpod standard. Il lavoro fatto con l'agente non va buttato quando arriva il momento di fare sul serio. È l'opposto degli app builder che producono web app chiuse.
- Team piccolo che usa già un agente. Se hai Claude Code o Cursor in abbonamento, App Studio non aggiunge costi e ti toglie mezza giornata di configurazione.
Lo eviterei invece in tre casi: se ti serve Windows oggi, se vuoi mettere in produzione la sincronizzazione offline (ancora sperimentale), o se devi ospitare dati di utenti europei su Serverpod Cloud senza regioni dichiarate. E vale la regola che applico a tutto ciò che nasce attorno agli agenti: nessun codice in produzione che non riesco a spiegare riga per riga.
Per molti progetti che mi arrivano, poi, un'app nativa non serve affatto. Una web app ben fatta copre il caso d'uso a una frazione del costo e senza store da gestire. Se stai valutando un'app e non sai se ha senso Flutter, un'altra tecnologia cross-platform o una web app, ho messo nero su bianco quanto costa davvero sviluppare un'app nel 2026.
Se invece vuoi un parere sul tuo progetto specifico, scrivimi. Rispondo io, e la prima chiacchierata serve a capire se ti serve un'app o basta un sito.
