Fai il deploy di SvelteKit su Nodion

Deploy di SvelteKit passo dopo passo

1. Passa da adapter-auto ad adapter-node Esegui npm i -D @sveltejs/adapter-node, rimuovi @sveltejs/adapter-auto e usa il nuovo adapter nella tua configurazione. Nodion legge l'adapter dal package.json, mentre la configurazione decide cosa scrive la build, quindi cambia entrambi. In SvelteKit 3 la configurazione si trova nelle opzioni di sveltekit() in vite.config.js; in SvelteKit 2 è kit.adapter in svelte.config.js. vite.config.js (SvelteKit 3)

   import adapter from "@sveltejs/adapter-node";
   import { sveltekit } from "@sveltejs/kit/vite";
   import { defineConfig } from "vite";
   
   export default defineConfig({
     plugins: [
       sveltekit({
         adapter: adapter(),
         paths: { origin: "https://shop.example.com" },
       }),
     ],
   });

2. Fai il commit del lockfile, niente script di avvio Fai il commit del lockfile; senza lockfile la build fallisce. Nodion esegue il tuo script build e avvia node build, e adapter-node ascolta sulla porta PORT impostata da Nodion. Uno script di avvio, se lo aggiungi, sostituisce quel comando.
3. Imposta l'origine pubblica Nodion termina HTTPS a monte della tua app, quindi dalla richiesta SvelteKit non può capire quale URL usano i tuoi visitatori, e senza questa informazione l'invio dei form viene rifiutato come cross-site. In SvelteKit 3, imposta paths.origin sul tuo URL pubblico come nella configurazione qui sopra; sostituisce la variabile ORIGIN di adapter-node. In SvelteKit 2, imposta invece ORIGIN nella scheda Environment, per esempio https://shop.example.com.
4. Variabili di build e di runtime I valori di $env/static/private e $env/static/public vengono inseriti nel codice durante la build, quindi hanno bisogno del flag Build nella scheda Environment. $env/dynamic/private e $env/dynamic/public vengono letti mentre il server è in esecuzione e funzionano con le variabili normali.
5. Crea l'app e fai push Nella dashboard crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea nella regione EU Central. Ogni push crea una nuova release, e il traffico passa alla nuova release appena / risponde con uno stato 2xx o 3xx. Se / risponde 401 o 404, aggiungi una route come src/routes/health/+server.js che restituisca 200 e imposta /health come percorso di health check.

Da sapere

• Siti statici con adapter-staticCon @sveltejs/adapter-static, Nodion serve build/ con un server web statico e un fallback su index.html. Fai il prerender delle pagine con export const prerender = true nel +layout.js alla radice. Per una single-page app, disattiva lì l'SSR e imposta fallback: 'index.html' nelle opzioni dell'adapter, perché Nodion ha bisogno di un index.html in build/. Non gira nessun server Node.js, quindi basta la dimensione minima.
• Un solo adapter nel package.jsonNodion cerca prima adapter-static, poi adapter-node. Se sono installati entrambi, l'app viene compilata come sito statico, quindi rimuovi l'adapter che non usi.

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.
• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.

SvelteKit su Nodion: domande e risposte