Cursor Build Live Apps: Funktionen, Preise und Grenzen

Viele KI-generierte Apps kommen über localhost nie hinaus. Genau diese Lücke soll Cursors Release Build Live Apps vom 5. November schließen: Ein Cloud-Agent erstellt und hostet eine Web-App. Nach Lektüre des Changelogs, der Dokumentation und früher Nutzerfragen fällt das Urteil klar aus: stark für interne Tools und Prototypen hinter Cursor SSO, bislang aber keine Lösung für komplexe oder compliance-kritische Produktions-Backends.

Das liefert Build Live Apps

Build Live Apps ist ein Workflow für Cloud-Agents, der aus einer natürlichsprachlichen Anforderung eine bereitgestellte Web-App macht. Cursor kündigte die Funktion am 5. November 2026 im Changelog an. Die begleitende Apps-Dokumentation beschreibt denselben Ablauf: Cloud-Agent per Prompt beauftragen, Vorschau in einer Leiste prüfen, URL auswählen, Sicherheitsprüfungen bestehen und anschließend über einen Live-Link veröffentlichen.

Der Auftrag muss eindeutig formuliert sein. Laut Cursor-Dokumentation sollte der Prompt den Agenten ausdrücklich auffordern, eine App zu bauen. Apps lassen sich entweder von Grund auf mit Cursor Origin erstellen, wodurch ein neues Repository entsteht, oder aus einem vorhandenen GitHub-Repository bereitstellen. Apps bauen können ausschließlich Cloud-Agents.

Benötigt die Anwendung Speicher, stellt Cursor eine PostgreSQL-Datenbank bereit. Das Hosting läuft für jeden Nutzer beziehungsweise jedes Team in einem eigenen, isolierten Hosting-Account. Team-Apps nutzen Cursor SSO: Empfänger müssen sich also zuerst bei Cursor anmelden. Nutzer individueller Pläne können zudem öffentliche Apps ohne Anmeldung veröffentlichen.

Einige Einschränkungen sind von Anfang an relevant. GitLab-Support ist geplant, aber noch nicht verfügbar. Auch benutzerdefinierte Domains sind nicht bestätigt. Cursor schreibt, dass der Publisher eine eindeutige Domain auswählt; laut Dokumentation lässt sich die URL später ändern. Einen Ablauf für eigene Domains zeigt jedoch keine der beiden Seiten.

Zu Frameworks, Laufzeiten, Regionen, PostgreSQL-Version, Backups, Skalierungsverhalten, Bandbreitenkontingenten oder einem SLA finden sich keine Angaben. Das Hosting ist rechtlich von den Cursor-Diensten getrennt und wird laut „as is“ und „as available“ bereitgestellt. Cursor behält sich außerdem vor, Subdomains oder Apps zu widerrufen oder zu sperren.

Veröffentlichen nur nach vier Pflichtprüfungen – plus KI-Review

Ohne eine ausdrückliche Veröffentlichung durch den Nutzer geht nichts live. Die bloße Vorbereitung macht die App nicht erreichbar. Bei jeder Veröffentlichung laufen vier verpflichtende Prüfungen, die auch dann aktiv bleiben, wenn ein Team das separate KI-Review deaktiviert:

• Die Veröffentlichung wird blockiert, wenn App-Dateien einen API-Key oder Zugriffstoken enthalten.
• Credential-Dateien wie private Schlüssel oder Service-Account-Schlüssel werden blockiert.
• .env-Dateien werden aus dem veröffentlichten Bundle ausgeschlossen.
• Source Maps werden entfernt, damit Besucher den ursprünglichen Quellcode nicht im Browser rekonstruieren können.

Schlägt eine Prüfung fehl, listet Cursor das Problem auf. Der Nutzer kann den Agenten mit der Behebung beauftragen und es erneut versuchen.

Das zusätzliche KI-Sicherheitsreview liest die Anwendungsdateien und kann schwerwiegende Probleme vor der Veröffentlichung blockieren. Team-Administratoren können dem Review-Prompt organisationsspezifische Anweisungen hinzufügen. Eigene Anweisungen können Regeln ergänzen, aber Cursors integrierte Prüfungen weder entfernen noch abschwächen. Administratoren dürfen manche Publish-Blockaden übergehen, nicht jedoch Blockaden wegen schädlichem Code, hartcodierten Secrets oder offengelegten Zugangsdaten. Änderungen an diesen Einstellungen erscheinen im Team-Audit-Log.

Entscheidender als das, was dieses Gate erkennt, ist allerdings, was es nicht belegt:

„Der Haken: Bestandene Sicherheitsprüfungen beweisen nicht, dass die richtigen Personen den richtigen Zugriff auf deine App haben.“ — @0node0, echter Nutzer

