Deploy SvelteKit op Nodion

SvelteKit stap voor stap deployen

1. Stap over van adapter-auto naar adapter-node Voer npm i -D @sveltejs/adapter-node uit, verwijder @sveltejs/adapter-auto en gebruik de nieuwe adapter in je config. Nodion leest de adapter uit package.json, en de config bepaalt wat de build schrijft, dus pas beide aan. In SvelteKit 3 staat de config in de opties van sveltekit() in vite.config.js; in SvelteKit 2 is het 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. Commit de lockfile, sla het startscript over Commit je lockfile; zonder lockfile mislukt de build. Nodion voert je build-script uit en start node build, en adapter-node luistert op de PORT die Nodion instelt. Een startscript, als je er een toevoegt, vervangt dat commando.
3. Stel de publieke origin in Nodion termineert HTTPS vóór je app, dus SvelteKit kan uit het request niet afleiden welke URL je bezoekers gebruiken, en zonder die URL worden formulierverzendingen als cross-site geweigerd. Zet in SvelteKit 3 paths.origin op je publieke URL, zoals in de config hierboven; dat vervangt de ORIGIN-variabele van adapter-node. Stel in SvelteKit 2 in plaats daarvan ORIGIN in op het tabblad Environment, bijvoorbeeld https://shop.example.com.
4. Variabelen voor build en runtime Waarden uit $env/static/private en $env/static/public worden tijdens de build in de code gezet, dus ze hebben de vlag Build op het tabblad Environment nodig. $env/dynamic/private en $env/dynamic/public worden gelezen terwijl de server draait en werken met gewone variabelen.
5. Maak de app aan en push Maak in het dashboard een applicatie aan vanuit je GitHub-, GitLab-, Bitbucket- of Gitea-repository in de regio EU Central. Elke push bouwt een nieuwe release, en het verkeer gaat ernaar over zodra / antwoordt met een 2xx- of 3xx-status. Antwoordt / met 401 of 404, voeg dan een route zoals src/routes/health/+server.js toe die 200 teruggeeft en stel /health in als pad voor de health check.

Goed om te weten

• Statische sites met adapter-staticMet @sveltejs/adapter-static serveert Nodion build/ met een statische webserver en een fallback naar index.html. Prerender je pagina's met export const prerender = true in de +layout.js in de root. Zet voor een single-page app daar SSR uit en stel fallback: 'index.html' in de adapteropties in, want Nodion heeft een index.html in build/ nodig. Er draait geen Node.js-server, dus de kleinste grootte is genoeg.
• Eén adapter in package.jsonNodion zoekt eerst naar adapter-static, daarna naar adapter-node. Zijn beide geïnstalleerd, dan wordt de app als statische site gebouwd, dus verwijder de adapter die je niet gebruikt.

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.
• Dockerfile vs buildpacks: welke moet je gebruiken? Allebei maken ze van je code een containerimage. Het verschil is wie de buildstappen schrijft, en dat bepaalt controle, onderhoud en beveiligingsupdates.

SvelteKit op Nodion: vragen en antwoorden