Vercel vs. Upsun: Vergleich der Plattformarchitektur nach dem Vorfall im April 2026

Das Wichtigste auf einen Blick: Der Vercel-Vorfall vom April 2026 ist ein guter Anlass, um noch einmal zu prüfen, wo sich der Prüfpfad für Infrastrukturänderungen befindet, wie der Compliance-Umfang für eine Full-Stack-Anwendung zusammengesetzt ist und wie portabel die Bereitstellung zwischen verschiedenen Clouds ist. Upsuns strukturelle Lösung ist ein Git-natives, YAML-definiertes Modell, das die gesamte Anwendung abdeckt.

I. Die Architektur eines Kompromisses

Das Wichtigste auf einen Blick: Die Angriffsfläche jeder gehosteten Plattform umfasst auch die eigene Lieferkette des Anbieters. Wie sichtbar diese Fläche vom Kunden aus ist, variiert je nach Plattform.

Der Sicherheitsvorfall bei Vercel im April 2026 ging von einem Drittanbieter-Tool aus, das mit dem Google Workspace eines Mitarbeiters verbunden war, und griff auf interne Vercel-Systeme über. Laut Vercels Mitteilung waren die Auswirkungen auf Kunden begrenzt, und Vercel hat Experten für die Reaktion auf Vorfälle hinzugezogen und die Strafverfolgungsbehörden benachrichtigt. Jede Plattform kann von einem Vorfall betroffen sein, und Vercel hat direkt und professionell reagiert.

Was der Vorfall verdeutlicht, ist eine Eigenschaft des gemeinsamen Multi-Tenant-SaaS-Modells, nicht etwa ein Versagen von Vercel im Besonderen. Jede gemeinsame Plattform, einschließlich Upsun, hat irgendwo in ihrer Architektur eine Lieferkette. Die Frage, die es zu stellen gilt, ist, wo jede Plattform ihre Grenzen zieht und wie viel von der operativen Oberfläche der Anwendung ein Kunde von seiner Seite aus sehen und prüfen kann.

Der strukturelle Unterschied bei Upsun liegt nicht darin, wie Geheimnisse gespeichert werden. Umgebungsvariablen funktionieren auf beiden Plattformen ähnlich: Werte werden über die CLI oder die Konsole gesetzt, mit einem opt-in-sensitive-Flag, das sie vor der Benutzeroberfläche verbirgt. Der Unterschied liegt eine Ebene höher, nämlich darin, wie die Infrastruktur selbst definiert und überprüft wird.

Auf Dashboard-gesteuerten Plattformen befinden sich die Konfigurationen für Routen, Umschreibungen, Funktionseinstellungen, Regionsauswahl und Integrationsverknüpfungen in der Admin-Oberfläche des Plattformbetreibers. Die Audit-Protokolle für diese Änderungen liegen in den Logs der Plattform, hinter dem Zugriffsmodell der Plattform.

Bei Upsun befindet sich diese Konfiguration in einer Konfigurationsdatei im eigenen Git-Repository des Kunden. Jede Änderung an einer Service-Definition, einer Route, einer Firewall-Regel oder einem Ressourcenprofil ist ein Commit, der über den Pull-Request-Prozess des Kunden geprüft wird und in dessen Git-Log sichtbar ist. Der Prüfpfad für Infrastrukturänderungen ist derselbe, den das Entwicklerteam bereits für den Anwendungscode pflegt.

II. Wo sich der Prüfpfad für die Infrastruktur befindet

Das Wichtigste: Der Prüfpfad für Infrastrukturänderungen sollte innerhalb der eigenen Systeme des Kunden sichtbar sein, nicht nur innerhalb der Systeme des Anbieters.

Teams entscheiden sich für Vercel, weil die Entwicklererfahrung rund um die Frontend-Laufzeit und den Preview-Ablauf gut ist. Für Teams, deren Backend aus einer verwalteten Datenbank und einer Handvoll Funktionen besteht, verstärkt sich diese Stärke noch. Der Kompromiss zeigt sich, wenn die Anwendung über diese Form hinauswächst und die Betriebsfläche außerhalb des Frontends das gleiche Maß an Transparenz und Überprüfung benötigt wie das Programmieren.

Upsun behandelt die Infrastrukturdefinition als Programm, was verändert, was von Kundenseite aus überprüfbar ist:

• Infrastruktur in Git. Routen, Dienste, Worker, Cron-Jobs, Firewall-Regeln, Dienstbeziehungen und Ressourcenzuweisungen werden in der Datei „.upsun/config.yaml“ in deinem Repository deklariert. Jede Änderung ist ein Commit, der über deinen Pull-Request-Prozess geprüft wird und in deinem Git-Log sichtbar ist. Der Prüfpfad für Infrastrukturänderungen ist derselbe, den das Entwicklerteam bereits für den Anwendungscode pflegt.
• Geheimnisse außerhalb der Konfigurationsdatei, mit Parität beim Flag selbst. Umgebungsvariablen sowohl bei Upsun als auch bei Vercel verwenden ein optionales „sensitive“-Flag, das Werte vor der UI- und CLI-Ausgabe verbirgt. Der strukturelle Unterschied liegt nicht im Flag. Er besteht darin, dass bei Upsun die Infrastruktur, die diese Geheimnisse nutzt (welche Dienste existieren, welche Beziehungen sie haben, unter welchen Firewall-Einstellungen sie laufen), versionsverwaltet ist, sodass Änderungen an dieser Infrastruktur außerhalb der Logs des Anbieters nachvollziehbar sind.
• Explizite Service-Beziehungen. Auf Upsun erhält ein Service Anmeldedaten und Verbindungsinformationen für einen anderen Service ausschließlich über eine „relationships“-Deklaration in YAML. Das Verbindungsdiagramm zwischen deinen Services wird programmiert und ist nicht implizit in den Standardeinstellungen der Plattform enthalten.
• Ausgehende Firewall-Regeln pro Dienst. Die Firewall-Eigenschaft in „.upsun/config.yaml“ schränkt ein, welche externen Hosts jeder Dienst erreichen kann, und wird zusammen mit der Dienstdefinition deklariert. Die ausgehende Netzwerkkonfiguration wird im selben Pull-Request überprüft wie das Programm, das sie nutzt.

