Über das Frontend hinaus: Die Wahl zwischen Vercel und Upsun für Full-Stack-Anwendungen im Jahr 2026

Wenn du im Jahr 2026 eine moderne Webanwendung entwickelst, steht Vercel mit ziemlicher Sicherheit auf deiner Auswahlliste – und wahrscheinlich ganz oben darauf. Die Entwicklererfahrung, die Vercel für Next.js und das damit verbundene Frontend-Ökosystem geprägt hat, ist eine echte Errungenschaft. Einen Branch pushen, eine Vorschau-URL abrufen, veröffentlichen. Es funktioniert, es ist schnell, und eine ganze Generation von Frontend-Teams hat ihren Workflow darauf aufgebaut.

Dieser Artikel soll nichts davon in Frage stellen.

Er ist hier, weil die Anwendungen, die Teams entwickeln, über den Teil des Stacks hinausgewachsen sind, für den Vercel ursprünglich konzipiert wurde, und weil die Fragen, die ein Full-Stack-Team zu einer Plattform beantworten muss, sich von denen unterscheiden, die ein Frontend-Team beantworten muss. Wo Daten gespeichert werden. Was Compliance abdeckt. In welcher cloud die Anwendung läuft. Wie die Infrastruktur beschrieben und überprüft wird. Ob Backend-Dienste genauso behandelt werden wie das Frontend.

Dies ist ein struktureller Vergleich der beiden Plattformen in den Bereichen, die wichtig werden, sobald eine Anwendung mehr ist als nur ihr Frontend. Das Ziel ist es, dir zu helfen, eine ehrliche Entscheidung zu treffen, nicht dir die Antwort vorzugeben.

Wo sich die beiden Plattformen strategisch unterscheiden

Vercels Schwerpunkt liegt auf der Frontend-Laufzeitumgebung und der damit verbundenen Entwicklererfahrung. Die jüngsten Ergänzungen der Plattform – Fluid Compute für effizientes serverloses JavaScript und Python, Vercel Sandbox für kurzlebige Rechenaufgaben in Firecracker-MicroVMs und die enge Integration mit Next.js – verstärken diesen Schwerpunkt. Die Stärke der Plattform liegt darin, die Frontend-Ebene hervorragend zu gestalten und von dort aus über einen Marktplatz mit Integrationen für die angrenzenden Komponenten nach außen zu expandieren.

Upsun geht von einem anderen Schwerpunkt aus. Die Plattform ist darauf ausgelegt, eine gesamte Anwendung – Frontend, Backend-Dienste, Datenbanken, queues, Worker, Caches, Cron-Jobs und alles, was diese miteinander verbindet – unter einer einzigen deklarativen Konfiguration, innerhalb einer Governance-Grenze und in einer cloud deiner Wahl auszuführen. Der Schwerpunkt liegt darauf, die gesamte Anwendung als Einheit zu behandeln, anstatt die umgebenden Komponenten um einen Frontend-Kern herum zu schichten.

Beide Ansätze sind legitim. Sie sind auf unterschiedliche Team- und Anwendungsstrukturen optimiert. Wo sie zu unterschiedlichen Ergebnissen führen, zeigt sich in den folgenden spezifischen Funktionen.

Die gesamte Anwendung, nicht nur die Frontend-Schicht

Die verwaltete Oberfläche von Vercel besteht aus der Frontend-Laufzeitumgebung und den damit verbundenen serverlosen Funktionen. Datenbanken, Objektspeicher und andere zustandsbehaftete Dienste sind über Vercels Marketplace-Integrationen mit Partneranbietern wie Neon, Supabase und Upstash verfügbar. Diese Integrationen sind wirklich praktisch für Teams, deren Backend aus einer Datenbank und einer Handvoll Funktionen besteht.

Der Nachteil ist, dass die über den Marketplace integrierten Teile deiner Anwendung in der Umgebung eines anderen Anbieters liegen, mit einem anderen Betriebsmodell, einem anderen Supportvertrag und anderen Governance-Grenzen. Für ein einfaches Backend ist das in Ordnung. Bei einer Full-Stack-Anwendung mit lang laufenden Workern, Queues, Laufzeitumgebungen für mehrere Sprachen oder Datendiensten, die zusammen mit der Recheninstanz untergebracht werden müssen, werden die Schnittstellen zwischen Vercel und den Marketplace-Partnern Teil der Architektur.

Upsun führt die gesamte Anwendung auf einer einzigen Plattform aus. Eine einzige `.upsun/config.yaml`-Datei in deinem Git-Repository beschreibt die Frontend-App, die Backend-Dienste in Node, Python, PHP, Go oder Java, die PostgreSQL- oder MySQL-Datenbank, den Redis-Cache, die RabbitMQ-queue, die Worker, die darauf zugreifen, die Cron-Jobs und das Routing zwischen all diesen Komponenten. Sie werden gemeinsam bereitgestellt, laufen gemeinsam und werden gemeinsam verwaltet. Es gibt keine Marktplatz-Nahtstelle, da es keine Marktplatz-Ebene gibt.

