Eine Astro-Site hosten: statische und SSR-Optionen

Astro kann Ihre Site auf zwei sehr unterschiedliche Arten ausliefern, und welche Sie wählen, entscheidet darüber, wo und wie Sie sie hosten. Standardmäßig baut Astro einen Ordner aus einfachem HTML, CSS und JS — Dateien, die jeder statische Hoster ausliefern kann. Aber Astro kann auch auf einem Server laufen und Seiten bei Bedarf (SSR) rendern, für Dinge wie Authentifizierung, Formulare oder Daten pro Anfrage. Dieser Leitfaden erklärt beide Ausgabemodi, die dahinterstehenden Build-Befehle, wie Adapter sich einfügen und wie man für jeden einen Hoster auswählt.

Statisch vs. Server: die zentrale Entscheidung

Jede Hosting-Entscheidung für Astro ergibt sich aus einer Frage: Braucht Ihre Site einen laufenden Server zum Anfragezeitpunkt?

• Statisch (der Standard). Seiten werden einmal, zur Build-Zeit, in HTML-Dateien gerendert. Es gibt keinen Serverprozess — Sie laden den gebauten Ordner auf ein CDN oder einen statischen Hoster hoch, und er liefert die Dateien aus. Am schnellsten, günstigsten, einfachsten. Ideal für Blogs, Dokumentationen, Marketing-Sites und die meisten Content-Sites.
• Server / SSR. Seiten werden pro Anfrage von einem Node- (oder Edge-)Prozess gerendert. Nötig, wenn der Inhalt von der Anfrage abhängt: angemeldete Benutzer, Formularverarbeitung, Personalisierung im Fluge oder Daten, die bei jedem Laden frisch sein müssen.

Sie können auch beides mischen: die Site größtenteils statisch halten und bestimmte Routen in das On-Demand-Rendering hineinnehmen. Der Punkt ist, überall dort statisch zu rendern, wo es geht, und nur dort für einen Server zu zahlen, wo Sie ihn tatsächlich brauchen.

Die Build-Befehle

Was auch immer der Modus ist, der Workflow sind dieselben zwei Befehle — installieren, dann bauen:

# install dependencies
npm install

# produce the production build
npm run build

# preview the production build locally before deploying
npm run preview

Standardmäßig schreibt npm run build eine statische Site in den Ordner dist/. Dieser Ordner ist Ihre gesamte deploybare Site im statischen Modus — es gibt nichts weiter auszuführen.

Den Ausgabemodus konfigurieren

Sie steuern den Modus in astro.config.mjs. Statisch ist der Standard, daher braucht eine minimale Konfiguration nichts Besonderes. Um auf dem Server zu rendern, fügen Sie einen Adapter hinzu — ein kleines Paket, das Astro beibringt, wie es auf einer bestimmten Plattform läuft (Node oder eine Edge-/Serverless-Laufzeit):

// astro.config.mjs — server (SSR) output with the Node adapter
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
});

Mit dem Standalone-Node-Adapter erzeugt npm run build einen Server-Einstiegspunkt, den Sie wie jede Node-App starten:

# after building with the Node adapter
node ./dist/server/entry.mjs

Wenn Sie nur eine Handvoll dynamischer Routen brauchen, behalten Sie die standardmäßige statische Ausgabe bei und nehmen einzelne Seiten vom Prerendering aus, statt die ganze Site in den Servermodus umzustellen:

---
// src/pages/dashboard.astro — render this page per request
export const prerender = false;
---

Einen Hoster nach Modus wählen

Statisches Hosting

Für die statische Ausgabe brauchen Sie nur irgendwo, um den Inhalt von dist/ über HTTPS auszuliefern, idealerweise von einem CDN. Die Build-/Publish-Einstellungen sind einfach:

Build command:    npm run build
Publish/output:   dist

Zahlreiche Plattformen tun dies — gemanagte statische Hoster, Objektspeicher hinter einem CDN oder ein universeller Hoster, der einen Ordner ausliefern kann. Da kein Server am Leben gehalten werden muss, ist statisches Hosting günstig und mühelos zu skalieren. Hosting auf europäischer Infrastruktur ist hier eine gute Wahl, wenn Ihr Publikum oder Ihre Datenresidenz-Anforderungen in diese Richtung weisen.

Server-Hosting (SSR)

SSR braucht eine Laufzeit, die einen Prozess am Leben hält. Zwei grobe Wege:

• Ein Node-Hoster / VPS. Mit dem Node-Adapter bauen Sie einen Standalone-Server und betreiben ihn wie jeden Node-Dienst. Ein VPS gibt Ihnen volle Kontrolle über Prozess, Umgebung und Skalierung — praktisch, wenn Sie dort bereits andere Dienste betreiben.
• Serverless / Edge. Plattformspezifische Adapter verpacken Ihre App, damit sie als Funktionen läuft. Weniger zu verwalten, aber Sie sind an das Modell dieser Plattform gebunden.

Eine einfache Art, den Node-Build auf Ihrem eigenen Server zu betreiben, ist ein Prozessmanager, damit er bei Absturz oder Neustart neu startet:

# example: keep the Astro Node server running with PM2
npm install -g pm2
pm2 start ./dist/server/entry.mjs --name astro-site
pm2 save

Schnellreferenz

Bedarf	Modus	Was hosten
Blog, Dokumentation, Marketing, Content	Statisch (Standard)	Der Ordner dist/ auf einem CDN/statischen Hoster
Größtenteils statisch, ein paar dynamische Routen	Statisch + prerender = false pro Seite	Ein Hoster/Adapter, der On-Demand-Routen unterstützt
Auth, Formulare, Daten pro Anfrage überall	Server (SSR)	Eine Node-Laufzeit / VPS oder Serverless-Plattform

Wie man entscheidet

Beginnen Sie statisch — es ist aus gutem Grund der Standard: günstiger, schneller und einfacher zu hosten. Greifen Sie erst dann zum Server-Adapter, wenn eine echte Anforderung (angemeldeter Zustand, Formularverarbeitung, immer frische Daten) das Rendering pro Anfrage erzwingt, und selbst dann erwägen Sie, nur diese Routen vom Prerendering auszunehmen, statt die ganze Site auf einem Server zu betreiben. Passen Sie den Hoster an den Modus an, bei dem Sie landen: ein CDN-gestützter statischer Hoster für gebaute Dateien oder ein Node-fähiges VPS / eine Serverless-Plattform, wenn Sie wirklich einen Server brauchen.