Netlify, Cloudflare Pages, Vercel und Sarpius stellen alle statische Websites über eine globale Edge bereit. Hier erfährst du, wie sie sich bei Rechtsraum und Preis tatsächlich unterscheiden.
Aktualisiert am 24. September 2026
Bei einem statischen oder clientseitig gerenderten Build (Vite, einer vorgerenderten SvelteKit-Website, Astro, reinem HTML/CSS) machen die gängigen Plattformen Netlify, Cloudflare Pages, Vercel und Sarpius technisch ungefähr dasselbe: Du pushst ein Git-Repository, erhältst einen einmal hochgeladenen Build, der über eine gecachte Edge mit automatischem TLS bereitgestellt wird, ohne Containerkosten. Cloudflare Pages läuft direkt auf dem eigenen Netzwerk von Cloudflare. Netlify und Vercel betreiben jeweils ihr eigenes CDN. Sarpius lädt den Build in S3-kompatiblen Objektspeicher hoch und stellt ihn über seinen eigenen Edge-Proxy bereit, der standardmäßig selbst hinter dem Netzwerk von Cloudflare liegt. Eine bei Sarpius gehostete statische Website wird daher in zwei Schichten statt in einer gecacht. Die praktischen Unterschiede sind der Rechtsraum, ob die kostenlose Stufe kommerzielle Nutzung erlaubt und was passiert, sobald das Project auch ein echtes Backend benötigt.
Ja. Der Assistent von Sarpius zum Verbinden eines Repositorys erkennt unter seinen 45 automatisch erkannten Frameworks und Laufzeitumgebungen Vite, SvelteKit, Astro, React, Vue, Angular, Hugo, Eleventy, Docusaurus, MkDocs und reine statische Ausgabe und ordnet jede erkannte Component vor deiner Bestätigung des Plans als „Aus Speicher bereitgestellt (statisch)“ oder „Container“ ein. Eine statische Component startet niemals einen Container, wird nach gespeicherter Größe (EUR 0.025/GB-month) statt nach Traffic abgerechnet und erhält für ihre gehashten Build-Assets (die Form app.4f3a9c12.js, die Vite, Rollup und webpack alle erzeugen) Cache-Control: public, max-age=31536000, immutable; alles andere erhält no-cache, sodass ein Redeploy immer erkannt wird. Verzeichnisartige Routen werden in die jeweils eigene index.html des Verzeichnisses aufgelöst, sodass /blog korrekt blog/index.html bereitstellt, statt auf die Wurzel der Website zurückzufallen.
| Funktion | Sarpius | Netlify | Cloudflare Pages | Vercel |
|---|---|---|---|---|
| Unternehmen / Hauptsitz | Niederlande (KVK 73239038), besitzt eigene Hardware | Vereinigte Staaten (San Francisco) | Vereinigte Staaten (San Francisco) | Vereinigte Staaten (San Francisco) |
| So wird der statische Build bereitgestellt | S3-kompatibler Speicher + eigene Edge von Sarpius, hinter dem Netzwerk von Cloudflare | Eigenes CDN von Netlify | Direkt auf dem eigenen globalen Netzwerk von Cloudflare | Eigenes CDN von Vercel (126 PoPs, 19 Regionen, laut eigener Dokumentation von Vercel) |
| Kostenlose Stufe, kommerzielle Nutzung | Erlaubt, in den Nutzungsbedingungen, section 5, erklärt | Auf der aktuellen Preisseite von Netlify keine ausdrückliche Einschränkung gefunden (vor einer Entscheidung prüfen) | Auf den geprüften Dokumentations-/Preisseiten von Cloudflare Pages keine Einschränkung gefunden | Ausdrücklich auf persönliche, nicht kommerzielle Projekte beschränkt |
| Günstigster kostenpflichtiger Tarif | EUR 4.99/month pro zusätzlicher App (Container-Seite; statische Components werden nur nach Speicher abgerechnet) | „Personal“-Tarif um $9/month, laut aktueller Preisseite von Netlify (genaue Tarifnamen als „prüfen“ behandeln) | Kostenloser Tarif: 500 Builds/month, 100 Projects/account; kostenpflichtige Stufe „Workers Paid“ für höhere Limits | Pro: $20/month pro Sitz |
| EU-Rechtsraum (Unternehmen, nicht nur Rechenzentrum) | Ja, niederländisches Unternehmen, keine US-Muttergesellschaft | Nein, US-Unternehmen | Nein, US-Unternehmen | Nein, US-Unternehmen |
| Container/Backend im selben Produkt | Ja, First-Party (PHP, Node, Python, Java, Go) | Kein First-Party-Containerprodukt; nur Functions | Workers (serverless), keine Container | Serverless-/Edge-Functions, keine Container |
| Verwaltete Datenbank im selben Produkt | Ja: PostgreSQL, Redis, MariaDB | Keine First-Party-Datenbank | D1 (SQLite-kompatibel), KV, R2 | Keine First-Party-Datenbank mehr, seit Vercel Postgres/KV eingestellt wurden |
| Project-Export / Ausstiegspaket | Project-Migrationspaket: Containerdateien, SQL-Datenbankdumps, Bucket-Objekte, Commit-Manifest, secrets.env über ein 5-min-Einmal-Token hinter 2FA, 24h-Aufbewahrung | Nur Git-Repository; kein automatisiertes vollständiges Stack-Archiv | Git-Repository und Cloudflare API/wrangler; separate Exporte für D1/KV/R2 | Nur Git-Repository; separate Exporte von Partnerdatenbanken |
Das eigene Netzwerk von Cloudflare erstreckt sich nach dessen veröffentlichter Zahl über 348 Städte in 8 Regionen, und das von Vercel nach dessen eigener Dokumentation über 126 Points of Presence in 19 rechenfähige Regionen. Keine dieser Zahlen sagt etwas darüber aus, welches Unternehmensrecht für deine Daten gilt: Cloudflare Pages, Netlify und Vercel sind alle US-Unternehmen, daher gilt die Frage des CLOUD Act für die Plattform, auch wenn ein bestimmter Edge-Node zufällig in einer EU-Stadt steht. Sarpius ist ein niederländisches Unternehmen ohne US-Muttergesellschaft. Für eine Domain, bei der Cloudflare selbst als Unterauftragsverarbeiter und nicht der Standort des Servers das Problem ist, entfernt eine kostenpflichtige „Privacy route“ pro Domain Cloudflare vollständig aus dem Anfragepfad dieser Domain, zu EUR 4.99/month zusätzlich zur bestehenden Gebühr von EUR 1.99/month für eine benutzerdefinierte Domain. Diese Option verzichtet für die Domain auf Cloudflares CDN, WAF und DDoS-Schutz. Es ist ein echter Tausch, kein kostenloses Upgrade.
Hier gehen die vier Plattformen am stärksten auseinander. Netlify, Cloudflare Pages und Vercel antworten jeweils mit serverlosen/Edge-Functions: kurzlebig, auf eine Anfrage begrenzt, ohne langlebigen Prozess. Sarpius antwortet mit einem Container im selben Project, der mit einer verwalteten Postgres-, Redis- oder MariaDB-Datenbank verbunden ist. Das passt besser zu einem echten Backend-Prozess (einer Laravel-API, einem Node-Worker, einem langlebigen Job) als eine Handvoll zustandslose Functions. Die eigenen Serverless Functions von Sarpius, das Function-per-Request-Modell, das die drei anderen bereits anbieten, sind geplant und noch nicht verfügbar.
Nein. Eine aus dem Objektspeicher bereitgestellte statische Component wird nach gespeicherten GB und nicht nach Egress abgerechnet; das Bandbreitenpaket von 10 GB und der Aufpreis von EUR 0.05/GB gelten für Container-Apps, nicht für den aus dem Speicher bereitgestellten Pfad.
Technisch ja: Ein Build wird einmal hochgeladen, gehashte Assets werden unveränderlich gecacht, alles andere wird bei jeder Anfrage revalidiert und die Website liegt hinter einem CDN. Der Unterschied liegt darin, wer dieses CDN betreibt: Vercel und Netlify betreiben ihr eigenes; Sarpius stellt über seinen eigenen Edge-Proxy bereit, der standardmäßig hinter dem separat betriebenen Netzwerk von Cloudflare liegt, mit einem kostenpflichtigen Opt-out pro Domain.
Ja. Ein Project ist eine Anwendung aus mehreren Components; der Assistent erkennt jede einzeln und legt das Frontend im Speicher sowie das Backend in einem Container ab. Sie teilen sich Routing, Datenbanken und Speicher.
Ja. Die Nutzungsbedingungen sagen dies in section 5 ausdrücklich: Die Free Tier darf für jeden rechtmäßigen Zweck verwendet werden, einschließlich kommerzieller Nutzung wie einer Unternehmenswebsite oder dem Frontend eines kostenpflichtigen Produkts.
Ja. Du kannst aus dem Project-Workspace hinter Zwei-Faktor-Authentifizierung ein Project-Migrationspaket erzeugen. Das Paket enthält den gebauten statischen Output, laufende Containerdateien, SQL-Datenbankdumps, Bucket-Objekte und ein Manifest mit Git-Commit-SHAs, sha256-Prüfsummen je Datei und ausdrücklichen Auslassungshinweisen. Entschlüsselte Umgebungsvariablen werden beim Download über ein einmal verwendbares 5-min-Token als secrets.env gestreamt und niemals im ruhenden Paketartefakt gespeichert. Pakete sind 24 Stunden lang herunterladbar und können einmal innerhalb von 24 Stunden erstellt werden.