Das ist besonders wichtig für Anwendungen mit mehreren Backend-Diensten, nicht trivialen Datenschichten oder Sprach-Runtimes jenseits von JavaScript und Python.

Preview-Umgebungen: Programmieren versus Byte-für-Byte

Vercels Preview-Deployments sind ein zentraler Bestandteil dessen, was die Plattform berühmt gemacht hat. Jeder Pull-Request erhält eine URL. Reviewer klicken darauf, sehen die Änderung und genehmigen sie oder lehnen sie ab. Es ist das einzige Feature, das die Messlatte dafür, wie sich die Entwicklererfahrung in der gesamten Branche anfühlen sollte, am stärksten angehoben hat.

Der Nachteil ist, dass ein Preview-Deployment in Vercel eine Vorschau auf Code-Ebene ist. Der Code wird bereitgestellt, aber die zugrunde liegenden Dienste, Datenbanken, Objektspeicher und queues sind genau das, worauf die Umgebung konfiguriert wurde. Teams verbinden Previews in der Regel über einen Marketplace-Partner mit einer gemeinsamen Staging-Datenbank oder einer pro Umgebung verzweigten Datenbank. Die Preview-URL wird geladen, aber ob die Daten hinter der Vorschau mit der Produktionsumgebung übereinstimmen, ist eine andere Frage mit einer anderen Antwort.

Die Umgebungsklon-Engine von Upsun erstellt auf jedem Branch eine Byte-für-Byte-Replik der Produktivumgebung. Nicht nur den Code. Die Datenbanken, die Dateien im Objektspeicher, die Dienste, die Suchindizes, die Caches. Ein reviewer, der eine Vorschau-URL auf Upsun öffnet, sieht die Anwendung, wie sie auf einer vollständigen, isolierten Kopie des tatsächlichen Zustands der Produktivumgebung läuft. In YAML definierte Sanitization-Hooks können personenbezogene Daten beim Klonen entfernen, sodass reviewers mit realistischen Daten arbeiten, ohne sensible Datensätze zu berühren.

Für Teams, bei denen die schwierigsten Fehler in der Interaktion zwischen Code und Daten liegen, ist dies ein ganz anderer Review-Prozess. Fehler, die früher bis zur Staging-Umgebung überlebten, werden nun bereits beim Pull-Request-Review beseitigt.

Die Wahl der cloud als erstklassige Funktion

Vercel läuft auf der globalen Infrastruktur von Vercel. Das ist ein Teil dessen, was die Plattform so magisch macht: Du musst dir keine Gedanken über Regionen, Instanzen oder cloud-Anbieter machen, weil Vercel sich um all das kümmert. Mit der regionalen Konfiguration von Vercel kannst du auswählen, wo Funktionen ausgeführt werden, und das Edge-Netzwerk stellt die Anwendung global bereit.

Der Nachteil ist, dass die Frage „Welche cloud?“ nicht von der Plattform beantwortet wird. Wenn eine Aufsichtsbehörde die Verarbeitung in der Infrastruktur einer bestimmten Gerichtsbarkeit vorschreibt, wenn das Beschaffungsteam eines Kunden sich weigert, Anbieter zu genehmigen, die einen bestimmten Hyperscaler nutzen, oder wenn ein CFO möchte, dass cloud-Ausgaben auf eine bestehende Committed-Use-Vereinbarung mit AWS, Azure, Google oder IBM angerechnet werden, ist die Antwort auf Vercel die Antwort, die dir die Plattform gibt.

Upsun stellt dieselbe Anwendung, beschrieben durch dieselbe .upsun/config.yaml, auf AWS, Azure, Google Cloud oder OVH in Dutzenden von Regionen bereit. Die Konfiguration ändert sich nicht, wenn die cloud wechselt. Das Verschieben eines Projekts von einem Hyperscaler zu einem anderen ist eine Einstellung auf Projektebene, keine Umstellung auf eine andere Plattform. Und Upsun ist auf den Marktplätzen von AWS, Azure, Google und IBM verfügbar, sodass Teams mit festen Ausgaben für eine bestimmte cloud diese Verpflichtung auf ihre Upsun-Nutzung anrechnen können. Für Teams, deren Geschäftsentwicklung regulierte Branchen, Anforderungen bestimmter Regionen oder Unternehmenskunden mit spezifischen Cloud-Präferenzen umfasst, ist diese Flexibilität oft der Unterschied zwischen einem „Ja“ und einem neunzigtägigen Entwicklungsprojekt.

