Bei Astro mit Server-Rendering entscheidet die Plattform über Kosten, Kaltstart und Datenschutz

Der Punkt kommt in fast jedem Astro-Projekt irgendwann. Die Website steht, ist komplett statisch, lädt schnell, und dann soll das Kontaktformular serverseitig validiert werden, eine Preisberechnung live rechnen oder ein Kundenbereich hinter einem Login liegen. Ab da braucht das Projekt einen Adapter. Und mit dem Adapter kommt eine Frage, die viel weitreichender ist als der astro add-Befehl, mit dem sie beantwortet wird.

Ich habe die vier üblichen Wege einmal auseinandergenommen. Nicht nach Deploy-Komfort, sondern nach dem, was danach dauerhaft gilt.

Vier Adapter, vier verschiedene Laufzeitumgebungen

astro add vercel, netlify, cloudflare oder node sehen von außen gleich aus. Darunter landet der Code in vier grundverschiedenen Umgebungen.

Stand 27.07.2026 laufen die Versionen @astrojs/node 11.0.2, @astrojs/vercel 11.0.3, @astrojs/netlify 8.1.2 und @astrojs/cloudflare 14.1.5, alle mit peerDependency astro ^7.0.0. Astro selbst steht bei 7.1.4 und verlangt Node ab 22.12.0.

Foto: eelias / Unsplash

Der Node-Adapter kennt zwei Modi. standalone startet einen eigenen HTTP-Server, middleware hängt sich in eine bestehende Express- oder Fastify-Anwendung ein. Konfiguriert wird über Umgebungsvariablen.

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

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

HOST=0.0.0.0 PORT=4321 node ./dist/server/entry.mjs

Cloudflare ist der Ausreißer. Seit @astrojs/cloudflare 13.0.0 ist der offizielle Support für Cloudflare Pages gestrichen, im Changelog steht “Drops official support for Cloudflare Pages in favor of Cloudflare Workers”. Neue Projekte gehen auf Workers, und dort läuft kein Node, sondern workerd. Wer Node-APIs benutzt, und das tun die meisten Astro-Projekte über Abhängigkeiten, braucht ein Flag.

// wrangler.jsonc
{
  "main": "@astrojs/cloudflare/entrypoints/server",
  "name": "my-astro-app",
  "compatibility_flags": ["nodejs_compat"],
  "compatibility_date": "2024-09-23"
}

Ohne nodejs_compat fehlen node:buffer, node:crypto, node:path und der Rest. Astro-Sessions landen bei Cloudflare automatisch in KV, und KV ist laut Doku zwischen Regionen nur eventually consistent, mit bis zu 60 Sekunden bis zur globalen Propagierung. Für einen Warenkorb ist das relevant, für einen Formular-Endpunkt selten.

Der Kostenhebel liegt vor der Plattformwahl

Ein Missverständnis kostet mehr Geld als jede Plattformentscheidung. Ein Adapter macht ein Astro-Projekt nicht dynamisch. Die Doku ist da eindeutig: “By default, your entire Astro site will be prerendered, and static HTML pages will be sent to the browser.”

Serverlast entsteht ausschließlich dort, wo eine Route sie ausdrücklich anfordert.

// Diese eine Zeile erzeugt die Rechnung. Nicht der Adapter.
export const prerender = false;

Für eine Firmenwebsite heißt das in der Regel: der Formular-Endpunkt und vielleicht zwei API-Routen laufen serverseitig, die restlichen 40 Seiten sind statisches HTML. Wer stattdessen global output: 'server' setzt, weil es in irgendeinem Tutorial so stand, zahlt für jeden Aufruf jeder Unterseite. Das ist der teuerste Ein-Zeilen-Fehler in dieser ganzen Betrachtung.

Was bei SSR tatsächlich abgerechnet wird

Die vier Wege rechnen nach vier verschiedenen Einheiten ab, und das entscheidet, ab welchem Traffic es weh tut.

Vercel hat die Abrechnung von GB-Sekunden auf drei Posten umgestellt. Active CPU zählt nur während echter Code-Ausführung, Provisioned Memory läuft durchgehend mit, auch während I/O-Wartezeiten, dazu kommen die Invocations. In Frankfurt (fra1) sind das 0,184 USD pro CPU-Stunde und 0,0152 USD pro GB-Stunde Memory, dazu 0,15 USD pro GB Fast Data Transfer oberhalb des ersten Terabyte und 2,60 USD pro Million Edge Requests oberhalb der ersten zehn Millionen. Einen Preis pro Invocation nennt die Regionentabelle nicht, das Fluid-Pricing-Dokument rechnet in einem Beispiel mit 0,60 USD je Million. Builds kosten 0,0035 USD pro CPU-Minute. Der Hobby-Plan mit seiner Million Invocations ist laut Fair-Use-Richtlinie ausdrücklich “non-commercial, personal use only”, scheidet für eine Firmenwebsite also aus. Pro startet bei 20 USD im Monat für einen deployenden Sitz, jeder weitere kostet nochmal 20 USD.

