Bolt.new-App produktionsreif machen

This page in English

Kurz gesagt

Damit eine Bolt.new-App produktionsreif wird, gehört der Code in ein eigenes Git-Repository, Deployments laufen reproduzierbar über eine Pipeline, und Geheimnisse bleiben aus dem Browser-Bundle heraus. Dazu kommen eine Produktivdatenbank mit Backups und Migrationen, Fehler-Monitoring, automatisierte Tests für die wichtigsten Abläufe sowie die Pflichtangaben, die für eine Website in Deutschland gelten.

Prototyp und Produktivbetrieb im Vergleich

Bolt.new von StackBlitz baut und startet Ihre Anwendung direkt im Browser, in sogenannten WebContainers. Das macht den Einstieg so schnell. Der Produktivbetrieb stellt andere Anforderungen:

ThemaTypischer PrototypProduktiv
Codeliegt im Bolt-Projekteigenes Git-Repository als Referenz
DeploymentKlick im Editorreproduzierbar über CI-Pipeline
Geheimnissein .env oder im Codenur serverseitig, rotierbar
Dateneine Datenbank für allesgetrennte Umgebungen, Backups, Migrationen
Fehlerfallen niemandem aufMonitoring mit Benachrichtigung

Code und Zugänge in die eigene Hand nehmen

Verbinden Sie das Projekt mit GitHub oder laden Sie es herunter und machen Sie dieses Repository zur einzigen Wahrheit. Hosting, Datenbank, Domain und Drittdienste sollten auf Ihr Unternehmen laufen, nicht auf das private Konto der Person, die den Prototyp gebaut hat. Prüfen Sie, ob sich das Projekt auf einem frischen Rechner mit npm ci und festgelegter Node.js-Version bauen lässt. Erst dann sind Sie wirklich unabhängig. Die Nutzungsbedingungen des Werkzeugs zu Rechten am Code sollten Sie ebenfalls kennen, spätestens wenn Investoren oder Kunden danach fragen.

Hosting, Umgebungsvariablen und Datenbank

Bolt bringt eine eingebaute Veröffentlichung mit, unter anderem über Netlify. Für den Produktivbetrieb sollten Deployments aus dem Repository über eine Pipeline erfolgen, damit jede Version nachvollziehbar ist.

Ein häufiger Fehler betrifft Umgebungsvariablen: Viele Bolt-Projekte nutzen Vite, und Vite übernimmt jede Variable mit dem Präfix VITE_ in das Browser-Bundle. Für eine öffentliche Supabase-URL ist das richtig, für Zahlungs- oder KI-Schlüssel nicht. Diese gehören in serverseitige Funktionen. Bereits offengelegte Schlüssel müssen Sie beim Anbieter neu erzeugen.

Je nach Einrichtung liegen die Daten in Supabase oder in einem von Bolt bereitgestellten Backend. In beiden Fällen gilt: getrennte Entwicklungs- und Produktivdatenbank, Schemaänderungen als Migrationen im Repository, aktivierte Backups mit mindestens einem getesteten Restore. Bei Supabase zusätzlich Row Level Security auf jeder Tabelle prüfen.

Monitoring und Tests

  • Fehler-Monitoring etwa mit Sentry, inklusive Source Maps aus dem Build, damit Fehlermeldungen auf echte Codezeilen zeigen.
  • Verfügbarkeitsüberwachung für die Startseite und wichtige API-Endpunkte.
  • End-to-End-Tests mit Playwright für Registrierung, Login und den Kernprozess.
  • Unit-Tests mit Vitest für Preislogik, Berechtigungen und Datenumwandlungen.
  • CI, die bei jedem Pull Request Typprüfung, Linting und Tests ausführt.

Mit diesem Sicherheitsnetz können Sie Bolt oder einen anderen Coding-Agenten weiter nutzen, ohne dass jede Änderung unbemerkt etwas zerstört. Volle Testabdeckung ist am ersten Tag nicht nötig. Beginnen Sie mit den Abläufen, die Umsatz bringen oder bei einem Ausfall den größten Schaden anrichten, und erweitern Sie die Tests mit jedem gefundenen Fehler.

Typische Stolpersteine beim Umzug aus dem Browser

Was in WebContainers läuft, verhält sich auf einem echten Server nicht immer gleich. Achten Sie besonders auf:

  • Pakete mit nativen Abhängigkeiten, die im Browser durch Ersatzlösungen liefen,
  • fest eingetragene Vorschau-URLs in Login-Weiterleitungen und CORS-Einstellungen,
  • fehlende Fehlerseiten und Weiterleitungsregeln für Single-Page-Anwendungen beim Hoster,
  • Abhängigkeiten ohne Lockfile, die beim nächsten Build plötzlich in neuer Version installiert werden.

Rechtliches für den Start in Deutschland

Bevor die Anwendung öffentlich erreichbar ist, sollten Impressum und Datenschutzerklärung stehen, eingebundene Dienste wie Monitoring, Analyse oder Schriftarten auf Einwilligungspflichten geprüft und Auftragsverarbeitungsverträge mit Hosting- und Datenbankanbietern geschlossen sein. Anbieter mit Datenhaltung in der EU vereinfachen vieles. Diese Hinweise sind allgemein und ersetzen keine Rechtsberatung.

So unterstützt jocapps

OnlineAppCreator ist unser ISO-zertifiziertes B2B- und B2G-Delivery-Team in Deutschland. Es bringt KI-gebaute Prototypen wie Bolt-Apps in den Produktivbetrieb: Übergabe von Repository und Zugängen, Hosting und CI, Umgang mit Geheimnissen, Absicherung der Datenbank, Monitoring, Tests und auf Wunsch langfristige Betreuung per SLA. Mehr im englischsprachigen Leitfaden zu Teststrategien für KI-generierten Code, beim Leistungsbereich Prototyp zu Produktion oder im kostenlosen 30-minütigen Erstgespräch über den Terminplaner.

Häufige Fragen

Muss ich meine Bolt-App für den Produktivbetrieb neu schreiben?

Meist nicht vollständig. Häufig bleibt die Oberfläche erhalten, während Datenzugriff, Geheimnisse, Fehlerbehandlung und Tests überarbeitet werden.

Warum ist mein API-Schlüssel im Browser sichtbar?

Variablen mit dem Präfix VITE_ landen bei Vite bewusst im Browser-Bundle. Verschieben Sie geheime Schlüssel in eine serverseitige Funktion und erzeugen Sie sie neu.

Kann ich weiter in Bolt entwickeln, wenn das Projekt produktiv ist?

Ja, sofern das Git-Repository die Referenz bleibt und Änderungen über Pull Requests mit Tests laufen. Bei wachsender Codebasis wechseln viele Teams in eine IDE oder zu einem Coding-Agenten.

Guides zum Thema

Sprechen wir über Ihr Projekt

Ehrliche Einschätzung zu Idee, Prototyp oder App.

  • 30 Minuten
  • Kostenlos
  • Unverbindlich

Kostenloses Gespräch buchen [email protected]