Compliance: plattformweit einheitlich, keine optionale Aktivierung pro Feature

Das ist der Unterschied, der für Teams, deren Compliance-Anforderungen nicht optional sind, am wichtigsten ist – und der bei Bewertungen am häufigsten unterschätzt wird.

Vercel ist SOC 2 Typ 2 zertifiziert und bietet HIPAA-Business-Associate-Vereinbarungen (BAA) für die Pro- und Enterprise-Tarife an. Die HIPAA-Konformität setzt einen qualifizierten Tarif und die Unterzeichnung der BAA voraus. Für Teams mit dem richtigen Tarif, die die BAA abschließen, funktioniert der Schutz wie dokumentiert.

Der Kompromiss besteht darin, dass Vercels Compliance-Status pro Team und pro Tarifstufe zusammengestellt wird. Du optierst für HIPAA, indem du auf Pro oder Enterprise upgradest und die BAA unterzeichnest. Du übernimmst Vercels SOC 2-Geltungsbereich für die Teile der Anwendung, die Vercel verwaltet, und deine Marktplatzpartner (für Datenbanken, queues, Objektspeicher und andere zustandsbehaftete Dienste) haben ihre eigenen Zertifizierungen, Geltungsbereiche und BAAs für die Teile, die sie verwalten. Das daraus resultierende Compliance-Diagramm ist eine Zusammensetzung der Compliance-Status mehrerer Plattformen, die an den von dir geschaffenen Schnittstellen miteinander verbunden sind.

Die SOC 2 Typ 2-, ISO 27001-, PCI DSS- und HIPAA-Optionen von Upsun gelten für jede Funktion und jede Umgebung auf der Plattform sowie für jeden Managed Service, den du darauf betreibst. Die Compliance-Grenze ist in der Staging-Umgebung dieselbe wie in der Produktivumgebung, für das Frontend dieselbe wie für den Queue-Worker, für den PostgreSQL-Dienst dieselbe wie für den Anwendungscontainer und dieselbe, unabhängig davon, auf welchem zugrunde liegenden Hyperscaler dein Projekt läuft. Wenn dein Audit-Umfang die gesamte Anwendung umfassen muss, stimmt die Umfangsbeschreibung mit dem Architekturdiagramm überein, da die Zertifizierungen die gesamte Plattform als Ganzes abdecken.

Für Teams im Gesundheitswesen, im Finanzdienstleistungssektor, in der öffentlichen Verwaltung oder in jedem B2B-Kontext, in dem Compliance Teil der Beschaffungsgespräche ist, ist eine einheitliche Haltung wesentlich einfacher zu verteidigen als eine zusammengesetzte.

Konfiguration und Entwicklererfahrung

Das Konfigurationsmodell von Vercel besteht in erster Linie aus dem Dashboard und der CLI, ergänzt durch eine `vercel.json`-Datei für projektbezogene Einstellungen. Umgebungsvariablen, Integrationen, Regionen und Teameinstellungen werden über die Vercel-Benutzeroberfläche verwaltet, die gut gestaltet und schnell zu erlernen ist. Die Benutzererfahrung ist für Einzelentwickler und kleine Teams optimiert, die möchten, dass die meisten Entscheidungen für sie getroffen werden.

Der Nachteil ist, dass die Plattformkonfiguration in der eigenen Admin-Oberfläche der Plattform und nicht in deinem Repository liegt. Für Sicherheitsteams, die jede Infrastrukturänderung in der Versionskontrolle unter denselben Prüfprozessen wie Anwendungscode haben wollen, erfordert das Vercel-Modell eine zusätzliche Audit-Ebene, um nachzuverfolgen, was sich wann geändert hat.

Das Modell von Upsun ist Git-nativ. Die Datei „.upsun/config.yaml“ in deinem Repository ist die gesamte Infrastrukturdefinition. Jede Datenbankversion, jede Firewall-Regel, jeder Dienst, jede Route, jeder Cron-Job, jede Ressourcenzuweisung – all das ist ein Commit in deinem Main-Branch. Änderungen laufen über Pull-Requests. Audits überprüfen das Git-Log. Rollbacks erfolgen per Git-Revert. Der gleiche Überprüfungsprozess, der für den Anwendungscode gilt, gilt auch für die Infrastruktur.

Das ist keine Wertung von Dashboards. Dashboards sind für Einzelpersonen schneller. YAML in Git ist für Teams mit Review-Anforderungen besser vertretbar.

Vergleich auf einen Blick

Wann Vercel wahrscheinlich die richtige Wahl ist

