Attek Solutions
RatgeberZuletzt geprüft: 09/2026

Bolt.new: die häufigsten Probleme mit Tokens, Supabase und Deployment — und ihre Lösungen

Antwort in Kürze

Die häufigsten Probleme mit Bolt.new betreffen fünf Bereiche: den Tokenverbrauch bei großen Projekten, die Wahl zwischen integrierter Datenbank und Supabase, Fehler in der Supabase-Anbindung, das Deployment und die Frage nach dem Code-Eigentum. Dieser Artikel zeigt für jeden Bereich, warum das Problem entsteht und wie es sich lösen lässt.

Die fünf Problemfelder aller AI App Builder im Überblick →

Warum verbraucht Bolt.new so viele Tokens?

Weil der Agent vor einer Änderung große Teile des bestehenden Projekts analysieren muss — nicht nur der Prompt kostet, sondern der Kontext dahinter. Bei großen, eng verbundenen Codebasen wächst dieser Anteil mit jeder Datei.

Der Tokenverbrauch ist eines der meistdiskutierten Themen rund um Bolt. Viele Nutzer erwarten, dass nur die eigene Eingabe zählt. Tatsächlich liest der Agent den Projektkontext mit, bevor er eine Änderung durchführen kann.

Typische Kostentreiber

  • große Codebasis
  • viele miteinander verbundene Dateien
  • lange Prompts
  • wiederholte Fehlerbehebung
  • große Refactorings
  • unklare Anforderungen
  • wiederholtes Einlesen des Projektkontexts

Warum Debugging teuer wird

Ein typischer Problemzyklus sieht so aus:

  1. Der Agent führt eine Änderung durch.
  2. Ein Fehler entsteht.
  3. Der Agent analysiert mehrere Dateien.
  4. Der Fehler wird teilweise behoben.
  5. Eine andere Funktion bricht.
  6. Der Agent analysiert erneut den gesamten Kontext.

Genau solche Schleifen treiben den Verbrauch. Änderungen klein und isoliert halten — und vor großen Refactorings einen stabilen Zwischenstand sichern, zu dem sich zurückkehren lässt.

Bolt Database oder Supabase?

Die Frage ist keine technische, sondern eine strategische: Wie viel Einfachheit ist wie viel langfristige Unabhängigkeit wert? Die integrierte Option startet schneller, die externe bleibt bestehen, wenn das Projekt die Plattform verlässt.

Bolt Database eignet sich, wenn

  • möglichst wenig Konfiguration gewünscht ist
  • das Projekt schnell starten soll
  • Frontend und Backend eng innerhalb der Plattform bleiben sollen

Supabase eignet sich, wenn

  • externe Kontrolle über die Datenbank wichtig ist
  • ein bestehendes Supabase-Projekt genutzt wird
  • Auth und Datenbank unabhängig von Bolt betrieben werden sollen
  • langfristige Portabilität wichtig ist

Nicht die technisch bessere Datenbank ist automatisch die richtige. Entscheidend ist, wie wichtig Einfachheit gegenüber langfristiger Unabhängigkeit ist — und diese Entscheidung fällt am besten vor der ersten Tabelle, nicht nach der fünfzigsten.

Warum funktioniert Bolt mit Supabase nicht?

Meist wegen Konfiguration, nicht wegen Code: falsche Environment Variables, fehlende Tabellen, abweichende Spaltennamen, Row-Level-Security, die Anfragen blockiert, oder nicht vollständig ausgeführte Migrationen.

Supabase ist leistungsfähig, bringt aber zusätzliche Komplexität mit. Diese Komplexität zeigt sich fast immer an den Übergängen zwischen Entwicklungs- und Produktionsumgebung.

Häufige Fehlerquellen

  • falsche Environment Variables
  • fehlende Tabellen
  • falsche Spaltennamen
  • Row-Level-Security blockiert Anfragen
  • Auth-Nutzer und Profildaten sind nicht korrekt verknüpft
  • Migrationen wurden nicht vollständig ausgeführt
  • Entwicklungs- und Produktionsumgebung verwenden unterschiedliche Werte

