Vibe-Coded App deployen: schnell, günstig, in der EU

Du hast in drei Stunden mit Lovable, Cursor und ein bisschen Claude Code eine App zusammengeschoben. Sie läuft, sie hat User, sie speichert Daten. Auf Vercel, mit Supabase als Datenbank. Du weißt vermutlich nicht, wo genau die Daten deiner User liegen. Und das ist ein Problem, das größer ist als du denkst. Wenn du souverän deployen willst, fängst du am besten heute an, nicht, wenn die erste DSGVO-Anfrage auf deinem Schreibtisch landet.

Der Vibe-Coder-Stack 2026 und warum er ein Compliance-Problem hat

Was unter „vibe coden“ tatsächlich passiert

Andrej Karpathy hat den Begriff Anfang 2025 geprägt, und Merriam-Webster hat ihn aufgenommen, bevor der Sommer vorbei war. Vibe Coding heißt: du beschreibst, was du willst, der Agent baut den Code, du testest, du gibst Feedback, du deployest. Knapp die Hälfte des heute geschriebenen Codes weltweit ist AI-generiert. Das ist keine Spielerei, das ist der neue Standard.

Karpathy selbst nennt es inzwischen „agentic engineering“ — die Drift weg vom blinden Akzeptieren hin zu mehr Oversight. Im Alltag bleibt aber, was die Tools versprechen: Beschreib, drück Enter, deploy. Cursor, Replit, Bolt, Lovable, v0 setzen alle auf diesen Flow.

Der Standard-Stack: Lovable + Cursor + Vercel + Supabase + OpenAI

Wenn du dir ansiehst, was Vibe Coder tatsächlich deployen, kommt fast überall dasselbe Bild heraus. Lovable oder Bolt erzeugt das Next.js-Frontend, Cursor verfeinert es, Supabase übernimmt Datenbank und Auth, Vercel hostet das Ganze, OpenAI oder Anthropic liefern die Intelligence im Backend. GitHub als Code-Storage. Alles auf Free-Tiers, alles in unter einer Stunde.

Das ist nicht nur populär, das ist eine Standardarchitektur mit eigenen Tutorials, Anleitungen und Fiverr-Profilen. Du tippst nicht mehr „wie deploy ich Next.js“, du tippst „fix mein Bolt plus Supabase plus Vercel Setup“.

Warum dieser Stack auf US-Infrastruktur landet

Vercel ist US. Supabase betreibt seine Default-Region in den USA, EU-Region ist optional. OpenAI und Anthropic sind US. GitHub gehört Microsoft. Selbst wenn du in Berlin sitzt, geht jeder API-Call deiner App durch mindestens einen US-Provider. Deine User-Daten liegen, je nach Konfiguration, in Virginia, in Frankfurt-aber-mit-US-Mutter, oder beidem gleichzeitig.

Das ist kein Bug deines Stacks. Das ist sein Default. Und solange dir niemand sagt, dass du auswählen kannst, wählst du nicht.

Default-Stack vs. souveräne Variante im Direktvergleich

Die rechte Spalte sieht auf den ersten Blick nach „alles selber machen“ aus. Das ist sie nicht. Die meisten Komponenten gibt es als managed Service mit derselben Bequemlichkeit wie ihre US-Pendants, nur eben unter europäischer Hoheit. Du tauschst Provider, nicht Workflow.

Was du als Vibe Coder gerade verarbeitest, ohne es zu wissen

Personenbezogene Daten ab dem ersten Login

Sobald deine App ein Login hat, verarbeitest du personenbezogene Daten. E-Mail-Adresse ist personenbezogen. IP-Adresse ist personenbezogen. Browser-Fingerprint, Geräte-ID, Auth-Token, alles personenbezogen. Du brauchst dafür keine Banking-App. Eine Login-Seite mit „Mit Google anmelden“ reicht.

