Déployez Nuxt sur Nodion

Déployez Nuxt étape par étape

1. Gardez les scripts par défaut et un lockfile Commitez votre lockfile ; sans lui, le build échoue. Les projets Nuxt n'ont pas de script start, et vous n'en avez pas besoin : Nodion exécute votre script build puis démarre .output/server/index.mjs, qui écoute sur le PORT défini par Nodion. Si vous ajoutez un script start, Nodion exécute celui-ci à la place. package.json

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

2. Créez l'app Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea, choisissez la branche et la région EU Central, et laissez la stratégie de build sur Buildpacks.
3. Configurez avec les variables NUXT_ Déclarez vos paramètres dans runtimeConfig et définissez-les comme NUXT_API_SECRET ou NUXT_PUBLIC_API_BASE dans l'onglet Environment. Nuxt lit ces variables au démarrage du serveur : elles n'ont donc pas besoin de l'option Build. Seules les valeurs que nuxt.config lit dans process.env pendant le build en ont besoin. nuxt.config.ts

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

4. Poussez pour déployer Chaque push sur la branche construit une nouvelle release. Le trafic bascule vers elle dès que / renvoie un code 2xx ou 3xx. Si / répond 401 ou 404, ajoutez une route serveur comme server/routes/health.ts et définissez /health comme chemin de health check dans les paramètres de l'app.

Bon à savoir

• Site statique avec nuxt generateNodion ne détecte pas nuxt generate tout seul et continue de démarrer le serveur. Pour un site statique, faites de nuxt generate votre script build et ajoutez un static.toml avec output-dir = ".output/public". Nodion sert alors ce dossier avec un serveur web statique et un fallback vers index.html, et la plus petite taille suffit.
• Preset NitroNodion démarre .output/server/index.mjs, que génère le preset par défaut de Nitro, node-server. Si nuxt.config ou NITRO_PRESET choisit un preset destiné à un autre hébergeur, supprimez-le.

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.
• Les Cloud Native Buildpacks expliqués Les buildpacks transforment votre code source en image de conteneur sans Dockerfile. Ce qu'ils sont et comment ils fonctionnent.

Nuxt sur Nodion : questions et réponses