Vercel-Alternative 2026: 6 Anbieter für Next.js und KI-Apps

Welche Vercel-Alternative passt, hängt davon ab, was dauerhaft laufen muss: Cloudflare Workers und Pages für statische Websites oder Edge-Anwendungen, Render oder Railway für dauerhaft laufende Full-Stack-Dienste und Netlify für einen verwalteten Next.js-Workflow. Zu den 6 Anbietern im Vergleich gehören außerdem Fly.io für mehr Kontrolle über die Infrastruktur und AWS Amplify für kompatible Apps, die bereits auf AWS setzen. Läuft die App gut und stört allein die Rechnung, lohnt sich vor dem Umzug ein Blick auf Vercels aktuelle Abrechnung und Ausgabenkontrollen.

Preise und dokumentierte Funktionen wurden am 3. November 2026 anhand der aktuellen Anbieterseiten geprüft. Der Vergleich beruht auf der Dokumentation; ein Deployment-Benchmark wurde nicht durchgeführt. Die Empfehlungen unterscheiden zwischen Code, der sich mitnehmen lässt, und Hosting-Verhalten, das am neuen Standort ersetzt werden muss.

Die passende Vercel-Alternative im Überblick

Für eine dauerhaft laufende Full-Stack-App steht Render zunächst ganz oben auf der Auswahlliste; für statische Websites und kompatible Edge-Anwendungen führt Cloudflare. Netlify gehört dazu, wenn ein verwalteter Next.js-Veröffentlichungsprozess wichtiger ist als ein klassischer Server.

Die Einstiegspreise decken unterschiedliche Leistungen ab. Eine kleine virtuelle Maschine, ein Guthabenkontingent und eine Build-Minute ergeben keine vergleichbaren Produktionsumgebungen. Alle Preise sind in USD angegeben; Nutzung, weitere Dienste und gegebenenfalls Steuern können die Rechnung erhöhen.

Erst die Laufzeitumgebung wählen, dann den Anbieter

Zuerst muss feststehen, welche Arbeit das Hosting übernehmen soll. Erst dann lohnt sich der Anbietervergleich innerhalb dieser Kategorie. Eine statische Website liefert bereits erzeugte Dateien aus. Beim serverseitigen Rendering, kurz SSR, entsteht die Antwort erst mit der Anfrage. Ein dauerhaft laufender Dienst steht für die Ausführung von Anwendungscode bereit; ein Hintergrund-Worker verarbeitet Aufgaben unabhängig von der Anfrage des Besuchers.

Wer eine Marketingwebsite und ein KI-Produkt betreibt, hat es möglicherweise mit ganz unterschiedlichen Anforderungen zu tun. Die Marketingseiten können statisch sein. Der Chat-Endpunkt muss Antworten streamen. Für den Dokumentenimport kann ein separater Worker nötig sein, der weiterarbeitet, nachdem der Kunde den Browser geschlossen hat.

Die entscheidende Weichenstellung: Geht es um das Ausliefern von Dateien, gehört Cloudflare in die engere Wahl. Soll ein verwaltetes Next.js-Deployment erhalten bleiben, kommt Netlify infrage. Braucht die App einen laufenden Prozess und Hintergrundverarbeitung, sind Render oder Railway die ersten Kandidaten. Fly.io wird interessant, wenn Betriebsregion und Infrastrukturkontrolle zu den Anforderungen gehören. Für Amplify sprechen eine wichtige AWS-Anbindung und eine passende Kompatibilitätsliste.

Das ist eine erste Eingrenzung. Daraus folgt nicht, dass Edge-Plattformen keine Hintergrundabläufe ausführen können. Bei einer bestehenden App zählt der Aufwand: Wie viel Arbeit erfordert die Übernahme des separaten Job-Systems einer Plattform, verglichen mit dem Betrieb des vorhandenen Workers als Dienst?

Cloudflare Workers und Pages: Für statische Websites und Edge-Anwendungen

Cloudflare Workers führt Code zur Anfrageverarbeitung im Netzwerk von Cloudflare aus. Für eine schlanke App, deren Abhängigkeiten zur Laufzeitumgebung passen, ist die Plattform der stärkste Ausgangspunkt. Besonders attraktiv ist sie, wenn die App hauptsächlich Dateien ausliefert, die Authentifizierung prüft und externe APIs aufruft. Bei einer bestehenden Next.js-Anwendung muss allerdings erst ein kompatibler Deployment-Weg gewählt werden. Ein bloßer Wechsel des Hosting-Ziels reicht nicht.

Cloudflare empfiehlt derzeit vinext, eine Beta-Implementierung der Next.js-APIs auf Basis des JavaScript-Build-Tools Vite. Unterstützt werden laut Funktionsliste der App Router, Server Actions, SSR mit Streaming und Incremental Static Regeneration, kurz ISR. ISR aktualisiert zwischengespeicherte Seiten, ohne die gesamte Website neu zu bauen. Bei einigen Imports und beim Verhalten der Bildverarbeitung muss die Kompatibilität weiterhin geprüft werden. Für eine Migration im Produktivbetrieb bleibt der Beta-Status ein Entscheidungskriterium, selbst wenn die Funktionsliste gut aussieht. Cloudflares Next.js-Anleitung.