Die DSGVO unterscheidet nicht, ob du Hobbyprojekt bist oder Konzern. Sie unterscheidet, ob du personenbezogene Daten verarbeitest. Tust du das, gelten dieselben Pflichten.

Embeddings, Chat-Verläufe, Logfiles

Vibe-coded Apps haben fast immer einen LLM im Backend. Damit holst du dir weitere Datenkategorien rein: Chatverläufe, Embeddings, Prompts. Embeddings sind kein anonymisierter Vektor, sondern ein potenziell rückführbarer Fingerabdruck des Inhalts. Wenn du Chats persistierst, persistierst du, was der User dir gesagt hat, inklusive aller Inhalte, die er besser nicht sagen sollte.

Logfiles vergessen viele komplett. Vercel loggt Request-Header. Supabase loggt SQL-Statements. Dein LLM-Provider loggt Prompts. Wenn auch nur einer davon mehr loggt als nötig oder länger als nötig, ist das ein DSGVO-Problem.

Warum dein Hobbyprojekt eine DPIA brauchen kann

Wer mit AI personenbezogene Daten verarbeitet, kann eine Data Protection Impact Assessment brauchen, eine DPIA nach Artikel 35 DSGVO. Klingt nach Konzern-Compliance, gilt aber auch für Solo-Devs, wenn das Verarbeitungsrisiko hoch ist. Eine Chatbot-App, die User-Anfragen an OpenAI schickt und Antworten speichert, fällt schnell darunter.

Wenn du keine DPIA hast, keine Records of Processing, keine klare Auflistung der Sub-Processors, bist du nicht „noch nicht so weit“. Du bist im Verzug.

Das CLOUD-Act-Problem für deine App

Wie US-Provider zu Datenherausgabe gezwungen werden können

Der CLOUD Act ist ein US-Gesetz von 2018. Er erlaubt US-Behörden, von US-Unternehmen die Herausgabe von Daten zu verlangen, unabhängig davon, wo die Daten physisch liegen. Frankfurt, Dublin, Singapur, egal. Wenn der Provider US ist, fällt er darunter.

Das ist kein theoretisches Szenario. Die Anweisung kann mit einer Gag Order kommen, das heißt: weder du noch der Provider darf den User informieren. Du verarbeitest also möglicherweise gerade Daten, die im Hintergrund schon herausgegeben werden, und du erfährst es nie.

Warum „EU-Region“ bei Hyperscaler nicht reicht

AWS Frankfurt, Azure Germany, GCP Belgium, Supabase EU-Region, alle nutzen physisch europäische Rechenzentren. Aber der Vertragspartner sitzt in den USA. Vertragspartner heißt: rechtsverbindlich verantwortlich, und damit dem US-Recht unterworfen. Die EU-Region ist ein Datenstandort, keine Datensouveränität.

Das EU-US Data Privacy Framework von 2023 hat das Transferproblem entschärft, das CLOUD-Act-Problem aber nicht gelöst. Es ist juristisch geheilt, strukturell offen.

Was passiert, wenn ein Kunde das mitbekommt

Solange du Hobbyprojekt bist und nur Friends-and-Family-User hast, passiert wenig. In Unternehmen wird daraus schnell Shadow IT durch Vibe Coding, die an der IT vorbei entsteht. Sobald du B2B-Kunden hast, fängt jeder zweite Vertrag mit einem Compliance-Fragebogen an. Wo werden Daten verarbeitet? Wer ist Datenverarbeiter? Subprozessoren? Wenn du dann mit „Supabase, Vercel, OpenAI, Anthropic“ antwortest, hast du gerade einen längeren Termin beim Datenschutzbeauftragten des Kunden gebucht.

Der Tag, an dem dein Side Project zum Problem wird

Erste DSGVO-Anfrage eines Users

Ein User schreibt: „Bitte löscht alle meine Daten.“ Du musst nachweisen können, wo überall Daten zu diesem User liegen, und dass du sie überall gelöscht hast. Bei Vercel-Logs, Supabase-Tabellen, OpenAI-Prompts, Stripe-Records. Wenn du das nicht koordiniert dokumentieren kannst, ist die Anfrage eine offene Front.