Netlify rechnet seit dem 14.04.2026 in Credits. Bandbreite 20 Credits pro GB, Compute 10 Credits pro GB-Stunde, Web Requests 2 Credits pro 10.000, ein Produktions-Deploy 15 Credits. Netlify beziffert das selbst in Dollar, aus 20 Credits pro GB werden 0,13 USD. Rechnerisch entsprechen die 3.000 Credits im Pro-Plan für 20 USD damit rund 150 GB reiner Bandbreite. Der Free-Plan hat 300 Credits als harte Grenze ohne Nachkaufmöglichkeit, also rund 15 GB. Deploy Previews und Branch Deploys kosten nichts, und die Abrechnung pro Sitz ist entfallen.

Foto: towfiqu999999 / Unsplash

Cloudflare rechnet nach CPU-Millisekunden. Free sind 100.000 Requests pro Tag bei 10 ms CPU-Zeit pro Invocation, Paid ab 5 USD im Monat mit 10 Millionen Requests und 30 Millionen CPU-Millisekunden, darüber 0,30 USD je weitere Million Requests. Requests auf statische Assets sind laut Doku “free and unlimited”. Für eine überwiegend vorgerenderte Astro-Seite ist das die mit Abstand günstigste Konstellation. Die Grenzen sind dafür hart: 128 MB pro Isolate, 3 MB gzippte Worker-Größe im Free-Plan, 10 MB im Paid-Plan.

Beim eigenen Node-Prozess wird pro Request gar nichts abgerechnet. Ein Hetzner CX33 mit 4 vCPU und 8 GB kostet seit der Preisanpassung vom 15.06.2026 8,49 Euro im Monat, mit 20 TB Traffic und einer IPv4. Ob der Server dabei 100 oder 100.000 Requests bedient, steht nicht auf der Rechnung.

Alle diese Zahlen sind Listenpreise pro Einheit, keine beobachteten Rechnungen. Wer sie in eine Prognose übersetzt, braucht eigene Traffic-Daten.

Kaltstart ist keine Zahl, sondern eine Bauart

Zu Kaltstartzeiten kursieren viele Zahlen, und die meisten stammen von den Anbietern selbst. Ich habe hier nichts gemessen, deshalb bleibe ich bei dem, was dokumentiert ist.

Cloudflare setzt auf V8-Isolates statt auf virtuelle Maschinen. Laut Doku wird ein Isolate innerhalb einer bereits laufenden Umgebung erzeugt, was “eliminates the cold starts of the virtual machine model” und rund hundertmal schneller startet als ein Node-Prozess im Container. Im Cloudflare-Blog steht die Zahl 5 ms für das Laden eines Workers, und der Start wird bereits beim TLS-ClientHello angestoßen, sodass er in der Netzwerklatenz verschwindet. Der Blogeintrag stammt allerdings vom 30.07.2020, ist also alt.

Vercel formuliert bewusst qualitativ. Fluid compute ist seit dem 23.04.2025 für neue Projekte Standard, dämpft Kaltstarts über Bytecode-Caching und Pre-Warming und “minimizes the effects of cold starts by greatly reducing their frequency and softening their impact”. Millisekunden nennt Vercel nicht.

Netlify Edge Functions laufen in einer Deno-basierten Runtime mit einem Limit von 50 ms CPU-Ausführungszeit pro Request. Das ist kein Kaltstart-Thema, aber es trifft direkt die Astro-Middleware, sobald middlewareMode: 'edge' gesetzt ist.

Der dauerhaft laufende Node-Prozess hat das Problem gar nicht. Er startet einmal und bleibt. Das ist der ehrlichste Vorteil des eigenen Servers und der am seltensten genannte.

Die Auftragsverarbeitungskette ist das eigentliche Unterscheidungsmerkmal

Hier trennen sich die vier Wege wirklich, und englischsprachige Vergleiche lassen diesen Teil meist komplett weg.

