SvelteKit auf Lizard bereitstellen

Verwende @sveltejs/adapter-node, um einen SvelteKit-Server für Lizard zu bauen. Dabei entsteht build/, das mit node build auf Port 3000 startet. Installiere und konfiguriere den Adapter ausdrücklich; ein Scaffold, das noch adapter-auto verwendet, richtet kein Node-Bereitstellungsziel ein.

Beginne mit dem vollständigen Quellcode-Beispiel, das die Konfiguration und Dateien enthält, die in dieser Anleitung verwendet werden.

Adapter konfigurieren

Die Hauptversion des Adapters muss zu der von SvelteKit passen. Unter SvelteKit 2, das das Beispiel und die Cloud-Prüfungen verwenden, installierst du adapter-node 5:

npm install --save-dev @sveltejs/adapter-node@5

Ohne @5 wählt npm adapter-node 6, das SvelteKit 3 voraussetzt, und bricht mit einem ERESOLVE-Fehler ab.

Behalte in svelte.config.js dein bestehendes Preprocess und andere Einstellungen bei, setze aber kit.adapter auf den Node-Adapter:

import adapter from '@sveltejs/adapter-node';
 
export default {
  kit: { adapter: adapter() },
};

Unter SvelteKit 3 erhältst du adapter-node 6 mit npm install --save-dev @sveltejs/adapter-node. SvelteKit 3 liest svelte.config.js nicht mehr; übergib den Adapter an das Plugin sveltekit() in vite.config.js:

import adapter from '@sveltejs/adapter-node';
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';
 
export default defineConfig({
  plugins: [sveltekit({ adapter: adapter() })],
});

SvelteKit 3 braucht Node 22.17 oder neuer; das Standard-Build-Image mit Node 22 erfüllt das. Die Schritte für SvelteKit 3 haben wir lokal gebaut, aber noch nicht auf Lizard bereitgestellt.

Behalte nur den Bereitstellungs-Adapter, den du tatsächlich verwenden willst. Insbesondere kann eine ungenutzte Abhängigkeit @sveltejs/adapter-static im aktuellen Detektor den statischen Pfad auswählen, selbst wenn deine Konfiguration adapter-node importiert.

Produktionsserver testen

npm ci
npm run build
HOST=0.0.0.0 PORT=3000 ORIGIN=http://localhost:3000 node build

Öffne eine servergerenderte Seite und sende eine Formularaktion ab, falls die App eine hat. Behalte den Standard-Ausgabepfad des Adapters für die in dieser Anleitung verwendete Erkennung bei.

adapter-node 6 ignoriert ORIGIN. Es bildet die Origin aus https und dem Host-Header der Anfrage, daher bekommt unter SvelteKit 3 ein Formular, das von http://localhost:3000 gesendet wird, in diesem lokalen Test eine 403. Prüfe Formulare über die bereitgestellte HTTPS-URL.

Bereitstellen und die öffentliche Origin setzen

Nach dem CLI-Setup:

lizard init --name sveltekit-app
lizard add --service web
lizard up --service web --port 3000
lizard ps --json

Setze unter SvelteKit 2 ORIGIN auf die genaue öffentliche HTTPS-Origin aus der Bereitstellungsausgabe, ohne Pfad. Ersetze zum Beispiel diesen Platzhalter durch deine tatsächliche URL:

lizard secrets set ORIGIN=https://YOUR_PUBLIC_HOST --service web

Verwende stattdessen die benutzerdefinierte Domain, wenn Besucher diese Origin verwenden werden. Prüfe Formulare nach der Variablenänderung erneut. Für mehrere erlaubte Origins oder Proxy-abgeleitete URLs lies die Anleitung zum SvelteKit Node-Server und konfiguriere vertrauenswürdige Proxy-Header bewusst.

Unter SvelteKit 3 entfällt ORIGIN: Die App nimmt ihre Origin aus dem Host-Header, der den öffentlichen Hostnamen oder deine benutzerdefinierte Domain enthält. Um eine feste Origin vorzugeben, setze paths: { origin: 'https://YOUR_PUBLIC_HOST' } in den Optionen von sveltekit(); SvelteKit liest sie beim Build.

Verifizieren und Fehler beheben

Lies Build- und Laufzeit-Logs mit lizard logs --build --service web --json und lizard logs --service web --json. Öffne direkt eine innere Route, sende ein Formular ab und rufe eine fehlende Route an.

Wenn Formulare einen Fehler wegen einer Cross-Website-Übermittlung melden, prüfe ORIGIN (SvelteKit 2) oder paths.origin (SvelteKit 3), bevor du eine Sicherheitsprüfung deaktivierst. Wenn node build den Server nicht finden kann, prüfe den aktiven Adapter und den Ausgabepfad. Lasse Überschreibungen des Service-Befehls ungesetzt, um den lizardpack-Pfad zu verwenden.

Statische SvelteKit-Sites

Eine App, die alle benötigten Seiten prerendern kann, kann @sveltejs/adapter-static, die Standard-Ausgabe build/ und Service-Port 80 verwenden. Diese Ausgabe kann keine Server-Aktionen oder Endpunkte zur Request-Zeit ausführen. Konfiguriere Prerendering für die benötigten Routen; das Paket allein zu installieren reicht nicht aus.

Installiere unter SvelteKit 2 @sveltejs/adapter-static@3 (Version 4 setzt SvelteKit 3 voraus) und ersetze den Adapter-Import in svelte.config.js:

import adapter from '@sveltejs/adapter-static';
 
export default {
  kit: { adapter: adapter() },
};

Installiere unter SvelteKit 3 @sveltejs/adapter-static und importiere ihn in vite.config.js anstelle von adapter-node.

Für eine Website, deren Routen vollständig generiert werden können, füge dies zu src/routes/+layout.js hinzu:

export const prerender = true;
export const trailingSlash = 'always';

Entferne ungenutzte Bereitstellungs-Adapter aus den Abhängigkeiten. Führe npm run build aus und prüfe, dass build/ jede benötigte Seite enthält. Für die Standard-Ausgabe lasse Überschreibungen des Service-Befehls ungesetzt und stelle einen neuen Service auf Port 80 bereit. Neue Builds liefern das generierte HTML aus und geben HTTP 404 für fehlende Seiten zurück. Verwende für nginx nicht erneut den Port 3000 aus dem Server-Rezept.

Verwende statische Routen und 404-Seiten, um zwischen generierten HTML-Routen und einem SPA-Fallback zu wählen. Sieh dir den SvelteKit Static Adapter für Framework-Optionen und Einschränkungen an.

Siehe getestete Versionen und Cloud-Ergebnisse für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen.

Aktualisiert 21. Oktober 2026