Erste Audit-Anfrage eines B2B-Kunden

Ein Mittelständler aus dem Gesundheitsbereich will deinen Service einkaufen. Sein Datenschutzbeauftragter schickt einen 40-Seiten-Fragebogen. Die zweite Frage betrifft Subprozessoren. Die fünfte betrifft Transfer Impact Assessment. Die zwölfte fragt, ob ein US-Provider involviert ist. Du kannst entweder ehrlich antworten und den Deal verlieren, oder hoffen, dass keiner nachfragt.

Erste Behördenanfrage oder Pen-Test

Eine Datenschutzbehörde stellt eine Routinefrage. Oder ein Sicherheitsforscher findet einen exposed Supabase Service Key in deinem Frontend-Bundle — das ist eins der typischen Deployment-Probleme von vibe-coded Apps. Beides ist nicht hypothetisch: Studien haben in über 5.600 öffentlich verfügbaren AI-generierten Apps mehr als 2.000 Schwachstellen und 400 exposed Secrets gefunden. Wenn das deine App ist, hast du keine Wahl mehr, sondern nur noch Schadensbegrenzung.

Was „souverän deployen“ konkret heißt

EU-Infrastruktur außerhalb US-Jurisdiktion

Souverän deployen bedeutet, dass die Vertragsbeziehung mit dem Hosting-Provider unter europäischem Recht steht und der Provider selbst keiner US-Jurisdiktion unterliegt. Das ist mehr als Datenstandort. Es ist Eigentums- und Rechtshoheit.

Konkret: Provider, die in der EU registriert sind, deren Mutterunternehmen in der EU sitzt, deren Infrastruktur in der EU steht. Hetzner, OVH, Scaleway, Kyberio sind Beispiele. Für die App-Plattform darauf gelten dieselben Anforderungen, wie du sie brauchst, um deine App rechtssicher in der EU zu hosten.

Standard-Container statt proprietärer Plattform-Bindung

Wenn deine App nur auf einer Plattform läuft, hast du auch politisch eine Abhängigkeit. Ein US-Provider kann seine Terms ändern, dich rauswerfen, gepatcht werden. Wer mit Standard-Containern deployt und auf Standard-Kubernetes setzt, bleibt portabel. Du kannst sie auf jeden konformen Anbieter umziehen, ohne Architektur zu ändern.

Datenbank und State im selben Souveränitätsraum

Wenn dein Frontend in Frankfurt liegt, deine Datenbank aber bei Supabase US, ist deine Souveränität trotzdem hin. Die schwächste Stelle in der Kette bestimmt das Niveau. Datenbank, Auth, File-Storage, Logs müssen mitziehen.

So setzt du es um, ohne die Vibe zu verlieren

Push-to-Deploy bleibt. Nur das Hosting ändert sich

Die gute Nachricht: Du musst deinen Workflow nicht kaputtmachen. lowcloud und vergleichbare Plattformen halten das Push-to-Deploy-Muster. Du pushst auf GitHub, ein Container wird gebaut, eine Preview-URL erscheint. Genau wie bei Vercel. Der Unterschied ist nicht der Flow, sondern wo das Resultat landet.

Container-Setup für dein AI-generiertes Next.js

Dein Lovable- oder Cursor-Output ist meist Next.js. Next.js läuft im Standalone-Modus in einem Standard-Docker-Container. Ein minimales Dockerfile reicht.

Das ist alles. Damit läuft die App auf jedem Container-Host. Auf einer souveränen Plattform genauso wie auf Vercel.

Managed Postgres statt Supabase-US-Region

Supabase ist im Kern Postgres. Du brauchst Postgres und ein bisschen Auth und Storage. Beides gibt es auf europäischen Plattformen managed: Postgres mit One-Click, Auth mit Standard-Libraries wie Auth.js oder Lucia, Object-Storage S3-kompatibel. Migration ist ein pg_dump und ein paar Connection-String-Änderungen entfernt.