Der andere relevante Weg führt über OpenNext, einen Adapter, der einen Next.js-Build an eine andere Plattform anpasst. Cloudflare dokumentiert ihn für bestehende OpenNext-Anwendungen. Streaming und ISR werden unterstützt; Node.js-Middleware bleibt laut Kompatibilitätsübersicht ausgeschlossen. Middleware ist Code, der ausgeführt wird, bevor eine Anfrage die Seite erreicht. Ist die eigene Middleware auf diese Laufzeitumgebung angewiesen, muss diese Unvereinbarkeit geklärt sein, bevor DNS-Einstellungen geändert werden. Cloudflares OpenNext-Unterstützung.

Cloudflare Pages passt zum einfacheren Fall: einer Next.js-App, die sich statisch exportieren lässt. Die dokumentierte Voreinstellung erzeugt Dateien im Verzeichnis out und bietet Git-basierte Neubuilds sowie Vorschauen. Ein statischer Export erhält weder Server Actions zur Anfragezeit noch ISR. Ein aktives Anwendungsbackend muss separat betrieben werden. Anleitung für statisches Next.js auf Pages, Grenzen des Next.js-Exports.

Abrechnung: Workers erfasst Anfragen und CPU-Nutzung. Für weitere eingesetzte Dienste gelten eigene Verbrauchszähler. Das Warten auf eine Netzwerkantwort verbraucht keine Worker-CPU-Zeit. Für einen KI-Endpunkt, der auf ein Modell wartet, kann das relevant sein. Der Modellaufruf und der übrige Stack werden dadurch allerdings nicht kostenlos. Direkt ausgelieferte statische Dateien werden anders abgerechnet als Datenverkehr, der durch einen Worker oder Workers Caching läuft. Workers-Preise, Laufzeitlimits.

Geeignet für: Statische Websites, schlanke API-Frontends und Edge-kompatible Next.js-Apps.
Besonderheit: Statische Auslieferung und Servercode können im selben Plattformökosystem bleiben.
Preise: Workers Free $0; Workers Paid ab $5/Monat, zuzüglich Nutzung oberhalb der enthaltenen Kontingente. Preise beim Anbieter.
Kostenlos testen: Ein dauerhafter Free-Tarif statt einer ausschließlich befristeten Testphase.

Fazit: Cloudflare passt, wenn die Kompatibilität nachgewiesen ist und die Anwendung von diesem Auslieferungsmodell profitiert. Ein günstiger Einstiegspreis allein rechtfertigt keine Framework-Migration.

1. 1

   Kompatibilität des Produktivstands prüfen

   Auf einem Migrationsbranch den von Cloudflare dokumentierten Ablauf mit npx vinext check ausführen und die Ergebnisse prüfen. Den unterstützten Weg mit der tatsächlich verwendeten Middleware, Bildverarbeitung und den Serverabhängigkeiten abgleichen.

2. 2

   Geschäftskritische Abläufe durchspielen

   Eine Vorschau bereitstellen und Anmeldung, authentifizierte Seitenaufrufe, eine Server Action, einen KI-Stream und die Revalidierung von Inhalten prüfen. Ein erfolgreicher Build ist erst der Anfang dieses Abnahmetests.

3. 3

   Den kleineren Migrationsaufwand wählen

   Für einen echten statischen Export eignet sich Pages. Für Code, der bei einer Anfrage ausgeführt wird, braucht es einen kompatiblen Workers-Weg. Übersteigen die nötigen Adapteranpassungen den Nutzen, sollte vor der Umleitung des Produktivverkehrs ein klassisches Node-Deployment verglichen werden.

Render: Für dauerhaft laufende Apps und Hintergrund-Worker

Render ist eine verwaltete Plattform für Webdienste, Worker und Datenbanken. Wenn eine KI-App einen klassischen Server braucht, steht Render bei mir zunächst ganz oben auf der Auswahlliste. Ein Produkt zur Dokumentenanalyse kann seinen Next.js-Webdienst getrennt von dem Worker betreiben, der Uploads verarbeitet. So lässt sich der Eingang eines Auftrags bestätigen, ohne den Besucher auf dessen vollständige Verarbeitung warten zu lassen.

Was von Next.js erhalten bleibt: Laut Render-Dokumentation lässt sich eine vollständige Next.js-Anwendung als Node.js-Webdienst betreiben, ein statischer Export als statische Website. Über den Node-Weg bleibt der Servercode des Frameworks erhalten. Wie Laufzeitcache, Deployment-Verhalten und zusätzliche Prozesse zusammenarbeiten, muss das Anwendungsteam festlegen. Next.js auf Render bereitstellen.

Beim Skalieren wird diese Unterscheidung sichtbar. ISR ermöglicht es, eine Seite zu aktualisieren und wiederzuverwenden. Unabhängige Serverinstanzen teilen das aktualisierte Ergebnis dadurch aber nicht automatisch. Ein Deployment mit Replikaten braucht eine Cache-Strategie und eine abgestimmte Invalidierung: Jede Instanz muss erfahren, dass gespeicherte Inhalte veraltet sind. Next.js beschreibt diese Aufgaben in der Dokumentation zum Self-Hosting. Next.js-Anleitung zum Self-Hosting.

Abrechnung: Workspace-Tarif und Rechenressourcen der einzelnen Dienste werden getrennt berechnet. Webserver, Worker und Datenbanken sind eigenständige Ressourcen; auch für Bandbreite und Builds gelten Kontingente und gegebenenfalls Mehrverbrauchskosten. Der Einstiegspreis eines kostenpflichtigen Webdienstes deckt deshalb keine komplette Kombination aus Web-App, Worker und Produktionsdatenbank ab. Render-Preise.