Ein Frontend-First-Team, das eine Next.js-Anwendung mit einer kleinen Backend-Oberfläche und ohne unmittelbare regulatorische Anforderungen entwickelt, wird auf Vercel wahrscheinlich schneller bereitstellen können als auf jeder anderen Plattform. Wenn deine Anwendung im Wesentlichen aus Frontend besteht, wenn dein Team auf JavaScript ausgerichtet ist, wenn dein Backend aus einer verwalteten Datenbank und einigen serverlosen Funktionen besteht und wenn deine Compliance-Anforderungen in den Rahmen passen, den Vercel und seine Marktplatzpartner gemeinsam zertifizieren, kommen die Stärken der Plattform zu deinem Vorteil zum Tragen. Für diesen Fall wurde sie entwickelt und leistet weiterhin gute Dienste.

Wann Upsun wahrscheinlich die richtige Wahl ist

Ein Team, dessen Anwendung mehrere Backend-Dienste, lang laufende Worker, Datenebenen, die mit der Rechenleistung leben müssen, Sprach-Runtimes jenseits von JavaScript und Python oder Compliance-Anforderungen umfasst, die die gesamte Anwendung abdecken müssen, wird feststellen, dass die strukturellen Eigenschaften von Upsun näher an der Problemstellung liegen. Kunden aus den Bereichen Gesundheitswesen, Finanzdienstleistungen, Behörden, Agenturen, die für regulierte Kunden entwickeln, und Produktteams, die über den Punkt hinaus sind, an dem die Anwendung ein Frontend mit einer Datenbank ist, landen in der Regel hier. Die Funktionen, die in diesen Kontexten am wichtigsten sind – YAML-definierte Infrastruktur in Git, byteweises Klonen von Umgebungen, Multi-Cloud-Bereitstellung ohne Konfigurationsänderungen und einheitliche Compliance über alle Funktionen und Umgebungen hinweg – sind strukturelle Entscheidungen, auf denen die Plattform aufbaut, und keine nachträglich hinzugefügten Features.

Der Wechsel von Vercel zu Upsun, falls du dich dafür entscheidest

Teams, die migrieren, tun dies in der Regel anwendungsweise. Das Programmieren des Anwendungscodes erfordert meist nur geringfügige Anpassungen. Der Großteil der Arbeit besteht darin, die Vercel-spezifische Konfiguration (Umschreibungen, Weiterleitungen, Umgebungsvariablen, Einstellungen für serverlose Funktionen) in die entsprechenden YAML-Deklarationen in .upsun/config.yaml zu übersetzen und die Backend-Dienste, die über den Vercel Marketplace integriert wurden, auf die nativen Dienstdefinitionen von Upsun zu übertragen.

Das Anwendungsdienst-Team von Upsun arbeitet bei Migrationen direkt mit den Entwicklerteams zusammen, wenn dies der richtige Weg ist. Das Ziel dieser Zusammenarbeit ist weniger, eine Migration zu verkaufen, sondern vielmehr, ein klares Bild davon zu vermitteln, was der Umstieg tatsächlich beinhaltet, damit das Team die Entscheidung anhand von konkreten Zahlen statt Schätzungen treffen kann.

Die ehrliche Zusammenfassung

Vercel und Upsun sind beide gute Plattformen. Sie zielen auf unterschiedliche Probleme ab, und die richtige Antwort hängt davon ab, welches Problem du tatsächlich hast.

Wenn deine Anwendung im Wesentlichen ein Frontend ist, ist Vercel wahrscheinlich gut geeignet, und die Tiefe einer Full-Stack-Plattform wäre für ein Team, das sie nicht benötigt, möglicherweise verschwendet.

Wenn deine Anwendung über ein umfangreiches Backend verfügt, Compliance-Anforderungen hat, die den gesamten Stack umfassen, in Zukunft cloud-flexible Lösungen benötigt oder ein Team hast, das die Infrastruktur neben dem Anwendungscode in Git haben möchte, sind die Full-Stack-Funktionen von Upsun genau das, was du brauchst.

Der Fehler liegt nicht darin, sich für das eine oder das andere zu entscheiden. Der Fehler liegt darin, die Plattform zu wählen, die zur aktuellen Situation der Anwendung passt, und im zwölften Monat festzustellen, dass die Plattform der Grund dafür ist, dass die Anwendung nicht das werden kann, was das Team sich vorgestellt hat.

Wähle die Plattform, die zu der Richtung passt, in die sich die Anwendung entwickelt.

Weiterführende Literatur

• Übersicht über die Upsun-Plattform
• Upsun-Umgebungen und Byte-für-Byte-Klonen
• Upsun-Compliance-Leitfaden
• Dokumentation zur Vercel-Plattform
• Vercel Fluid Compute
• Vercel Sandbox
• Vercel-Preview-Bereitstellungen
• Vercel Sicherheit und Compliance