Für den LLM-Teil: Es gibt europäische Inferenz-Anbieter. Wenn du auf OpenAI bleibst, weißt du wenigstens, was du tust — und du kannst die Prompts vor dem Senden minimieren, statt ungefiltert User-Daten weiterzureichen.

Was du gewinnst, abgesehen vom Compliance-Frieden

Klare Datenflüsse, klare Rechnung

Ein Vertrag statt fünf. Eine Rechnung statt vier. Ein Logstream statt drei. Wer schon einmal versucht hat, einer Datenschutzbehörde den Datenfluss durch Vercel, Supabase, OpenAI und Stripe nachzuzeichnen, weiß, was das wert ist.

Migration mit nüchternem Kopf, nicht mit Panik

Du migrierst entweder, wenn du Zeit hast, oder wenn ein Kunde Druck macht. Letzteres ist immer teurer. Wer früh souverän deployen lernt, hat den Vorgang einmal sauber gemacht und kann sich danach auf das konzentrieren, was Vibe Coding eigentlich gut kann: schnell bauen.

Glaubwürdigkeit gegenüber B2B-Kunden

Compliance-Fragebögen sind ein Verkaufsargument geworden. Wer „EU-Provider, kein US-Subprozessor, dokumentierte DPA“ sagen kann, geht durch jeden Procurement-Prozess durch, an dem die US-Konkurrenz scheitert. Das ist nicht Marketing — das ist ein direkter Sales-Vorteil im Mid-Market und im öffentlichen Sektor.

Eine Checkliste zum Anfangen

Wer pragmatisch starten will, geht in dieser Reihenfolge vor.

1. Liste deine Subprozessoren auf. Jeder Service, den deine App aufruft. Schreib ihn auf.
2. Markiere jeden US-Provider. Das sind deine Migrationskandidaten.
3. Identifiziere, welche Daten dort liegen. E-Mails, Passwörter, Inhalte, Logs, Embeddings.
4. Priorisiere nach Sensitivität. Auth und Datenbank zuerst, Logs danach, Code-Storage zum Schluss.
5. Wähle pro Kategorie einen souveränen Ersatz. Container-Hosting, managed Postgres, S3-kompatibler Storage, EU-LLM oder Prompt-Minimierung.
6. Migriere in kleinen Schritten. Datenbank-Cutover mit Logical Replication, kein Big Bang.
7. Dokumentiere alles in einem Verzeichnis der Verarbeitungstätigkeiten. Das ist ohnehin DSGVO-Pflicht.

Das ist keine sechsmonatige Transformation. Für eine typische vibe-coded App ist das ein verlängertes Wochenende plus zwei Wochen Schatten-Betrieb, in dem du beide Umgebungen parallel laufen lässt und dann den DNS-Switch machst.

Wenn du jetzt nicht handelst

Du hast zwei Optionen. Entweder du wartest, bis ein User, ein Kunde oder eine Behörde dich zwingt. Dann migrierst du unter Stress, mit Anwaltsterminen, ohne Verhandlungsmacht. Oder du machst es jetzt, mit Zeit und nüchterner Architektur. Die zweite Variante kostet ein paar Wochenenden. Die erste kostet Reputation, möglicherweise Umsatz und ziemlich sicher Nerven.

lowcloud ist eine europäische Container-Plattform, die den Push-to-Deploy-Flow erhält, aber Container Deployment, managed Postgres und Stateful Deployment auf europäischer Infrastruktur kombiniert. One-Click-Deployment, kein Aufwand für DevOps, eingebautes Monitoring, die Vibe bleibt, die Souveränität kommt dazu.

Du hast in drei Stunden eine App gebaut. Nimm dir zwei Stunden, damit sie dir nicht in zwei Jahren um die Ohren fliegt.