Ein Datenbankproblem wirkt im Frontend häufig wie ein UI-Fehler. Wer dort sucht, findet nichts — die Ursache liegt meist in fehlenden Rechten oder einer inkonsistenten Datenstruktur.

Warum funktioniert das Deployment nicht?

Weil die Vorschau andere Bedingungen hat als die produktive Umgebung: andere Variablen, andere Domain, andere Rechte. Eine App kann in der Vorschau korrekt aussehen und beim Deployment trotzdem scheitern.

Typische Ursachen

  • fehlende Environment Variables
  • Build Errors
  • falsche API-Endpunkte
  • externe Dienste erlauben die Production-Domain nicht
  • Auth-Redirects zeigen noch auf die Entwicklungsumgebung
  • Datenbankzugriffe funktionieren nur lokal

Deployment-Checkliste

  • Production Build
  • Environment Variables
  • Auth Redirect URLs
  • Datenbankzugriff
  • API Keys
  • Domain
  • HTTPS
  • Error Logs

Kann man Bolt verlassen und den Code behalten?

Über GitHub ja — und das gehört zum Projektstart, nicht ans Projektende. Ein externes Repository ist die Voraussetzung dafür, dass ein MVP später von einem Entwicklerteam übernommen werden kann.

Code Ownership ist besonders relevant, wenn aus einem MVP eine betriebene Anwendung werden soll. Ein Repository außerhalb der Plattform liefert:

  • externe Versionshistorie
  • Backups
  • lokale Entwicklung
  • Code Reviews
  • alternative Hosting-Anbieter
  • einen einfacheren Übergang an Entwickler

Zu bedenken ist, was nicht mit dem Code wandert: Datenbank, Auth-Konfiguration, Secrets und Hosting-Einstellungen. Wer nur den Code sichert, hat die halbe Anwendung gesichert.

Wie der Übergang von einem AI-generierten Prototyp zu einer betriebsfähigen Anwendung abläuft, haben wir hier beschrieben: Wenn No-Code nicht mehr trägt.

Wofür sich Bolt.new gut eignet

Für Projekte, in denen schnell echter Code entstehen soll und Code, Vorschau und Entwicklungsumgebung eng beieinander liegen — technischere MVPs, bei denen das Team am Code selbst arbeiten möchte.

Die größten Herausforderungen entstehen bei steigender Komplexität. Fünf Bereiche entscheiden darüber, ob ein Bolt-Projekt tragfähig bleibt: Tokenkosten, Debugging, Datenbankarchitektur, Deployment und Versionierung. Wer sie früh strukturiert, kann Bolt deutlich effizienter einsetzen.

Einordnung für deutsche Unternehmen

Welche Fragen zu klären sind, hängt bei Bolt.new an einer frühen Entscheidung: Liegt die Datenbank in der Plattform oder in einem eigenen Supabase-Projekt? Davon hängen Datenstandort, Vertragslage und Exportfähigkeit ab.

Diese Entscheidung wird meist aus technischer Bequemlichkeit getroffen und hat trotzdem die größere rechtliche Wirkung. Bei einem eigenen Datenbankprojekt bleiben Standort, Zugriff und Export in eigener Hand; bei der integrierten Option verschiebt sich beides zum Plattformanbieter.

  • Datenstandort

    Wo laufen Anwendung, Datenbank und Backups — und wurde die Region bewusst gewählt? Bei externer Datenbank ist zusätzlich zu klären, wo die Anwendung selbst gehostet wird.

  • Auftragsverarbeitung

    Ein Vertrag nach Art. 28 DSGVO wird für jeden beteiligten Anbieter gebraucht: Plattform, Datenbankdienst, Hosting und die Dienste, die die Anwendung selbst einbindet.

  • Zu prüfen

    Bei personenbezogenen Daten Löschkonzept, Betroffenenrechte und das Verzeichnis von Verarbeitungstätigkeiten. Bei buchungsrelevanten Daten Aufbewahrung, Unveränderbarkeit und Export nach GoBD.