Der kostenlose Dienst eignet sich für eine Migrationsvorschau, wechselt aber nach 15 Minuten ohne eingehenden Datenverkehr in den Ruhemodus. Bei einer KI-App für Kunden sollte eine ruhige Phase nicht zu einer unerwarteten Aufwachverzögerung für den nächsten Nutzer führen. Wenn die App jederzeit bereitstehen muss, gehören kostenpflichtige Rechenressourcen ins Budget. Einschränkungen von Render Free.

Eine weitere praktische Hürde betrifft den Build: Render bewahrt das Next.js-Verzeichnis .next/cache nicht automatisch auf. Die Anleitung erklärt, wie sich der Build-Cache über Renders persistenten Speicherort für Build-Caches wiederverwenden lässt. Dieser Cache ist vom Laufzeitcache für ausgelieferte Seiten zu unterscheiden. Die Konfiguration des einen richtet den anderen nicht mit ein.

Geeignet für: Eine Next.js-App mit dauerhaft laufenden Diensten, Hintergrundaufgaben oder einem separat bereitgestellten Backend.
Besonderheit: Webdienste und Hintergrund-Worker sind ausdrücklich eigene Deployment-Typen.
Preise: Kostenlose Rechenressourcen sind verfügbar; kostenpflichtige Web-Rechenressourcen beginnen bei $7/Monat für 512 MB, zuzüglich etwaiger Workspace-Gebühren und weiterer Ressourcen. Preise beim Anbieter.
Kostenlos testen: Ein Free-Tarif mit Webdiensten im Ruhemodus; keine gleichwertige, jederzeit bereite Produktionsumgebung.

Fazit: Render ist eine gute Wahl, wenn ein dauerhaft laufendes Backend den Wechsel von Vercel begründet. Die erste Migration sollte überschaubar bleiben: die vorhandene App als Webdienst bereitstellen, prüfen und anschließend den Job-Prozess separat umziehen. Wer zugleich die App neu schreibt und die Datenbank wechselt, erschwert die Eingrenzung von Fehlern.

Railway: Für den schnellen Aufbau einer kleinen Full-Stack-App

Railway bündelt Dienste und ihre Verbindungen in Projekten. Die Deployment-Plattform passt gut zu einem kleinen Team, das App, Datenbank und Worker gemeinsam aufbaut. Besonders hilfreich ist sie, wenn die Verbindungen zwischen diesen Bausteinen sichtbar sein sollen und das Team sie zusammen weiterentwickeln möchte. Der wichtigste Abwägungspunkt ist der variable Ressourcenverbrauch. Auf das schnelle Deployment sollte deshalb ein bewusster Blick auf die laufenden Kosten folgen.

Was von Next.js erhalten bleibt: Railways Anleitung beschreibt Deployments über GitHub, die CLI oder ein Dockerfile. Der Next.js-Workflow nutzt eine Standalone-Ausgabe, also einen Build mit den für den Serverbetrieb nötigen Dateien. Außerdem zeigt er die PostgreSQL-Anbindung über eine referenzierte DATABASE_URL. Ein vor dem Deployment ausgeführter Befehl für Datenbankmigrationen wird ebenfalls unterstützt. Railways Next.js-Anleitung.

Für eine KI-Recherche-App ergibt sich daraus eine sinnvolle Aufteilung: Der Webdienst übernimmt Oberfläche und Anfragen, ein weiterer Dienst die Importe, PostgreSQL die dauerhaft gespeicherten Anwendungsdaten. Dienstreferenzen erleichtern die Verbindung. Was bei einem erneuten Importversuch oder einer Änderung des Datenbankschemas während eines Deployments geschieht, muss trotzdem festgelegt werden.

Abrechnung: Das Abonnement legt einen Mindestumsatz fest, der Ressourcenverbrauch in gleicher Höhe abdeckt. Es handelt sich nicht um eine Abogebühr, die zusätzlich zu jedem Dollar Rechenleistung anfällt. Oberhalb des enthaltenen Betrags bestimmt der Ressourcenverbrauch die Rechnung. Arbeitsspeicher, CPU, Volumes und ausgehender Datenverkehr eines Dienstes werden getrennt erfasst. Railway-Preise, Preise für Ressourcen.

Der entscheidende Haken: Auch eine gerade ungenutzte App kann laufende Ressourcen haben. Ein Webprozess, der Arbeitsspeicher belegt, eine Datenbank und ein Worker sind von der Besucherzahl unabhängig. Wenige Seitenaufrufe machen daher nicht automatisch das gesamte Projekt günstig. Für den Vergleich zählt der Ressourcenbedarf aller Dienste, die weiterlaufen sollen, einschließlich der Vorschauumgebungen.

Was sich gegenüber Vercel ändert: Mit Railway fällt die Wahl auf den Node- beziehungsweise Container-Weg. Wie die einzelnen Framework-Funktionen bereitgestellt werden, übernimmt dann nicht mehr Vercel. Bei zusätzlichen Replikaten muss die Next.js-Cache-Koordination geplant werden. Gestreamte Antworten sind über den öffentlichen Endpunkt zu prüfen; außerdem muss klar sein, wo Uploads ein Deployment überdauern. Das Framework kann umziehen, die Annahmen über den Produktivbetrieb müssen überprüft werden.