Cursor nennt Secrets und offengelegte Zugangsdaten als Beispiele. Nicht angegeben ist, dass jede App auf Autorisierung, zeilenbasierte Berechtigungen, SQL Injection, Abhängigkeiten oder Geschäftslogik geprüft wird. Die Analyse von TechRepublic vom 6. November kommt zum gleichen Schluss: Testen Sie mit mehreren Konten und unterschiedlichen Berechtigungsstufen, denn es ist nicht belegt, dass der Zugriff eines angemeldeten Nutzers auf die Datensätze eines anderen Nutzers abgedeckt wird.

Kosten, Vercel und Secrets: die wichtigsten Fragen

Kostet das Hosting extra? Einen separaten Preis für Hosting oder Datenbank hat Cursor nicht veröffentlicht. Build Live Apps ist kein eigenständiges Abo, sondern in kostenpflichtigen Plänen mit Cloud-Agent-Zugang enthalten. Die konkreten Preise stammen aus der Plantabelle von TechRepublic, nicht von Cursors Feature-Seiten:

Cursor arbeitet mit einem gemeinsamen wöchentlichen KI-Nutzungskontingent (TechRepublics Planübersicht), veröffentlicht auf diesen Seiten aber keine Token-, Request- oder Compute-Werte je Tarif. Modelle von Drittanbietern können separate Kosten verursachen (TechRepublic). Grenzen für Datenbank, Speicher, Traffic und Gleichzeitigkeit bleiben offen. Die 30 $ sind daher als Einstiegspreis zu verstehen, nicht als vollständige Betriebskosten. Prüfen Sie die Kontingente, bevor Sie eine kundenorientierte Last auf dem integrierten Hosting betreiben.

Ersetzt Build Live Apps Vercel? Für komplexe oder compliance-kritische Produktions-Backends noch nicht. Der integrierte Weg passt zu Postgres, SSO und einem teilbaren Link. Die klassische Kombination aus GitHub und Vercel, Netlify, Railway, Render oder einem VPS bleibt für individuelle Architekturen und regulierte Daten zuständig; die Tabelle unten ordnet die Szenarien vollständig zu. In Reddit-Threads zum Hosting taucht immer wieder derselbe Maßstab auf: Entscheidend für den Hoster ist, wie zustandsbehaftet oder langlebig die Workload ist.

„Die meisten Cursor-Demos, die ich in meiner Timeline sehe, konzentrieren sich auf die UI … die meisten sind nicht für echte zahlende Nutzer bereitgestellt.“ — @mayowaoshin, echter Nutzer

Wo liegen Secrets – und sieht der Agent sie? Laut Cursor-Dokumentation sieht der Coding-Agent niemals Secret-Werte. Apps, die ein Data Warehouse oder eine externe API benötigen, fordern den Nutzer zur Eingabe der Secrets auf. Team-Secrets werden normalerweise von einem Team-Administrator im Apps-Dashboard erstellt oder später über dasselbe Dashboard ergänzt.

Team-Administratoren können jede Team-App und jedes Team-Secret sehen. Das dient der Governance, markiert aber auch eine Vertrauensgrenze, die vor dem Einfügen von Produktionsschlüsseln klar sein sollte. Automatisierte Clients wie Skripte, CI-Jobs und Grok Bot greifen mit einem schlüsselbasierten Header auf geschützte Apps zu (x-cursor-app-token) – nicht über Cookies oder Query-Parameter.

Wann Live Apps passt – und wann das klassische Deployment besser bleibt

Der klassische Weg bringt weiterhin eigenen Einrichtungsaufwand mit sich: MCP-Konfiguration, Hosting-Zugangsdaten, Umgebungsvariablen und RLS-Härtung. Das zeigt auch der vierwöchige Weg eines Entwicklers von der Landingpage über Vercel bis zu Supabase Auth.

Checkliste vor dem ersten Teilen

Cursors Prüfungen erkennen geleakte Secrets und Credential-Dateien. Übrig bleiben Risiken bei Berechtigungen, der Einbindung von Umgebungen, asynchronen Seiteneffekten und ungelesenem Code. Arbeiten Sie diese Liste vor der ersten Freigabe ab – auch bei einem internen Tool.