Vercel Inc. ist eine Delaware-Gesellschaft, und im DPA steht “Vercel’s primary processing facilities are in the United States”. Die Plattform läuft dabei selbst auf fremder Infrastruktur, dokumentiert als “The Vercel CDN and deployment platform primarily uses Amazon Web Services (AWS)”. Es hängt also mindestens ein weiterer Verarbeiter dran. Bei Vercel beträgt die Widerspruchsfrist gegen neue Unterauftragsverarbeiter fünf Kalendertage, das einzige Rechtsmittel ist die Kündigung. Die vollständigen Unterauftragsverarbeiter-Listen von Vercel und Netlify liegen hinter Trust-Center-Zugängen und sind ohne Anmeldung nicht einsehbar. Für ein Verarbeitungsverzeichnis ist das unpraktisch.

Foto: drwmrk / Unsplash

Dazu kommt die Default-Region, und die wird gern übersehen. Vercel legt Funktionen aller neuen Projekte nach iad1, also Washington D.C. Netlify-Functions laufen standardmäßig in cmh, US East in Ohio. Beides lässt sich umstellen, bei Netlify allerdings erst ab dem Pro-Plan.

// vercel.json
{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "regions": ["fra1"]
}

# netlify.toml
[functions]
  region = "fra"

Bei Cloudflare Workers ist die Regionalisierung praktisch nicht herstellbar. Die Data Localization Suite ist ein Enterprise-Add-on, und für Workers gilt laut Doku ohnehin “Workers code and secrets are deployed globally to all Cloudflare data centers”. Regional Services greift nur für die konfigurierte Custom Domain und deckt ausgehende Subrequests, Queues und Cron Triggers nicht ab.

Hetzner steht am anderen Ende. Im AV-Vertrag nach Art. 28 DSGVO, Version 1.1 vom 10.02.2025, heißt es in § 3 Abs. 1 wörtlich, die Verarbeitung finde “ausschließlich in einem Mitgliedstaat der Europäischen Union oder in einem anderen Vertragsstaat des Abkommens über den Europäischen Wirtschaftsraum” statt. Die genehmigten Subunternehmer sind standortgebunden, für Finnland die Hetzner Finland Oy, für die USA die Hetzner US LLC und zwei Rechenzentrumsbetreiber. Wer in Nürnberg oder Falkenstein bucht, hat die Hetzner Online GmbH als einzigen Verarbeiter. Die Widerspruchsfrist beim Subunternehmerwechsel beträgt 14 Tage.

CLOUD Act und Data Privacy Framework, Stand Juli 2026

Alle drei US-Plattformen sind unter dem EU-U.S. Data Privacy Framework zertifiziert, für Netlify weist die DPF-Liste den 13.02.2020 als Erstzertifizierungsdatum aus. Das ist eine gültige Übermittlungsgrundlage auf Basis des Angemessenheitsbeschlusses (EU) 2023/1795 vom 10.07.2023. Es ist keine Immunität gegen Zugriffe nach US-Recht.

Der US CLOUD Act steht als 18 U.S.C. § 2713 im Gesetz, eingefügt am 23.03.2018. Der Wortlaut verpflichtet Anbieter zur Herausgabe von Inhalten und Kundendaten, “regardless of whether such communication, record, or other information is located within or outside of the United States”. Der Serverstandort ist damit die falsche Frage. Entscheidend ist, welchem Konzern der Anbieter gehört. Ob Vercel, Netlify und Cloudflare im Einzelfall als Anbieter im Sinne des Stored Communications Act einzuordnen sind, ist nicht gerichtlich geklärt, in der Praxis wird es so behandelt.

Die Lage ist zusätzlich in Bewegung. Das EuG hat die Nichtigkeitsklage Latombe am 03.09.2025 abgewiesen, das Rechtsmittel läuft beim EuGH als C-703/25 P. Am 29.06.2026 hat der US Supreme Court in Trump v. Slaughter mit 6:3 entschieden, dass der Kündigungsschutz für FTC-Kommissare verfassungswidrig ist. noyb hat die EU-Kommission daraufhin aufgefordert, den Angemessenheitsbeschluss geordnet zurückzunehmen, weil sich die Kommission darin vielfach auf eine unabhängige FTC stützt. Aufgehoben ist bisher nichts. Wer eine Prognose braucht, bekommt sie hier nicht. Wer eine Risikoeinschätzung für ein Verarbeitungsverzeichnis braucht, hat mit diesen Daten das Nötige.

Am Rande relevant: Cloudflare hat am 16.01.2026 die Übernahme der Astro Technology Company bekanntgegeben. Framework-Hersteller und eine der vier Deploy-Optionen gehören seither zum selben Konzern.

Der eigene Node-Prozess auf Hetzner, mit allem was dazugehört

Diese Website läuft als Astro-SSR-Container mit node dist/server/entry.mjs auf Port 4321, auf einem Hetzner CX33 im Rechenzentrum Nürnberg, orchestriert über Coolify, Reverse Proxy Traefik, TLS über Let’s Encrypt. Auf demselben Server laufen rund 36 Container. Coolify steht unter Apache License 2.0 und ist laut eigener Doku “completely free to use, open-source, and has no features locked behind a paywall”, inklusive Push-to-Deploy und PR-Deployments.

Das klingt nach der bequemen Lösung. Ist es nicht, und die Belege dafür stehen in meiner eigenen Betriebsdoku.

Am 25.07.2026 haben 616 nie bereinigte Docker-overlay2-Layer die Disk vollgefahren. Symptome waren HTTP 500 aus der Coolify-API und 350 Prozent CPU-Last. Behoben über Log-Löschung, Reboot und docker prune, das 11,18 GB freigegeben hat. Danach lag die Disk-Auslastung bei 83 Prozent. 80 GB für 36 Container sind zu knapp, ein Cronjob für regelmäßiges Pruning fehlt bis heute.

Foto: fslfsl / Unsplash

Zweites Beispiel. Der Coolify-Auto-Deploy nach git push greift bei der Website-App nicht zuverlässig, das Deployment muss dort per API ausgelöst werden. Drittes Beispiel. Docker liest Container-Labels nur beim Create, nicht bei stop/start. Geänderte Traefik-Labels griffen bei einer Node-App erst nach einem vollen Deploy, nicht nach einem Restart. Viertes Beispiel. Das noindex für Staging-Domains ist bei mir eine Traefik-Label-Middleware mit X-Robots-Tag, bewusst nicht im Code, damit beim Kunden-Deploy kein noindex mitwandert. Bei Vercel und Netlify ist genau das eingebaut.

Persistente Daten sind der fünfte Punkt. Auf dem eigenen Server hängt ein Volume am Container, und die Uploads liegen einfach da. Auf den Serverless-Plattformen gibt es dieses Konzept nicht, dort braucht jede Datei einen externen Objektspeicher. Das ist kein Nachteil, aber ein Architekturunterschied, den man vor der Wahl kennen sollte.

Und Build-Zeiten. Bei einem meiner Next.js-Projekte auf Coolify mit Nixpacks lagen die Builds vor der Optimierung im Schnitt bei 7 bis 8 Minuten, der schnellste bei 5m34s, der längste bei 12m14s (Messreihe Anfang Juni 2026). In der Engpassanalyse eines Sieben-Minuten-Builds gingen 122 Sekunden allein für den Docker-Export der Image-Layer und 40 Sekunden für den Unpack drauf, zusammen 39 Prozent reines Image-Handling. Standalone-Output, eine .dockerignore und eine eigene nixpacks.toml sind dagegen Standardarbeit, finden und umsetzen musste ich sie trotzdem selbst. Diese Zeit zahlt man nicht in Dollar, aber man zahlt sie. Astro selbst ist dabei nicht das Problem, das Upgrade dieser Website auf Astro 7 hat die Build-Zeit halbiert.

Entscheidungsraster für kleine Firmenwebsites

Vier Fälle, vier Antworten.

Eine überwiegend statische Firmenwebsite mit einem Formular-Endpunkt und ohne besondere Datenschutzanforderungen fährt auf Cloudflare Workers am günstigsten. 5 USD im Monat, kostenlose Asset-Requests, kein Kaltstartproblem. Preis-Leistung schlägt hier alles andere.

Verarbeitet dieselbe Website personenbezogene Daten, die im Verarbeitungsverzeichnis sauber stehen müssen, kippt das Bild. Dann zählt eine kurze, dokumentierte Kette mehr als drei gesparte Euro, und der eigene Node-Prozess bei einem EU-Anbieter ist die klarere Antwort. Ausführlicher zum Kostenvergleich mit den großen Clouds steht das im Vergleich Hetzner gegen AWS und Azure.

Ein Team, das ohne eigene Betriebskompetenz schnell liefern muss und Preview-Deployments pro Pull Request braucht, ist bei Vercel oder Netlify richtig aufgehoben. Dann aber mit regions: ["fra1"] beziehungsweise region = "fra" von Anfang an, nicht nachträglich.

Und wer bereits einen Server betreibt, auf dem andere Dienste laufen, hat die Entscheidung faktisch schon getroffen. Der Grenzaufwand für einen weiteren Astro-Container ist gering, der Grenzaufwand für eine zusätzliche Plattform im Verarbeitungsverzeichnis nicht.

Wenn du gerade vor genau dieser Entscheidung stehst und wissen willst, welche Routen in deinem Astro-Projekt überhaupt serverseitig laufen müssen und was das je Plattform bedeutet, schau ich mir das gern konkret an. Schreib mir kurz, wie das Projekt aufgebaut ist.