Geeignet für: Kleine Teams, die App, Datenbank und Hintergrunddienst gemeinsam entwickeln.
Besonderheit: Verknüpfung von Diensten auf Projektebene und ein dokumentierter Ablauf für Datenbankmigrationen.
Preise: Hobby beginnt bei $5/Monat einschließlich $5 Ressourcenverbrauch; zusätzliche Nutzung wird berechnet. Preise beim Anbieter.
Kostenlos testen: $5 Testguthaben, das nach 30 Tagen verfällt. Testbedingungen auf der Preisseite.

Fazit: Railway eignet sich für ein kleines Full-Stack-Projekt, das schnell aufgebaut und verändert werden soll. Stehen nur noch diese containerorientierten Plattformen zur Wahl, vertieft der Vergleich Railway vs. Render die Entscheidung.

Netlify: Verwaltetes Next.js-Hosting mit vertrautem Workflow

Netlify ist eine verwaltete Plattform für Webdeployments. Für Teams, die Vorschauen und einen betreuten Next.js-Veröffentlichungsprozess beibehalten möchten, kommt sie dem gesuchten Modell in diesem Vergleich am nächsten. Eine inhaltsreiche SaaS-Website mit geschützten Seiten ist ein überzeugenderer Einsatzgrund als der Wunsch, einen beliebigen dauerhaften Worker zu betreiben. Netlify unterstützt Next.js umfassend; der gemeinsame Credit-Pool und der Ausführungsort des Codes verdienen aber einen genauen Blick.

Was von Next.js erhalten bleibt: Netlifys OpenNext-Adapter unterstützt den App Router, SSR, ISR, React Server Components, Server Actions, das Streaming von Antworten, Bildoptimierung und Cache Components. Das sind wesentliche Funktionen: Eine Migration bedeutet also nicht automatisch, auf serverseitiges Rendering oder das Streamen einer KI-Antwort zu verzichten. Netlifys Next.js-Unterstützung.

Was sich ändert: Next.js-SSR-Seiten, die für die Edge-Laufzeit konfiguriert sind, laufen bei Netlify mit Node.js in der Functions-Region. Eine Edge-Einstellung erhält also nicht zwangsläufig den bisherigen Ausführungsort. Netlify dokumentiert außerdem Unterschiede in der Ausführungsreihenfolge von Middleware. Dateisystemzugriffe und C++-Addons sind in Node.js-Middleware ausgeschlossen. Diese Einschränkungen sind besonders relevant, wenn Authentifizierung oder Anfrage-Routing davon abhängen.

Wenn Kunden die App während eines Deployments aktiv nutzen, ist Skew Protection einen Blick wert: Sie hält eine Browsersitzung bei der Serverversion, mit der sie begonnen hat. Netlify bietet die Funktion zur optionalen Aktivierung an. Laut Dokumentation übertragen gewöhnliche fetch-Aufrufe des Clients die Deployment-Kennung allerdings nicht automatisch. Eigene API-Aufrufe brauchen daher besondere Aufmerksamkeit. Die Funktion hilft, ersetzt aber nicht die Prüfung der eigenen Anfragewege. Details zu Kompatibilität und Skew Protection.

Abrechnung: Produktivdeployments, Rechenleistung, Bandbreite und Anfragen verbrauchen Credits; weitere Plattformdienste können ebenfalls darauf zugreifen. Eine Inhaltswebsite mit häufigen Deployments und großen Dateien nutzt das Kontingent anders als eine wenig besuchte App mit serverseitiger Verarbeitung. Netlify erfordert deshalb eine Kalkulation des tatsächlichen Lastprofils und senkt Kosten nicht automatisch. Netlify-Preise.

Kostenloses Netlify-Hosting: Das Credit-Limit entscheidet über die Verfügbarkeit

Die entscheidende Grenze des kostenlosen Tarifs zeigt sich, wenn die Credits aufgebraucht sind. Laut Netlifys Preis-FAQ werden Projekte dann pausiert. Überschreitet ein Projekt seine Limits, können sämtliche Projekte des Kontos pausiert werden. In kostenpflichtigen Tarifen lässt sich Guthaben automatisch nachladen; standardmäßig ist das deaktiviert. Es braucht eine bewusste Entscheidung: Sollen zusätzliche Ausgaben verhindert werden oder soll der Dienst auch bei einer Verkehrsspitze weiterlaufen?

Für Gründer ist das eine konkrete Frage: Darf ein unerwarteter Besucheransturm nach einem Launch auf der Marketingwebsite die App unterbrechen, die dasselbe Konto nutzt? Bevor Anwendungen zusammengelegt werden, sollten Kontostruktur und Credit-Regeln geprüft werden.

Geeignet für: Teams, die verwaltete Next.js-Deployments und ihre Prüfabläufe beibehalten möchten.
Besonderheit: Breite Framework-Unterstützung über den OpenNext-Adapter sowie Deployment-Vorschauen.
Preise: Free beginnt bei $0/Monat mit 300 Credits; für kostenpflichtige Tarife und Mehrverbrauch gilt die aktuelle Credit-Staffel. Preise beim Anbieter.
Kostenlos testen: Ein dauerhafter Free-Tarif mit monatlichem Kontingent.

Fazit: Netlify gehört in die engere Wahl, wenn der Deployment-Workflow erhalten bleiben soll. Für die abschließende Gegenüberstellung hilft der Vergleich Vercel vs. Netlify. Bevor eine Ersparnis geschätzt wird, muss der aktuelle Kontotarif feststehen.

Fly.io: Für Container mit Kontrolle über die Betriebsregion