III. Cloud-übergreifende Portabilität, programmiert

Das Wichtigste zum Mitnehmen: Ein Bereitstellungsmodell mit einem einzigen Anbieter erleichtert viele Entscheidungen, macht es aber später schwieriger, diese Entscheidungen zu überdenken. Die Portabilität zwischen Clouds ist eine strukturelle Eigenschaft, die diese Kosten senkt.

Wenn ein Vorfall, eine Beschaffungsanforderung oder eine Änderung des Compliance-Umfangs die Frage aufwirft: „Können wir das woanders betreiben?“, hängt die Antwort davon ab, wie stark die Anwendung an die Laufzeitumgebung eines Anbieters gebunden ist. Ist die Bereitstellungslogik plattformspezifisch, bedeutet ein Wechsel eine Neuprogrammierung. Ist die Bereitstellungslogik generisch, bedeutet ein Wechsel lediglich eine Konfigurationsänderung.

Die „.upsun/config.yaml“ von Upsun ist dieselbe Datei, egal ob das Projekt auf AWS, Azure, Google Cloud oder OVH läuft – und das über Dutzende von Regionen hinweg. Du wählst den Hyperscaler bei der Projekterstellung aus, und die Konfiguration ändert sich nicht, wenn du den Hyperscaler wechselst. Upsun ist außerdem auf den Marktplätzen von AWS, Azure, Google und IBM verfügbar, sodass Teams mit bestehenden Committed-Use-Vereinbarungen für eine dieser clouds diese auf ihre Upsun-Nutzung anwenden können.

Deine Anwendung läuft in von Upsun betriebenen Umgebungen auf dem von dir gewählten Hyperscaler. Die Portabilität liegt in der Konfiguration, nicht darin, wo die Infrastruktur physisch betrieben wird. Was sich dadurch ändert, sind die Kosten für die erneute cloud-Entscheidung: Es handelt sich um eine Projekteinstellung statt um ein vierteljähriges Engineering-Projekt.

Für Teams, deren Roadmap regulierte Kunden, Anforderungen an souveräne Regionen oder Unternehmensbeschaffungen umfasst, bei denen nach Präferenzen für Hyperscaler gefragt wird, ist diese Flexibilität oft der entscheidende Faktor zwischen einem „Ja“ und einem Plattformwechsel.

Häufig gestellte Fragen

Ist Upsun sicherer als Vercel?

Beide Plattformen verfügen über SOC 2 Typ 2-Zertifizierungen und werden von seriösen Teams in der Produktivumgebung eingesetzt. Die Unterschiede, die es zu vergleichen lohnt, sind struktureller Natur. Wo sich der Audit-Trail für Infrastrukturänderungen befindet: bei Upsun im eigenen Git-Repository des Kunden; bei Vercel in der Admin-Oberfläche und den Logs der Plattform. Wie sich der Compliance-Umfang für eine Full-Stack-Anwendung zusammensetzt: Die Zertifizierungen von Upsun decken die gesamte Plattform ab, einschließlich Datenbanken, queues, Objektspeicher und Worker, während der SOC-2-Umfang von Vercel die Vercel-Ebene abdeckt und HIPAA-BAAs in den Pro- und Enterprise-Tarifen verfügbar sind, wobei Marktplatzpartner ihre eigenen Zertifizierungen für zustandsbehaftete Dienste mitbringen. Welche Optionen stehen zur Verfügung: Upsun bietet SOC 2 Typ 2, ISO 27001 sowie PCI DSS- und HIPAA-Optionen plattformweit an.

Unterstützt Upsun Next.js?

Ja. Next.js ist eine erstklassige Laufzeitumgebung auf Upsun. Du definierst die Anwendung und ihre zugrunde liegenden Dienste (Datenbanken, Caches, Suche, queues) in „.upsun/config.yaml“. Umgebungsvariablen werden über die Upsun-CLI oder -Konsole festgelegt und können als sensibel gekennzeichnet werden, sodass ihre Werte in der Benutzeroberfläche und der CLI-Ausgabe ausgeblendet werden – das gleiche Opt-in-Modell, das Vercel anbietet. Jeder Git-Zweig erhält einen Byte-für-Byte-Klon der Produktivumgebung (Code, Daten und Dienste), was nützlich ist, wenn du die Anwendung vor dem Umstieg von einer anderen Plattform validieren möchtest.

Wie lange dauert die Migration von Vercel?

Bei den meisten Next.js-Anwendungen besteht die Migration in erster Linie darin, eine `.upsun/config.yaml`-Datei zu schreiben, die die Anwendung und ihre Dienste beschreibt, sowie Umgebungsvariablen und DNS zu übertragen. Da jeder Zweig auf Upsun eine byteweise identische Vorschauumgebung erhält, die aus der Produktivumgebung geklont wurde (Code, Daten und Dienste), kannst du die vollständig migrierte Anwendung vor der Umstellung mit produktionsreifen Daten testen. Das Anwendungsdienst-Team von Upsun unterstützt Migrationen praxisnah, wenn dies der richtige Weg ist.