Vercel ist die bequemste Art, eine Next.js-Anwendung zu betreiben — und die teuerste in einer Währung, die auf keiner Rechnung steht: Souveränität. Wer dort deployt, übergibt Applikation und Nutzerdaten in den Geltungsbereich von US-Recht. Das ist kein Skandal, sondern eine Designentscheidung, die zu wenige Entscheider bewusst treffen.
Der Reflex, Next.js und Vercel als untrennbares Paket zu denken, ist Marketing, kein Fakt. Next.js ist ein Open-Source-Framework unter MIT-Lizenz. Vercel ist das Unternehmen dahinter und betreibt eine Managed-Plattform mit exzellenter Developer Experience. Beides hängt zusammen, ist aber nicht dasselbe. Sie können Next.js auf eigener Infrastruktur in Deutschland betreiben, mit fast allen Features und sehr ähnlicher Performance. Die Frage ist nicht, ob das technisch geht — es geht offiziell und dokumentiert. Die Frage ist, ob Sie die Betriebsverantwortung tragen wollen, die der Komfort von Vercel Ihnen abnimmt.
Warum bei Next.js auf Hetzner statt Vercel die Jurisdiktion zählt, nicht die Zertifizierung
Vercel läuft primär auf AWS in rund zwanzig Regionen, und der Default-Standort der Vercel Functions ist die USA. Das Unternehmen ist nach dem EU-U.S. Data Privacy Framework zertifiziert, nutzt Standardvertragsklauseln samt UK Addendum und hält SOC 2 Type 2 sowie ISO 27001. Das alles ist real und nicht wertlos. Es löst nur nicht das Problem, das es zu lösen vorgibt.
Denn das Problem ist nicht die Verschlüsselung im Transit oder das Auditlevel des Rechenzentrums. Das Problem ist die Reichweite des Rechts. Vercel ist ein US-Unternehmen und bleibt damit US-Recht unterworfen, einschließlich des CLOUD Act. Der erlaubt US-Behörden, von amerikanischen Anbietern die Herausgabe von Daten zu verlangen — unabhängig davon, wo diese Daten physisch liegen. Eine DPF-Zertifizierung und SCCs adressieren den Transfer von Daten, nicht die Jurisdiktion über den Anbieter. Das ist ein kategorialer Unterschied, den juristische Hochglanzbroschüren gern verwischen.
Die Zertifizierungen sind dokumentiert und belegbar; die Jurisdiktionsfrage ergibt sich aus der allgemeinen Rechtslage, die wir an anderer Stelle ausführlicher behandeln. Für eine Marketing-Landingpage ohne personenbezogene Daten ist das alles irrelevant. Für ein System, das Kundendaten, Gesundheitsdaten oder Geschäftsgeheimnisse verarbeitet, ist es der entscheidende Punkt — besonders im Lichte von NIS2 und steigenden Anforderungen an Datenlokalisierung. Wer hier mit "aber wir sind ja DPF-zertifiziert" argumentiert, hat die Frage nicht verstanden oder hofft, dass der Datenschutzbeauftragte sie nicht stellt.
Was Next.js self-hosted tatsächlich kann
Die größte Fehlannahme bei diesem Thema lautet, Self-Hosting koste die halbe Feature-Liste. Das stimmt nicht, und die offizielle Dokumentation ist hier eindeutig. Node.js-Server und Docker unterstützen alle Next.js-Features; lediglich der reine Static Export ist eingeschränkt. Der empfohlene Build-Pfad ist output: 'standalone' — ein schlankes, in sich geschlossenes Artefakt, das ohne den vollständigen Node-Modules-Ballast in einen Container wandert.
Die beiden Features, um die sich die meisten Sorgen ranken, sind in der Praxis unspektakulär. Die Bildoptimierung über next/image läuft self-hosted mit Zero-Config über next start, weil Next.js intern sharp nutzt; nur Edge-Cases wie glibc-Memory-Tuning brauchen Handarbeit. Auch Middleware beziehungsweise die ab Version 16 in proxy umbenannte Konvention läuft self-hosted ohne Konfiguration. Was Sie verlieren, ist nicht die Funktion, sondern ihre global verteilte Ausführung auf einem Edge-Netzwerk. Das ist ein Performance-Detail, kein Funktionsverlust — und für die allermeisten DACH-Anwendungen mit europäischer Nutzerbasis ein Detail, das im Rauschen verschwindet.
Der genuin schwierige Teil ist ein anderer, und ich nenne ihn bewusst beim Namen, weil ehrliche Architektur hier den Unterschied macht. Incremental Static Regeneration funktioniert automatisch nur, solange Sie eine next start-Instanz mit persistentem Disk betreiben. Sobald Sie horizontal über mehrere Instanzen hinter einem Load Balancer skalieren, brauchen Sie einen Custom cacheHandler — typischerweise auf Redis oder S3 — plus koordinierte Cache-Tags, einen geteilten Encryption-Key für Server Actions und eine stabile deploymentId. Genau das ist das Kernwertangebot von Vercel, das sich nicht trivial nachbauen lässt. Für eine Single-Instance mit ordentlicher Vertikal-Skalierung — und ein Hetzner AX41 ist erstaunlich groß — stellt sich diese Frage gar nicht erst.
Hetzner, Coolify und Docker: der konkrete Stack
So bauen wir das. Ein Hetzner-Dedicated-Server, etwa ein AX41 für rund 39 bis 49 Euro im Monat, in einem deutschen Rechenzentrum, DSGVO-konform und ohne Drittstaatentransfer. Darauf Coolify, eine Apache-2.0-lizenzierte Open-Source-Plattform, die das übernimmt, was Vercel im Alltag so angenehm macht: git-push-Deploys, PR-Preview-URLs, automatisches SSL über Let's Encrypt und Zero-Downtime-Deploys. Next.js wird als Standard-Docker-Image gebaut, output: 'standalone', und läuft als Container.
Eine Einordnung gehört dazu: Coolify ist kein Next.js-Adapter. Es baut und betreibt schlicht den Standard-Docker-Build und erbt damit die Zusicherung der Next.js-Doku, dass Docker alle Features unterstützt. Der Cache-Handler und die Infrastruktur dahinter bleiben in Ihrer Verantwortung — was bei einer Single-Instance, wie gesagt, keine ist. Die Kostenrelation zu Vercel wird in Vergleichsblogs gern mit zehn bis zwanzig Prozent angegeben; das ist eine grobe, stark setup-abhängige Faustregel, kein Benchmark. Belastbar ist die Richtung, nicht die Dezimalstelle.
Die ehrliche Gesamtrechnung sieht so aus. Die saubere Erstimplementierung eines self-hosted Stacks veranschlagen wir einmalig mit 5.000 bis 20.000 Euro, je nach Komplexität. Der laufende Betrieb liegt bei 2 bis 5 Stunden im Monat für Updates, Monitoring und Backups. Den Einstieg gibt es ab 20 bis 50 Euro im Monat; wer Hochverfügbarkeit mit redundanten Instanzen und separater Datenbank braucht, landet bei einigen hundert Euro. Dem steht Vercel Pro mit 20 US-Dollar pro Nutzer und Monat gegenüber, plus Overages für Build-Minuten und Transfer; SAML SSO ist ein kostenpflichtiges Add-on, Enterprise hat keinen öffentlichen Listenpreis (Stand Mitte 2026, prüfen — Vercels Pricing ist hochvolatil). Die entscheidende Dynamik dahinter: Self-hosted Kosten sinken über die Zeit, weil das Setup steht. Managed-Kosten steigen mit dem Projekterfolg, weil Sie pro Erfolg zahlen. Wer das übersieht, trifft Hosting-Entscheidungen nach dem Demo-Preis statt nach der Drei-Jahres-Kurve.
Ist die Developer Experience von Vercel nachbaubar?
Teilweise, und ich verteidige die Antwort nicht zu optimistisch. Coolify deckt die wichtigsten DX-Bausteine ab: Sie pushen auf einen Branch, ein Build startet, eine Preview-URL erscheint. Für den Alltag eines mittelgroßen Teams ist das nah genug an Vercel, dass der Wechsel nach zwei Wochen nicht mehr schmerzt. Auto-SSL und Zero-Downtime-Deploys sind gelöste Probleme, keine Bastelei.
Was Sie nicht eins zu eins bekommen, ist die Tiefe des Vercel-Ökosystems: das nahtlose globale Edge-Network, die granularen Analytics, die in den Workflow eingebauten Speed Insights, das reibungslose Zusammenspiel von Edge Functions und ISR über Regionen hinweg. Diese Dinge sind real besser auf Vercel, und es wäre unredlich, das zu bestreiten. Der Punkt ist nicht, dass Vercel schlecht wäre — Vercel ist exzellent. Der Punkt ist, dass dieser Komfort eine Gegenleistung verlangt, die nicht in Dollar bezahlt wird, sondern in der Kontrolle über Ihre Daten und in einem Vendor-Lock-in, der sich leise aufbaut. Dasselbe Muster sehen wir bei Datenbanken: Supabase oder Firebase ist im Kern dieselbe europäische Souveränitätsfrage, nur eine Ebene tiefer im Stack. Wer Frontend und Daten konsequent denkt, beantwortet beide Fragen gleich.
Der unbequeme Punkt: Self-Hosting ist Betriebsverantwortung
Jetzt der Teil, den Berater gern überspringen, weil er die These kompliziert. Self-Hosting verschiebt Verantwortung, es eliminiert sie nicht. Vercel patcht für Sie, skaliert für Sie, hält die Edge für Sie warm. Übernehmen Sie das selbst, übernehmen Sie es wirklich: Coolify-Updates einspielen, das Betriebssystem härten, Backups testen — nicht nur einrichten, sondern wiederherstellen üben — und im Skalierungsfall den Cache-Handler korrekt aufsetzen.
Und einige Dinge sind tatsächlich schwer. Vercels Edge Functions laufen an dutzenden Standorten gleichzeitig; das bauen Sie auf einem deutschen Server nicht nach, und für globale Nutzerbasen mit Latenzanspruch ist das ein echter Nachteil. Der Multi-Instance-ISR-Fall, oben beschrieben, ist Ingenieursarbeit, die schiefgehen kann, wenn man die Tag-Koordination und die geteilten Keys unterschätzt. Wer eine Anwendung mit globalem Publikum und harten Latenzzielen betreibt und intern keine Ops-Kapazität hat, kauft mit Vercel berechtigt Aufwand zurück. Das ist keine Kapitulation, sondern eine saubere Make-or-Buy-Entscheidung. Run-the-Business-Aufgaben, die niemand bei Ihnen tragen kann oder will, gehören ausgelagert — solange Sie wissen, was Sie damit auslagern.
Der Fehler ist nicht, Vercel zu wählen. Der Fehler ist, Vercel zu wählen, ohne die Souveränitätsfrage gestellt zu haben, und dann überrascht zu sein, wenn der Datenschutzbeauftragte oder ein NIS2-Audit sie für Sie stellt. Eine bewusste Make-or-Buy-Entscheidung mit offenem Visier ist immer verteidigbar. Eine Default-Entscheidung, die man nie getroffen hat, ist es nie.
Was ich Entscheidern rate
Trennen Sie die zwei Fragen, die Vercel bewusst verschmilzt: Wollen Sie Next.js? Und wollen Sie Vercel als Betreiber? Die erste Antwort ist oft ja — Next.js ist ein hervorragendes Framework, und warum es als technologisches Fundament trägt, haben wir an anderer Stelle vollständig aufgeschlüsselt. Die zweite Antwort hängt allein an Ihrem Datenschutzanspruch und Ihrer Ops-Kapazität, nicht am Framework.
Verarbeiten Sie sensible Daten, unterliegen Sie NIS2, haben Sie einen Datenschutzbeauftragten, der seinen Job ernst nimmt — dann ist self-hosted auf Hetzner mit Coolify und Docker keine exotische Option, sondern die naheliegende Antwort. Der Stack ist erprobt, die Kosten sind kalkulierbar und sinken, die Performance ist für europäische Nutzerbasen praktisch nicht von Vercel zu unterscheiden. Was Sie aufgeben — Edge-Komfort und ein Stück DX-Glätte — ist benennbar und planbar.
Haben Sie kein Ops-Team, kein sensibles Datenmodell und ein globales Publikum mit harten Latenzzielen, dann ist Vercel die ehrlich bessere Wahl, und ich würde Sie nicht davon abbringen. Nur treffen Sie diese Entscheidung dann aktiv. Eine Technologieentscheidung ist immer auch eine Entscheidung über Macht und Abhängigkeit. Wer sie dem Default überlässt, kauft die Interessen seines Dienstleisters mit — und merkt es erst, wenn der Ausstieg teuer wird.
