Fai il deploy di Nuxt su Nodion

Deploy di Nuxt passo dopo passo

1. Tieni gli script predefiniti e il lockfile Fai il commit del lockfile; senza lockfile la build fallisce. I progetti Nuxt non hanno uno script di avvio e non ti serve: Nodion esegue il tuo script build e poi avvia .output/server/index.mjs, che ascolta sulla porta PORT impostata da Nodion. Se aggiungi uno script di avvio, Nodion esegue quello. package.json

   "scripts": {
     "build": "nuxt build",
     "dev": "nuxt dev"
   }

2. Crea l'app Nella dashboard crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea, scegli il branch e la regione EU Central e lascia la strategia di build su Buildpacks.
3. Configura con le variabili NUXT_ Dichiara le impostazioni in runtimeConfig e impostale come NUXT_API_SECRET o NUXT_PUBLIC_API_BASE nella scheda Environment. Nuxt le legge all'avvio del server, quindi non serve il flag Build. Serve solo per i valori che nuxt.config legge da process.env durante la build. nuxt.config.ts

   export default defineNuxtConfig({
     runtimeConfig: {
       apiSecret: "",
       public: {
         apiBase: "",
       },
     },
   });

4. Push e deploy Ogni push sul branch crea una nuova release. Il traffico passa alla nuova release appena / risponde con uno stato 2xx o 3xx. Se / risponde 401 o 404, aggiungi una server route come server/routes/health.ts e imposta /health come percorso di health check nelle impostazioni dell'app.

Da sapere

• Sito statico con nuxt generateNodion non rileva nuxt generate da solo e continua ad avviare il server. Per un sito statico, usa nuxt generate come script build e aggiungi un static.toml con output-dir = ".output/public". Nodion serve allora quella cartella con un server web statico e un fallback su index.html, e basta la dimensione minima.
• Preset di NitroNodion avvia .output/server/index.mjs, che viene generato dal preset predefinito node-server di Nitro. Se nuxt.config o NITRO_PRESET sceglie un preset per un altro hosting, rimuovilo.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Ambienti di anteprima spiegati: un'app per ogni pull request Una copia in esecuzione della tua app per ogni pull request: a cosa servono gli ambienti di anteprima, dove diventano complicati e come li gestisce Nodion.
• Cloud Native Buildpacks: cosa sono e come funzionano I buildpack trasformano il tuo codice sorgente in un'immagine container senza Dockerfile. Cosa sono e come funzionano.

Nuxt su Nodion: domande e risposte