Fly.io betreibt Anwendungen in virtuellen Maschinen namens Machines. Die Plattform eignet sich für Entwickler, die den Standort ihrer containerisierten App selbst bestimmen möchten. Konkrete Anforderungen an die regionale Platzierung sprechen stärker für Fly.io als der Wunsch nach möglichst wenig Betriebsaufwand. Entscheidend ist, ob die Daten der App derselben Standortstrategie folgen können.

Was von Next.js erhalten bleibt: Fly.io dokumentiert ein Next.js-Deployment mit fly launch, einem erzeugten Dockerfile und einer fly.toml-Konfiguration. Für die Zusammenstellung der Laufzeitdateien wird die Standalone-Ausgabe empfohlen. Das ergibt ein klassisches Serverdeployment mit direkterer Kontrolle über die Umgebung. Next.js-Anleitung von Fly.io.

Eine klassische Laufzeitumgebung klärt noch nicht jedes Migrationsdetail. Öffentliche Next.js-Umgebungsvariablen werden beim Build festgeschrieben. Eine Änderung der Produktionseinstellungen kann deshalb einen neuen Build erfordern. Mehrere Machines brauchen außerdem aufeinander abgestimmte Framework-Caches und Deployment-Stände. Diese technischen Aufgaben sind lösbar, gehören aber in die Aufwandsschätzung für den Umzug.

Ein Beispiel ist eine App, deren Kunden weit von der Datenbank entfernt sind. Selbst wenn der Webprozess näher an die Kunden rückt, kann jede Seite weiterhin auf eine entfernte Datenbankabfrage warten. Die Regionswahl muss den gesamten Anfrageweg berücksichtigen. Mehr App-Standorte auf einer Karte belegen für sich genommen noch keine schnellere Nutzererfahrung.

Abrechnung: Die Rechenleistung einer Machine wird während ihrer Laufzeit berechnet; Größe und Region bestimmen den Preis mit. Volumes, ausgehender Netzwerkverkehr und weitere Ressourcen kommen separat hinzu. Die kleinste angezeigte Monatsschätzung ist eine Preisuntergrenze für wenig Rechenleistung, keine Empfehlung für den Speicherbedarf einer Next.js-App. Gespeicherte Ressourcen können auch dann weiter Kosten verursachen, wenn ein Prozess stoppt. Fly.io-Preise.

Die wichtigste Einschränkung für Anwendungen mit lokalem Zustand: Volumes werden nicht automatisch repliziert. Ein Volume ist lokaler Speicher an einer Machine, keine weltweit synchronisierte Datenbank. Wer Zustand lokal speichert, muss Replikation und Wiederherstellung im Anwendungs- oder Datenbankkonzept vorsehen. Volume-Dokumentation von Fly.io.

Geeignet für: Entwickler, die Betriebsregion und Container gezielt kontrollieren müssen.
Besonderheit: Ein dokumentierter Next.js-Container-Weg mit ausdrücklicher Infrastrukturkonfiguration.
Preise: Die kleinste angezeigte Machine mit 256 MB beginnt bei umgerechnet $2.19/Monat; regionale Preise, größere Maschinen, Speicher und Datenverkehr verändern die Gesamtsumme. Preise beim Anbieter.
Kostenlos testen: Der Test endet nach insgesamt 2 VM-Stunden oder 7 Tagen, je nachdem, was zuerst eintritt. Fly.io-Testphase.

Fazit: Fly.io lohnt sich, wenn die gebotene Kontrolle gebraucht wird. Wer sich möglichst wenig mit Infrastruktur beschäftigen möchte, überlässt die damit verbundene Arbeit möglicherweise lieber einem anderen Anbieter.

AWS Amplify: Für kompatible Apps in einem bestehenden AWS-Stack

AWS Amplify ist das Angebot von Amazon Web Services für Anwendungsentwicklung und Hosting. Es passt zu Unternehmen, die bereits AWS-Dienste nutzen und deren Next.js-Funktionen vom Hosting unterstützt werden. Sind Authentifizierung, Daten und Speicher ohnehin Teil dieses Stacks, kann die Wahl organisatorisch sinnvoll sein. Bei einer KI-Anwendung mit Streaming muss die Kompatibilität allerdings Vorrang vor dem Komfort des gemeinsamen Ökosystems haben.

Was von Next.js erhalten bleibt: Die aktuelle Dokumentation von Amplify Hosting nennt die Next.js-Versionen 12 bis 15 für das Compute-basierte Hosting. Dazu gehören SSR, statische Seiten, API-Routen, ISR und Bildoptimierung. Das ist der dokumentierte Versionsbereich, keine Zusage für jede Version, mit der eine App gerade läuft. Next.js-Unterstützung von Amplify.

Was wegfällt: Dieselbe Dokumentation führt Next.js-Streaming, On-Demand-ISR und Edge-API-Routen als nicht unterstützt auf. On-Demand-ISR erlaubt es, zwischengespeicherte Inhalte als Reaktion auf ein Ereignis für ungültig zu erklären, etwa wenn eine geänderte Produktbeschreibung veröffentlicht wird. Die Unterstützung von zeitgesteuertem oder gewöhnlichem ISR bedeutet nicht, dass auch dieses ereignisgesteuerte Verhalten funktioniert.

In einem Chatprodukt lässt Streaming den Text nach und nach erscheinen, statt erst die fertige Antwort anzuzeigen. Beruht eine vorhandene Next.js-Route auf diesem Verhalten, ist Amplify Hosting kein gleichwertiges Umzugsziel. Ein separat gehostetes Streaming-Backend wäre eine alternative Architektur, verlangt aber einen größeren Eingriff als den Import des Frontend-Repositories.

Abrechnung: Amplify erfasst Build-Minuten, gehosteten Speicher, Datenübertragung, SSR-Anfragen und SSR-Laufzeit. AWS-Backend-Dienste sind zusätzliche Ressourcen mit eigener Abrechnung. Die Preisseite nennt Integrationen wie Amazon Cognito für die Authentifizierung und Amazon S3 für Dateispeicher. Diese Dienste weiterzuverwenden kann sinnvoll sein; ihre Kosten gehen dadurch jedoch nicht in einem gemeinsamen Hosting-Abonnement auf. Amplify-Preise.

Betreibt das Team bereits AWS, können vertraute Zugriffskontrollen, klare Zuständigkeiten für die Abrechnung und vorhandene Backend-Dienste eine stärker aufgeteilte Rechnung aufwiegen. Für einen Einzelentwickler, der lediglich seine Vercel-Ausgaben senken möchte, besteht dieser organisatorische Vorteil möglicherweise nicht. Maßgeblich ist die benötigte Architektur, nicht die Breite des AWS-Katalogs.

Geeignet für: Unternehmen mit AWS-Schwerpunkt und einer kompatiblen Next.js-App.
Besonderheit: Hosting neben einem vorhandenen AWS-Backend und einer bestehenden Kontostruktur.
Preise: Standard-Builds beginnen bei $0.01/Minute; Hosting, SSR und Backend-Ressourcen werden separat erfasst. Preise beim Anbieter.
Kostenlos testen: Anspruch auf AWS Free Tier und Guthaben hängen vom Konto und den Anmeldebedingungen ab.

Fazit: Amplify kommt erst infrage, wenn seine Kompatibilitätsliste die Anforderungen der App erfüllt. Vorhandene AWS-Ausgaben sind ein Grund für die Prüfung, rechtfertigen aber keinen Verzicht auf eine benötigte Produktionsfunktion.

Wann es sinnvoller ist, bei Vercel zu bleiben

Vercel kann weiterhin die bessere Wahl sein, wenn die App gut läuft und lediglich eine unklare oder unkontrollierte Rechnung Probleme bereitet. Ein Anbieterwechsel verursacht Entwicklungsarbeit, birgt das Risiko neuer Fehler in bisher funktionierenden Abläufen und bringt zusätzliche Betriebsaufgaben mit sich. Diesem Aufwand sollte eine konkrete Verbesserung gegenüberstehen.

Vercel-Kosten: Vor der Migration den aktuellen Tarif prüfen

Ausgangspunkt sind die tatsächliche Rechnung und die aktuelle Übersicht der Vercel-Preise. Vercels aktuelle Preisgestaltung umfasst inzwischen eine Flat Rate CDN-Option im Pro-Tarif. Ein älterer Vergleich, der nur Auslieferungskosten pro Gigabyte berücksichtigt, kann deshalb von der falschen Rechnung ausgehen. Vor dem Alternativenvergleich muss klar sein, welcher Posten schmerzt: Auslieferung, Rechenleistung, Builds, Nutzerplätze oder ein separater Dienst. Vercels aktuelle Preise.

Spend Management unterstützt Benachrichtigungen, Webhooks und eine optionale Aktion, die sämtliche Produktivdeployments des Teams pausiert. Eine Warnung allein stoppt die Nutzung nicht. Durch die Pause können auch Kunden diese Apps nicht mehr erreichen. Zudem kann die Ausgabenprüfung dem Überschreiten des Grenzwerts um mehrere Minuten hinterherlaufen. Die Funktion kontrolliert Kosten mit Folgen für die Verfügbarkeit; sie ist keine sofort greifende, exakte Obergrenze. Vercel Spend Management.

Bleiben lohnt sich, wenn sich die teure Verarbeitung entfernen, zwischenspeichern oder in einen separaten Dienst auslagern lässt, ohne das Frontend umzuziehen. Ein Wechsel ist gerechtfertigt, wenn ein dauerhaft laufender Prozess, eine Einschränkung der Laufzeitumgebung oder eine bewusste Anforderung an die Portabilität den Aufwand begründet.

Kostenlose Vercel-Alternativen: Was die Kontingente tatsächlich leisten

Ein kostenloses Kontingent hilft bei der Eignungsprüfung, ersetzt aber keine Produktionsarchitektur. Bei Netlify können aufgebrauchte Credits Projekte pausieren. Renders Free-Webdienst wechselt in den Ruhemodus. Railway und Fly.io bieten begrenzte Testphasen. Bei AWS hängt der Anspruch von den Kontobedingungen ab. Cloudflares kostenlose Laufzeitumgebung hat Ausführungslimits, auch wenn die Kontingente für statische Auslieferung großzügig sind.

Die kostenlose Variante sollte klären, ob sich die App korrekt bauen lässt, ob Authentifizierung und Streaming funktionieren und ob sie sich nach Fehlern wiederherstellt. Anschließend muss der laufende Betrieb mit den Ressourcen kalkuliert werden, die die Produktion tatsächlich benötigt.

Vercel Free Tier und kostenlose Testphase haben unterschiedliche Aufgaben

