Deploy Nuxt op Nodion

Nuxt stap voor stap deployen

1. Behoud de standaardscripts en een lockfile Commit je lockfile; zonder lockfile mislukt de build. Nuxt-projecten hebben geen startscript, en je hebt er ook geen nodig: Nodion voert je build-script uit en start daarna .output/server/index.mjs, dat luistert op de PORT die Nodion instelt. Voeg je een startscript toe, dan voert Nodion dat uit. package.json

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

2. Maak de app aan Maak in het dashboard een applicatie aan vanuit je GitHub-, GitLab-, Bitbucket- of Gitea-repository, kies de branch en de regio EU Central en laat de buildstrategie op Buildpacks staan.
3. Configureer met NUXT_-variabelen Declareer je instellingen in runtimeConfig en stel ze op het tabblad Environment in als NUXT_API_SECRET of NUXT_PUBLIC_API_BASE. Nuxt leest ze wanneer de server start, dus ze hebben geen vlag Build nodig. Die is alleen nodig voor waarden die nuxt.config tijdens de build uit process.env leest. nuxt.config.ts

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

4. Push om te deployen Elke push naar de branch bouwt een nieuwe release. Het verkeer gaat ernaar over zodra / antwoordt met een 2xx- of 3xx-status. Antwoordt / met 401 of 404, voeg dan een serverroute zoals server/routes/health.ts toe en stel in de app-instellingen /health in als pad voor de health check.

Goed om te weten

• Statische site met nuxt generateNodion herkent nuxt generate niet uit zichzelf en blijft de server starten. Maak voor een statische site nuxt generate je build-script en voeg een static.toml toe met output-dir = ".output/public". Nodion serveert die map dan met een statische webserver en een fallback naar index.html, en de kleinste grootte is genoeg.
• Nitro-presetNodion start .output/server/index.mjs, dat de standaardpreset node-server van Nitro schrijft. Kiest nuxt.config of NITRO_PRESET een preset voor een andere hostingprovider, verwijder die dan.

Wat Nodion voor je regelt

• Deploys zonder downtime Push naar je branch en Nodion bouwt een nieuwe release. Het verkeer schakelt over zodra de nieuwe instanties hun health check doorstaan; een mislukte release laat de draaiende versie staan. Apps met een lokaal volume herstarten in plaats daarvan, omdat de schijf bij één instantie hoort.
• Databases naast de app Managed PostgreSQL, pgvector, MySQL, Valkey en ClickHouse in dezelfde regio. Gekoppelde databases komen binnen als DATABASE_URL, REDIS_URL of CLICKHOUSE_URL.
• Previews per pull request Zet previews aan en pull requests uit je repository krijgen een eigen app met een eigen URL en nieuwe, lege databases, automatisch of handmatig aangemaakt. Forks en pull requests van bots worden overgeslagen.
• Workers, cronjobs en schalen Draai workers als extra processen van dezelfde app, plan jobs op het tabblad Cron en schaal elk proces naar maximaal 16 instanties.
• Releasestap Met buildpacks draait een release:-regel in het Procfile bij elke nieuwe build. Dockerfile-apps, en redeploys of rollbacks naar een eerdere image, gebruiken een releasecommando dat op de app zelf is ingesteld en dat ook voorrang heeft op de Procfile-regel. Bij statische sites draait een releasestap in een image die alleen de gebouwde bestanden bevat.
• Logs en metrics Build-, release- en runtimelogs plus metrics voor CPU, geheugen, schijf en netwerk van elke instantie in het dashboard.
• Domeinen en HTTPS Een standaardhostnaam met HTTPS vanaf de eerste deploy; je eigen domeinen krijgen automatisch certificaten.

Verder lezen

• Previewomgevingen uitgelegd: een app per pull request Een draaiende kopie van je app voor elke pull request: waar previewomgevingen goed voor zijn, waar het lastig wordt en hoe Nodion ze afhandelt.
• Cloud Native Buildpacks uitgelegd Buildpacks maken van je broncode een containerimage zonder Dockerfile. Wat ze zijn en hoe ze werken.

Nuxt op Nodion: vragen en antwoorden