it
EnglishSvenskaDeutschNederlandsFrançaisEspañolItaliano

Lunover Engineering Notes

Next.js su piu piattaforme: adapter, OpenNext e cosa cambia per i deploy

Next.js 16.2 ha introdotto una Adapter API stabile e una test suite condivisa per i provider di deployment. Ecco cosa significa per i team che rilasciano Next.js su Cloudflare, AWS, Netlify e oltre.

March 30, 2026By LunoverWork with us

Next.js su piu piattaforme: adapter, OpenNext e cosa cambia per i deploy

Se costruisci Next.js da abbastanza tempo, conosci gia la realta:
  • Puoi eseguire un’app Next.js quasi ovunque.
  • E puoi anche perdere accidentalmente meta del valore del framework nel farlo.
Il gap non era “puo girare?” Il gap era il comportamento a piena fedelta tra piattaforme mentre Next.js continuava ad evolvere: streaming, Server Components, middleware/proxy, semantiche di caching, revalidation on-demand, Partial Prerendering e come tutte queste feature interagiscono. Next.js 16.2 e un punto di svolta: introduce una Adapter API stabile, una test suite di correttezza condivisa e un insieme di impegni su come dovrebbe funzionare il supporto alle piattaforme in futuro. Il progetto OpenNext e una parte centrale di come siamo arrivati qui. Come web agency remota in Nepal, questo conta perche la portabilita non e un feature “teorica”. Impatta:
  • quanto sono prevedibili i deploy tra clienti
  • quanta fiducia abbiamo nell’adottare nuove feature Next.js
  • quanta glue code custom dobbiamo mantenere nel tempo
Questo post spiega cosa e cambiato e cosa significa in pratica.

Il problema: “funziona su Vercel” vs “funziona ovunque”

Quando i team dicono “Next.js funziona meglio su Vercel”, di solito stanno descrivendo qualcosa di specifico:
  • il target di deploy capisce l’output di build
  • caching e revalidation si comportano correttamente a scala
  • edge case di streaming e routing sono gia risolti
  • nuove feature arrivano senza rompere l’integrazione con l’host
Su altre piattaforme potevi deployare, ma rischiavi di ricostruire pezzi dell’integrazione da solo:
  • mappare il routing sulle primitive del provider
  • cablare il comportamento di caching
  • rendere corretta la revalidation tra istanze
  • gestire correttamente il comportamento edge di middleware/proxy
E qui che la portabilita storicamente si rompeva: non perche Next.js fosse “chiuso”, ma perche mancava un contratto stabile e documentato su cosa un provider di deploy dovesse implementare.

OpenNext: il ponte di cui l’ecosistema aveva bisogno

OpenNext ha colmato il gap traducendo l’output di build di Next.js in un formato che le piattaforme potevano consumare in modo consistente. In pratica, ha dimostrato qualcosa di importante:
  • l’output di build di Next.js puo essere trattato come un contratto
  • gli adapter possono mappare quel contratto su infrastrutture diverse
  • l’ingrediente mancante era un’API pubblica stabile “a monte”
Una volta chiarito, l’unica mossa sostenibile era standardizzare il contratto upstream.

La Adapter API (perche e diversa da “basta eseguire next start”)

Il cambiamento chiave in 16.2 e una Adapter API stabile: una descrizione tipizzata e versionata dell’output dell’applicazione che gli adapter possono targettare. Concettualmente:
  • Next.js builda l’app ed emette una descrizione di route, asset, runtime target e decisioni di caching/routing.
  • Un adapter consuma quell’output e lo mappa su una piattaforma.
La parte importante: l’adapter non sta piu facendo reverse engineering degli internals di Next.js. Sta leggendo un’interfaccia pubblica progettata per essere stabile.

La test suite condivisa: la portabilita ha bisogno di una barra di correttezza

Senza una test suite condivisa, “supporto” diventa soggettivo. Ogni provider puo dichiarare compatibilita e fallire su edge case che contano:
  • comportamento dello streaming con pattern reali di navigazione
  • interazioni di caching tra istanze
  • revalidation e freschezza dei contenuti
  • comportamento edge di middleware/proxy
La suite condivisa rende la portabilita misurabile:
  • gli autori degli adapter possono eseguire gli stessi test
  • i failure diventano azionabili
  • le regressioni vengono intercettate prima
Cosi eviti “funziona sulla piattaforma A ma si rompe sulla piattaforma B” mentre arrivano nuove feature Next.js.

Adapter verificati e un working group dell’ecosistema

Gli adapter sono come Next.js diventa portabile sul serio, ma serve anche una storia di governance:
  • dove vivono gli adapter “quasi ufficiali”?
  • chi possiede la manutenzione?
  • come si coordinano breaking change?
La direzione qui e lineare:
  • gli adapter possono essere open source e verificati passando la test suite
  • il team Next.js e i provider coordinano i cambi via un working group
  • le breaking change richiedono versioning esplicito
Per i team di ingegneria, e il segnale che “deployare Next.js fuori da Vercel” sta diventando un percorso di prima classe, non un workaround.

Cosa cambia per progetti reali (punto di vista agency)

1. Piu fiducia nell’adottare feature moderne di Next.js

Quando il comportamento tra piattaforme e standardizzato e testato, adottare feature come streaming, Server Components e caching avanzato diventa meno rischioso.

2. Meno glue code custom per cliente

Storicamente, “Next.js portabile” spesso significava fix one-off e integrazione fragile. Con un contratto adapter stabile, piu complessita si sposta dentro:
  • l’adapter (posseduto dal team piattaforma)
  • la test suite condivisa (posseduta dall’ecosistema)

3. Maggiore prevedibilita operativa

Se hai mai debuggato “perche la revalidation qui si comporta diversamente”, sai quanto pesa l’incertezza. Contratti standard e test sono noiosi nel modo migliore: riducono gli incidenti.

Guida pratica: come pensiamo alla scelta piattaforma oggi

La Adapter API non significa “tutte le piattaforme sono uguali”. Significa che la decisione puo basarsi su vincoli reali:
  • dove vuoi eseguire compute (regionale vs globale)
  • quali primitive storage ti servono (KV, object storage, SQL)
  • come vuoi gestire caching e invalidation
  • workflow operativi (log, preview deploy, env, rollback)
Il punto e che non dovresti dover sacrificare il comportamento core di Next.js per fare questa scelta.

Cosa fare adesso

Se stai costruendo un sito Next.js e ti interessa la portabilita, tratta il deployment come parte dell’architettura fin dal giorno uno:
  • definisci esplicitamente il modello di caching e revalidation
  • isola le assunzioni specifiche del runtime
  • aggiungi gate di release QA che verificano HTML renderizzato, metadata e route critiche
Se vuoi aiuto per rilasciare un sito Next.js in produzione con una storia di deploy pulita tra piattaforme:

Related