Praktisch bewährt es sich, die Frage vor der ersten echten Datenzeile zu beantworten. Eine Datenbank lässt sich am Anfang in einer Stunde verlagern und nach sechs Monaten Produktivbetrieb kaum noch ohne Migrationsprojekt.

Dieser Abschnitt ist beschreibend. Welche Anforderungen für Ihr Unternehmen konkret gelten und ob sie erfüllt sind, beurteilt Ihr Datenschutzbeauftragter — nicht dieser Artikel.

Häufige Fragen

Warum verbraucht Bolt.new so viele Tokens?

Weil der Agent vor jeder Änderung große Teile des bestehenden Projekts analysieren muss. Nicht nur der Prompt zählt, sondern der Projektkontext dahinter — bei großen, eng verbundenen Codebasen und in Debugging-Schleifen wächst dieser Anteil stark.

Bolt Database oder Supabase — was ist die richtige Wahl?

Bolt Database, wenn möglichst wenig Konfiguration gewünscht ist und das Projekt schnell starten soll. Supabase, wenn externe Kontrolle über die Datenbank, ein bestehendes Projekt, unabhängiger Betrieb von Auth und Datenbank oder langfristige Portabilität wichtig sind.

Warum funktioniert Bolt mit Supabase nicht?

Meist wegen Konfiguration statt Code: falsche Environment Variables, fehlende Tabellen, abweichende Spaltennamen, Row-Level-Security, die Anfragen blockiert, nicht verknüpfte Auth-Nutzer und Profildaten oder unvollständig ausgeführte Migrationen. Ein Datenbankproblem wirkt im Frontend oft wie ein UI-Fehler.

Warum funktioniert das Deployment bei Bolt.new nicht?

Weil die Vorschau andere Bedingungen hat als die produktive Umgebung. Typische Ursachen sind fehlende Environment Variables, Build Errors, falsche API-Endpunkte, externe Dienste, die die Production-Domain nicht erlauben, und Auth-Redirects, die noch auf die Entwicklungsumgebung zeigen.

Kann man Bolt verlassen und den Code behalten?

Ja, über ein GitHub-Repository — sinnvollerweise ab Projektstart. Es liefert externe Versionshistorie, Backups, lokale Entwicklung, Code Reviews und alternative Hosting-Anbieter. Datenbank, Auth-Konfiguration, Secrets und Hosting-Einstellungen wandern allerdings nicht mit dem Code.

Was ist bei Bolt.new datenschutzrechtlich zu klären?

Zuerst, ob die Datenbank in der Plattform oder in einem eigenen Projekt liegt — davon hängen Datenstandort, Vertragslage und Exportfähigkeit ab. Ein Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO wird für jeden beteiligten Anbieter gebraucht. Die Bewertung liegt beim Datenschutzbeauftragten.

Autor

Jan Klädtke

Geschäftsführer, Attek Solutions GmbH

Wenn Sie an diesem Punkt sind

Diese Probleme lassen sich eine Zeit lang lösen. Wenn Ihre Anwendung aber geschäftskritisch wird — echte Nutzer, sensible Daten, Schnittstellen, Nachweispflichten —, ist die Frage irgendwann nicht mehr, wie ich das repariere, sondern wer das dauerhaft betreibt. Attek Solutions entwickelt aus funktionierenden Prototypen betriebsfähige Software — zur Miete, ab 500 € im Monat, erste produktive Version nach ein bis zwei Monaten.

Wenn No-Code nicht mehr trägt →
Erstgespräch buchen

DSGVO-konform · Hosting in Deutschland · Persönlicher Support