Vercels Hobby-Tarif ist für die persönliche, nicht kommerzielle Nutzung vorgesehen. Eine Pro-Testphase ermöglicht die Prüfung der dafür freigegebenen Funktionen des kostenpflichtigen Tarifs; daraus entsteht kein dauerhafter Anspruch auf Produktivbetrieb. Ein kommerzielles Deployment sollte nicht mit einem kostenlosen Tarif verglichen werden, der den vorgesehenen Einsatz nicht abdeckt. Hinweise zu den Vercel-Tarifen.

So gelingt der Wechsel von Vercel ohne Ausfälle in der App

Zuerst sollte die teure oder inkompatible Verarbeitung umziehen. Die gesamte Anwendung folgt nur, wenn das ein größeres Problem löst. Eine KI-App kann ihr bestehendes Frontend behalten, während eine separate API Aufträge annimmt, eine Warteschlange offene Jobs vorhält und ein Worker sie verarbeitet. Dauerhafte Daten gehören außerhalb eines austauschbaren Anwendungsdeployments gespeichert.

Eine Queue ist eine Warteschlange, deren Einträge der Worker unabhängig von der Browseranfrage abarbeiten kann. Ein Upload kann beispielsweise eine Job-Kennung zurückgeben. Der Worker extrahiert den Text und speichert das Ergebnis; die App ruft später den Status ab. Dafür müssen nicht gleichzeitig sämtliche Marketingseiten und Anmeldeoberflächen umziehen.

Ein portables Repository ist nur ein Teil eines portablen Systems. Zur Bestandsaufnahme gehören anbieterspezifische Speicheraufrufe, Umgebungsvariablen, zeitgesteuerte Aufgaben, Authentifizierungs-Callbacks und Deployment-URLs. Es muss feststehen, welche Dienste bleiben, welche ersetzt werden und aus welchen Daten exportiert werden müssen. Ein anderer Frontend-Host übernimmt keinen dieser Umzüge automatisch.

1. 1

   Einen repräsentativen Ablauf auswählen

   Den geschäftlich wichtigen Weg durchspielen: anmelden, ein Dokument hochladen, die Verarbeitung starten, eine gestreamte Antwort erhalten und das gespeicherte Ergebnis erneut aufrufen. Das erwartete Verhalten festhalten, bevor das Hosting geändert wird.

2. 2

   Build-Einstellungen von Laufzeitgeheimnissen trennen

   Serverseitige Geheimnisse am Ziel neu hinterlegen und prüfen, welche öffentlichen Einstellungen beim Build eingebettet werden. Zugangsdaten der Produktionsumgebung gehören nicht in Migrationsvorschauen, sofern diese nicht ausdrücklich für ihre Nutzung freigegeben sind.

3. 3

   Streaming und Cache-Invalidierung prüfen

   Über die öffentliche URL prüfen, ob Antwortteile fortlaufend eintreffen. Inhalte ändern und kontrollieren, ob sich die vorgesehenen Seiten aktualisieren. Bei zusätzlichen Replikaten muss jede Instanz den aktualisierten Stand sehen. Next.js dokumentiert Proxy-Pufferung und Cache-Koordination als Aufgaben beim Self-Hosting.

4. 4

   Fehlerfälle und Rollback vor der Verkehrsumstellung testen

   Einen Worker während eines Jobs neu starten, eine Anfrage wiederholen und ein Deployment bei geöffneter Browsersitzung durchführen. Sicherstellen, dass Wiederholungsversuche keine für Kunden sichtbaren Vorgänge doppelt ausführen. Festlegen, wie sich die Anwendung zurücksetzen lässt, ohne eine Datenbankmigration auf unsichere Weise rückgängig zu machen.

5. 5

   Dasselbe Lastprofil vergleichen und schrittweise umstellen

   In jede Kalkulation App, Worker, Datenbank, Dateispeicher, Datenverkehr, Builds und Monitoring einbeziehen. Den Verkehr erst nach bestandenen Abnahmeprüfungen umstellen, eine Rückkehrmöglichkeit offenhalten und ungenutzte Ressourcen abschalten, sobald die neue Umgebung stabil läuft.

Die Framework-Details hinter diesen Prüfungen stehen in der Next.js-Anleitung zum Self-Hosting. Die Checkliste ist ein Abnahmeplan. Sie behauptet nicht, dass diese Anwendungen im Rahmen des Vergleichs tatsächlich bereitgestellt wurden.

Nach welchen Kriterien wurden die Anbieter ausgewählt?

Im Mittelpunkt steht ein belastbarer Migrationsweg für eine produktiv genutzte Next.js- oder KI-App. Die Kriterien sind eine passende Laufzeitumgebung, dokumentierte Framework-Kompatibilität, Abrechnungseinheiten, Deployment-Abläufe und die Betriebsaufgaben, die auf das eigene Team übergehen.

Die sechs Anbieter wurden am 3. November 2026 anhand ihrer eigenen Preis- und Technikseiten bewertet. Die Empfehlungen ordnen diese Fakten den jeweiligen Anforderungen zu: statische Auslieferung, verwaltete Anfrageverarbeitung, dauerhaft laufende Dienste oder der Verbleib beim bisherigen Anbieter. Ohne gemessenes Lastprofil werden weder synthetische Leistungswerte noch behauptete Einsparungen vergeben.

Selbst verwaltete virtuelle Server gehören nicht zu dieser Auswahl, weil sie ein anderes Betriebsmodell mitbringen. Fachkundige Entwickler können diesen Weg wählen. Dann muss jedoch jemand Updates, Backups, Wiederherstellung und die öffentliche Erreichbarkeit des Servers verantworten. Weitere Namen auf der Liste würden diese Aufgaben nicht beseitigen.

