S SvelteKurs
M11 · Deployment

Build-Modi & Adapter

Wie aus deinem Code eine lauffähige App wird — und welche Rendering-Strategie wann passt.

Adapter: das Ziel bestimmen

SvelteKit selbst ist plattformunabhängig. Ein Adapter übersetzt deinen Code beim Build in etwas Lauffähiges für eine konkrete Umgebung: einen Node-Server, ein serverloses Deployment (Vercel/Netlify) oder rein statische Dateien.

Für Self-Hosting (Docker, Coolify) ist @sveltejs/adapter-node die richtige Wahl — er erzeugt einen eigenständigen Node-Server im Ordner build/:

vite.config.ts ts 
// vite.config.ts (dieses Projekt nutzt adapter-node)
import adapter from '@sveltejs/adapter-node';
import { sveltekit } from '@sveltejs/kit/vite';

export default defineConfig({
  plugins: [sveltekit({ adapter: adapter() })]
});
bash 
npm run build     # erzeugt build/ (adapter-node)
node build        # startet den Produktionsserver

ℹ️ adapter-auto vs. fester Adapter

Neue Projekte starten oft mit adapter-auto (errät die Plattform). Für ein vorhersehbares Docker-Deployment setzt man bewusst adapter-node — so baust du lokal exakt das, was später im Container läuft.

SSR, CSR & Prerendering

  • SSR (Standard): Server rendert HTML pro Request, Client übernimmt (Hydration).
  • Prerendering: Seite wird zur Build-Zeit einmal zu statischem HTML gerendert — ideal für Inhalte, die sich nicht pro Nutzer ändern.
  • CSR/SPA: kein Server-Rendering, alles im Browser.

Du steuerst das pro Route über Seitenoptionen:

ts 
// In einer +page.ts / +page.server.ts / +layout.ts:

export const prerender = true;  // zur Build-Zeit zu statischem HTML rendern
export const ssr = false;       // kein Server-Rendering → reine Client-Seite (SPA)
export const csr = false;       // kein Client-JS → statisches HTML, keine Interaktivität

🛤️ Rails-Vergleich: Rendering-Strategien

Server-gerendertes ERB entspricht dem SSR-Standard, assets:precompile/statische Seiten dem Prerendering, und ein API-only-Rails mit separatem JS-Frontend dem SPA-Modus.

Analogie ruby 
# Rails: unterschiedliche "Modi"
# - Server-gerendert (ERB)            ≈ SSR (Standard)
# - assets:precompile / statisch      ≈ prerender
# - API-only + JS-Frontend            ≈ ssr:false (SPA)

Wichtige Umgebungsvariablen (adapter-node)

💡 Zur Laufzeit gesetzt

  • PORT — Port des Servers (Standard 3000).
  • HOST — 0.0.0.0, damit der Container von außen erreichbar ist.
  • ORIGIN — die öffentliche URL (z.B. https://svelte.apps.tomcodes.de); nötig, damit POST/Form-Actions den CSRF-Schutz bestehen.

Zusammenfassung

💡 Das Wichtigste

  • Der Adapter bestimmt das Deploy-Ziel; adapter-node für Docker/Coolify.
  • Rendering pro Route steuerbar: prerender, ssr, csr.
  • ORIGIN in Produktion setzen, sonst schlagen Form Actions fehl.

🎯 Probier es selbst

Setze auf der Landingpage (src/routes/+page.svelte → lege ein +page.ts an) export const prerender = true; und baue neu. Sie wird dann als statisches HTML erzeugt.