SvelteKit auf Nodion deployen

SvelteKit Schritt für Schritt deployen

1. Von adapter-auto auf adapter-node wechseln Führ npm i -D @sveltejs/adapter-node aus, entfern @sveltejs/adapter-auto und trag den neuen Adapter in deine Config ein. Nodion liest den Adapter aus der package.json, was der Build schreibt, entscheidet die Config; ändere also beides. In SvelteKit 3 steht die Config in den Optionen von sveltekit() in der vite.config.js, bei SvelteKit 2 ist es kit.adapter in der 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. Lockfile committen, start-Skript weglassen Committe dein Lockfile; ohne Lockfile scheitert der Build. Nodion führt dein build-Skript aus und startet node build, und adapter-node lauscht auf dem PORT, den Nodion setzt. Ein start-Skript, falls du eins anlegst, ersetzt diesen Befehl.
3. Öffentlichen Origin setzen Nodion terminiert HTTPS vor deiner App, SvelteKit kann aus dem Request also nicht ablesen, unter welcher URL deine Besucher die App aufrufen, und lehnt Formular-Submits sonst als Cross-Site ab. In SvelteKit 3 setzt du paths.origin wie in der Config oben auf deine öffentliche URL; das ersetzt die ORIGIN-Variable von adapter-node. Bei SvelteKit 2 setzt du stattdessen ORIGIN auf dem Tab Environment, etwa https://shop.example.com.
4. Variablen für Build und Laufzeit Werte aus $env/static/private und $env/static/public werden beim Build eingesetzt, sie brauchen auf dem Tab Environment also das Häkchen Build. $env/dynamic/private und $env/dynamic/public liest der Server zur Laufzeit, dafür reichen normale Variablen.
5. App anlegen und pushen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository in der Region EU Central an. Jeder Push baut ein neues Release, und der Traffic wechselt, sobald / mit 2xx oder 3xx antwortet. Antwortet / mit 401 oder 404, leg eine Route wie src/routes/health/+server.js an, die 200 liefert, und trag /health als Health-Check-Pfad ein.

Gut zu wissen

• Statische Sites mit adapter-staticMit @sveltejs/adapter-static liefert Nodion build/ über einen statischen Webserver mit index.html-Fallback aus. Prerendere deine Seiten mit export const prerender = true im Root-+layout.js. Für eine Single-Page-App schaltest du dort SSR ab und setzt in den Adapter-Optionen fallback: 'index.html', denn Nodion braucht eine index.html in build/. Es läuft kein Node.js-Server, die kleinste Größe reicht.
• Nur ein Adapter in der package.jsonNodion prüft zuerst auf adapter-static, dann auf adapter-node. Sind beide installiert, wird die App als statische Site gebaut; entfern also den Adapter, den du nicht nutzt.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Preview-Environments erklärt: eine App pro Pull Request Eine laufende Kopie deiner App für jeden Pull Request: wofür Preview-Environments gut sind, wo es knifflig wird und wie Nodion sie handhabt.
• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.

SvelteKit auf Nodion: Fragen und Antworten