Déployez SvelteKit sur Nodion

Déployez SvelteKit étape par étape

1. Passez d'adapter-auto à adapter-node Exécutez npm i -D @sveltejs/adapter-node, supprimez @sveltejs/adapter-auto et utilisez le nouvel adapter dans votre configuration. Nodion lit l'adapter dans package.json, et la configuration détermine ce que le build génère : changez donc les deux. Dans SvelteKit 3, la configuration se trouve dans les options de sveltekit() dans vite.config.js ; dans SvelteKit 2, c'est kit.adapter dans 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. Commitez le lockfile, sans ajouter de script start Commitez votre lockfile ; sans lui, le build échoue. Nodion exécute votre script build et démarre node build, et adapter-node écoute sur le PORT défini par Nodion. Si vous ajoutez un script start, il remplace cette commande.
3. Définissez l'origine publique Nodion termine le HTTPS en amont de votre app : SvelteKit ne peut donc pas savoir, à partir de la requête, quelle URL utilisent vos visiteurs, et sans elle les envois de formulaires sont rejetés comme requêtes intersites. Dans SvelteKit 3, définissez paths.origin sur votre URL publique, comme dans la configuration ci-dessus ; ce paramètre remplace la variable ORIGIN d'adapter-node. Dans SvelteKit 2, définissez plutôt ORIGIN dans l'onglet Environment, par exemple https://shop.example.com.
4. Variables de build et d'exécution Les valeurs de $env/static/private et $env/static/public sont intégrées au code pendant le build : elles ont donc besoin de l'option Build dans l'onglet Environment. $env/dynamic/private et $env/dynamic/public sont lues pendant l'exécution du serveur et fonctionnent avec des variables normales.
5. Créez l'app et poussez Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea dans la région EU Central. Chaque push construit une nouvelle release, et le trafic bascule vers elle dès que / renvoie un code 2xx ou 3xx. Si / répond 401 ou 404, ajoutez une route comme src/routes/health/+server.js qui renvoie 200 et définissez /health comme chemin de health check.

Bon à savoir

• Sites statiques avec adapter-staticAvec @sveltejs/adapter-static, Nodion sert build/ avec un serveur web statique et un fallback vers index.html. Générez vos pages à l'avance (prerender) avec export const prerender = true dans le +layout.js racine. Pour une app monopage, désactivez-y le SSR et définissez fallback: 'index.html' dans les options de l'adapter, car Nodion a besoin d'un index.html dans build/. Aucun serveur Node.js ne tourne, la plus petite taille suffit donc.
• Un seul adapter dans package.jsonNodion cherche d'abord adapter-static, puis adapter-node. Si les deux sont installés, l'app est construite comme un site statique : supprimez donc l'adapter que vous n'utilisez pas.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Environnements de preview : une app par pull request Une copie de votre app en fonctionnement pour chaque pull request : à quoi servent les environnements de preview, où ils se compliquent et comment Nodion les gère.
• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.

SvelteKit sur Nodion : questions et réponses