Welche Kombinationen besser vermieden werden

Zu vermeiden ist die falsche Kombination aus Anbieter und Anwendung, keine Marke unter allen Umständen.

• AWS Amplify Hosting für eine unveränderte Next.js-KI-App mit Streaming. Der dokumentierte Ausschluss von Streaming ist ein konkretes Hindernis.
• Ein statischer Export auf Cloudflare Pages für eine App, die eigene Server Actions zur Anfragezeit oder ISR benötigt. Dafür braucht es eine kompatible Serverlaufzeit oder ein getrenntes Backend.
• Render Free für eine App, die jederzeit sofort bereitstehen muss. Der Ruhemodus widerspricht dieser Anforderung.
• Netlify als vermeintlicher Festpreisersatz für eine hohe Auslastung. Die gemeinsame Credit-Nutzung und die Folgen eines aufgebrauchten Kontingents müssen zuerst durchgerechnet werden.
• Fly.io als Ausweg aus Infrastrukturentscheidungen. Regionale Datenplatzierung, Volumes und Wiederherstellung verlangen klare Zuständigkeiten.

Auch Railway oder eine andere Plattform mit verbrauchsabhängiger Ressourcenabrechnung sollte nicht allein wegen ihres Mindestabopreises gewählt werden. Ein attraktiver Einstiegspreis sagt nichts über die Kosten der Dienste aus, die erst noch bereitgestellt werden.

Häufige Fragen

Ist Vercel ein Hosting-Anbieter?

Ja. Vercel hostet Webanwendungen und stellt sie bereit. Die hier vorgestellten Alternativen übernehmen unterschiedliche Teile dieser Aufgabe: von der Auslieferung statischer Dateien bis zum Betrieb eines dauerhaft laufenden Anwendungsservers.

Was unterscheidet Vercel von GoDaddy?

Eine Domain zu registrieren und eine Anwendung bereitzustellen sind unterschiedliche Aufgaben. GoDaddy verkauft Domainregistrierungen; Vercel hostet Anwendungen. Eine bei GoDaddy registrierte Domain verpflichtet nicht dazu, dort auch die Anwendung zu hosten.

Welche Alternative ist besser als Vercel?

Für dauerhaft laufende Full-Stack-Dienste können Render oder Railway besser passen. Bei statischen Websites und kompatiblen Edge-Anwendungen gehört Cloudflare ganz oben auf die Auswahlliste. Netlify eignet sich für einen verwalteten Next.js-Veröffentlichungsprozess. Ohne festgelegte Laufzeitumgebung und konkretes Lastprofil gibt es keinen pauschalen Sieger.

Nutzt Netlify Vercel?

Netlify betreibt eine eigene Deployment-Plattform. Next.js läuft dort über Netlifys eigenen OpenNext-Adapter. Dieses Deployment ist vom Hosting einer App auf Vercel unabhängig.

Was ist besser: Vercel oder Netlify?

Netlify ist eine ernsthafte Alternative, wenn Framework-Verhalten und Credit-Modell zur App passen. Bei Vercel zu bleiben kann sinnvoller sein, wenn der Migrationsaufwand die erwartete Verbesserung überwiegt. Verglichen werden sollten die aktuelle Rechnung und die benötigten Funktionen, insbesondere Middleware, Ausführungsort und Deployment-Verhalten.

Welche Nachteile hat Netlify?

Mehrere Nutzungsarten teilen sich einen Credit-Pool. Ist er aufgebraucht, können auch andere Projekte des Kontos pausieren. Der SSR-Ausführungsort bei konfigurierter Next.js-Edge-Laufzeit und Teile des Middleware-Verhaltens unterscheiden sich von einem eigenständigen Deployment. Bei Skew Protection brauchen außerdem eigene Clientanfragen besondere Aufmerksamkeit.

Welche Netlify-Alternative ist besser?

Für statische Auslieferung und kompatiblen Edge-Code lohnt sich die Prüfung von Cloudflare. Wird ein dauerhaft laufender Dienst oder ein klassischer Hintergrund-Worker benötigt, sind Render oder Railway der bessere Ausgangspunkt. Steht die verwaltete Veröffentlichung von Websites im Mittelpunkt, bleibt Netlify eine starke Wahl.

Bleibt Netlify dauerhaft kostenlos?

Netlify bietet derzeit einen dauerhaften Free-Tarif mit monatlichem Credit-Kontingent an. Das bedeutet weder unbegrenzte Nutzung noch eine Garantie für unveränderte Bedingungen. Ist das Kontingent aufgebraucht, können Websites pausiert werden.

Was ist besser: GitHub oder Netlify?

GitHub Pages liefert statische Websites aus Repository-Dateien aus. Netlify unterstützt über seinen Adapter zusätzlich serverseitige Next.js-Funktionen. Entscheidend ist, ob die Website eine Serverlaufzeit benötigt. Quellcode auf GitHub zu speichern schließt ein Deployment der App bei einem anderen Anbieter nicht aus. GitHub-Pages-Dokumentation.

Vor der Migration nächste Woche hilft die Checkliste für den Audit von KI-Geschäftsabläufen, Frontend, Jobs, Daten und Ausgabenlimits zu erfassen. Damit lässt sich die eine Aufgabe identifizieren, deren Umzug sich zuerst lohnt.