1. Sauber neu bauen und dann den Diff lesen. Lassen Sie den Agenten den echten Produktions-Build ausführen, nicht nur den Dev-Server. Öffnen Sie jede geänderte Datei rund um Zahlungen, Authentifizierung und Datenschreibvorgänge. Ist das Projekt bereits so gewachsen, dass sich der Diff nicht mehr sinnvoll prüfen lässt, stellen Sie einen Checkpoint wieder her und teilen Sie die Aufgabe auf, statt sich per Prompt durch das Chaos zu arbeiten.
2. Berechtigungen mit zwei Accounts testen. Melden Sie sich einmal als Administrator und einmal als eingeschränktes Mitglied an. Erstellen Sie einen Datensatz als Nutzer A und versuchen Sie, ihn als Nutzer B zu lesen, zu bearbeiten und zu löschen. Ein bestandener Sicherheitsbericht ist kein Beleg dafür, dass die Eigentümerschaft auf Zeilenebene korrekt umgesetzt ist.
3. Secrets durchgängig prüfen. Stellen Sie sicher, dass kein Schlüssel im Frontend-Code gebündelt wird, keine .env ausgeliefert wird und jede externe Zugangsdatenkombination nur die minimal nötigen Berechtigungen besitzt. Entfernen Sie direkte URLs zur Produktionsdatenbank aus der für den Agenten erreichbaren Umgebung. Ein Bericht auf r/cursor beschreibt, wie Cursor direkt in eine produktive Supabase-Instanz statt über GitHub deployte.
4. Asynchrone Pfade wirklich ausführen. Lösen Sie einen echten Webhook aus, wiederholen Sie ihn und brechen Sie ihn während der Ausführung ab. Prüfen Sie das Verhalten des Connection Pools bei paralleler Nutzung. Stille Webhook-Fehler und erschöpfte Pools gehören zu den Problemen, die Nutzer nach eigener Aussage erst nach dem Launch entdecken.
5. Updates und Rollbacks definieren. Klären Sie, wer veröffentlichen darf, wer eine blockierte Veröffentlichung übergehen kann, wer die Veröffentlichung zurückziehen kann und wohin das Audit-Log geht. Halten Sie fest, wie ein fehlerhaftes Deployment zurückgesetzt und wie eine Schema-Migration ausgeführt wird: Die Dokumentation beschreibt das Veröffentlichen, nicht aber Versionshistorie oder Rollbacks.

„Sobald eine App localhost verlässt, nimmt sie ihre Secrets mit.“ — @1PasswordDev, echter Nutzer zur Secret-Isolation pro App

Bleibt einer dieser Punkte unbeantwortet – etwa weil kein Staging-Projekt, kein zweiter Testaccount oder kein Rollback vorhanden ist –, sollte die App auf einem teaminternen Link oder dem klassischen Stack bleiben, bis das geklärt ist.

FAQ

Braucht Build Live Apps einen kostenpflichtigen Cursor-Plan?

Ja. Build Live Apps läuft nur in kostenpflichtigen Plänen mit aktivierten Cloud-Agents. Plus für 8 $/Monat qualifiziert sich nicht. Premium für 30 $/Monat ist der günstigste berechtigte Individualplan.

Kann Cursor eine App aus meinem bestehenden Repository bauen?

Ja, aus einem vorhandenen GitHub-Repository oder von Grund auf mit Cursor Origin. GitLab ist geplant, aber nicht verfügbar, und Local Agents können keine Apps bauen.

Kann eine Team-App öffentlich sein?

Team- und Enterprise-Pläne deaktivieren öffentliche Freigaben standardmäßig. Ein Administrator kann sie im Apps-Dashboard aktivieren. Individualpläne können öffentliche Apps direkt veröffentlichen.

Unterstützt Cursor eigene Domains?

Cursor sagt, dass der Publisher eine eindeutige Domain auswählt und sie später ändern kann. Weder Changelog noch Dokumentation bestätigen jedoch das Mapping eigener Domains. Bis Cursor etwas anderes dokumentiert, ist von einer Cursor-verwalteten URL auszugehen.

Wie greifen Skripte oder Bots auf eine private App zu?

Stellen Sie einen Cursor-API-Key bereit und senden Sie ihn bei jeder Anfrage im Header x-cursor-app-token. Persönliche Keys öffnen alles, worauf der Inhaber Zugriff hat. Team-Keys öffnen nur ausdrücklich freigegebene Team-Apps.

Was passiert, wenn ich eine App zurückziehe?

Administratoren können jede Team-App zurückziehen. Wird die Einstellung für öffentliche Apps deaktiviert, werden vorhandene öffentliche Apps wieder nur für das Team sichtbar. Cursor dokumentiert kein Verhalten für Aufbewahrung, Backups oder Datenexport nach dem Zurückziehen.

Build Live Apps nimmt den Hosting-Aufwand zwischen einem funktionierenden Prototypen und einem nutzbaren Link ab. Die Prüf-, Berechtigungs- und Verantwortungsarbeit, die darüber entscheidet, ob andere das Ergebnis sicher nutzen können, entfällt dadurch nicht.

Weiterführend: Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained