Deployment verstehen: Was nach dem Klick auf "Launchen" passiert

TL;DR: Wenn du bei einem AI-App-Builder auf "Launchen" klickst, passieren im Hintergrund sechs Dinge: Dein Code wird zu statischen und serverseitigen Artefakten gebaut, diese Artefakte werden auf ein CDN und serverlose Infrastruktur gepusht, die DNS deiner Domain wird auf diese Infrastruktur ausgerichtet, SSL-Zertifikate werden ausgestellt, deine Datenbank wird bereitgestellt und befüllt, und Umgebungsvariablen (API-Keys, Secrets) werden geladen. Danach beginnen Monitoring und Logs, Daten zu sammeln. Diese Ebene zu verstehen ist wichtig, weil Deployment der Bereich ist, in dem die meisten nicht-technischen Gründer auf Probleme stoßen, die sie nicht debuggen können — DNS-Propagation, falsch gesetzte Umgebungsvariablen, fehlgeschlagene Builds. Dieser Guide erklärt jede Phase in einfacher Sprache, was jede Plattform unterschiedlich macht, und die operativen Grundlagen nach dem Launch, die funktionierende Produkte von kaputten unterscheiden.

Einleitung

Für nicht-technische Gründer, die mit AI-App-Buildern shippen, fühlt sich "Launchen klicken" magisch an — und meistens funktioniert es. Aber wenn nicht, liegen die Probleme in einer Ebene, die die meisten Gründer nie gelernt haben. DNS-Propagation. SSL-Zertifikatsausstellung. Build-Pipelines. Umgebungsvariablen. CDN-Cache-Invalidierung. Allein das Vokabular ist einschüchternd, und der AI-Builder erklärt nicht immer, was genau fehlschlägt.

Dieser Guide entmystifiziert Deployment in einfacher Sprache. Was tatsächlich passiert, wenn du auf Launchen klickst, was jede Komponente macht, was jede Plattform unterschiedlich handhabt und welche operativen Grundlagen nach dem Launch deine App am Laufen halten. Am Ende verstehst du die Deployment-Ebene gut genug, um die häufigsten Probleme zu debuggen und die richtigen Fragen zu stellen, wenn etwas kaputtgeht.

Die 30-Sekunden-Version

Wenn du auf Launchen klickst, macht die Plattform sechs Dinge.

1. Baut deinen Code — Verwandelt deinen Quellcode in die Dateien, die tatsächlich laufen (HTML, JS-Bundles, Serverfunktionen)
2. Pusht auf Infrastruktur — Schickt diese Dateien an Server rund um die Welt (CDN für statische Inhalte, serverlose Funktionen für dynamische)
3. Konfiguriert DNS — Richtet deine Domain (deinemarke.de) auf diese Infrastruktur aus
4. Stellt SSL aus — Sorgt für das grüne Schloss, damit die URL https:// statt http:// ist
5. Stellt die Datenbank bereit — Erstellt die Produktionsdatenbank und befüllt sie mit dem Schema
6. Lädt Umgebungsvariablen — Verbindet sich mit Stripe, OpenAI, Resend und anderen Diensten über API-Keys

Jeder dieser Schritte kann unabhängig fehlschlagen. Zu wissen, welcher gerade fehlschlägt, ist der Schlüssel zum Debuggen von Deployment-Problemen.

Phase 1: Der Build

Dein Quellcode ist nicht das, was in Produktion läuft. Die Build-Phase wandelt den Quellcode in lauffähige Artefakte um.

Was während des Builds passiert

• JavaScript-/TypeScript-Transpilation — Moderner Code (TypeScript, JSX, ES2024) wird zu älterem JavaScript kompiliert, das alle Browser ausführen können
• Bundling — Hunderte Quelldateien werden zu wenigen optimierten Bundles zusammengefasst, für schnelleres Laden
• Minifizierung — Code wird komprimiert (Variablennamen verkürzt, Whitespace entfernt), um die Dateigröße zu reduzieren
• Tree Shaking — Ungenutzter Code wird aus den Bundles entfernt
• Statische Seitengenerierung — Seiten, die keine nutzerspezifischen Daten brauchen, können als HTML vorgerendert werden
• Asset-Optimierung — Bilder werden komprimiert; CSS wird von ungenutzten Styles bereinigt

Warum Builds fehlschlagen

• Fehlende Dependency — Dein Code referenziert ein Package, das nicht installiert wurde
• TypeScript-Fehler — Typkonflikte, die der Build erkennt, obwohl die Vorschau einwandfrei lief
• Speicherüberlauf — Große Projekte überschreiten das Speicherlimit des Build-Servers
• Fehlende Umgebungsvariable, die zur Build-Zeit referenziert wird — Manche Env-Vars müssen schon beim Build existieren, nicht erst zur Laufzeit
• Versionskonflikt — Node.js- oder npm-Version unterscheidet sich zwischen Vorschau und Build

Wenn ein Build fehlschlägt, zeigt der AI-App-Builder meist die Fehlerprotokolle an. Diese Logs zu lesen ist die erste Debugging-Fähigkeit. Die Fehlermeldungen sind oft verständlicher, als sie aussehen — "Cannot find module X" bedeutet meist, dass X referenziert, aber nicht installiert wurde; "Type Y is not assignable" bedeutet einen Typkonflikt in TypeScript.

Phase 2: Push auf die Infrastruktur

Moderne Web-Apps laufen auf zwei Arten von Infrastruktur, oft gemeinsam.

Statische Dateien auf einem CDN

Deine HTML-, CSS-, JavaScript-Bundles und Bilder gehen auf ein CDN (Content Delivery Network). Ein CDN hat Server rund um die Welt — Cloudflare hat über 300 Standorte, AWS CloudFront über 600 — und der nächstgelegene Server zu jedem Nutzer liefert die Dateien aus. Deshalb lädt deine App in Millisekunden, egal ob der Nutzer in São Paulo oder Singapur sitzt.

Serverseitiger Code auf serverlosen oder Edge-Funktionen

Code, der bei Bedarf laufen muss (API-Endpunkte, Datenbankabfragen, KI-Aufrufe), wird als serverlose Funktion deployt. Diese starten, wenn ein Nutzer eine Anfrage stellt, laufen ein paar hundert Millisekunden und verschwinden dann wieder. Du zahlst nur für die Ausführungszeit, nicht für ungenutzte Server. Edge-Funktionen sind eine Untergruppe, die an den Edge-Standorten des CDN läuft, für extrem niedrige Latenz.

Datenbank-Hosting

Datenbanken brauchen persistenten Speicher und passen nicht gut zu Serverless. Sie laufen typischerweise auf dedizierten Managed-Database-Diensten — Supabase Postgres, Neon, PlanetScale, MongoDB Atlas, AWS RDS. Dein AI-App-Builder stellt entweder automatisch eine bereit oder verbindet sich mit einer, die du angibst.

Phase 3: DNS — deine Domain an den richtigen Ort ausrichten

DNS (Domain Name System) ist der Mechanismus, durch den "deinemarke.de" zum "tatsächlichen Server, der deine App ausliefert" wird. Die DNS-Konfiguration sagt dem Internet, wo es deine App findet.

Die relevanten Records

• A-Record — Zeigt deine Root-Domain (deinemarke.de) auf eine IP-Adresse
• CNAME-Record — Zeigt eine Subdomain (app.deinemarke.de) auf eine andere Domain (cname.vercel-dns.com)
• MX-Record — Sagt dem Internet, welche Server E-Mails für deine Domain verarbeiten
• TXT-Record — Speichert beliebigen Text, genutzt für SPF-/DKIM-/DMARC-E-Mail-Authentifizierung und Domain-Verifizierung

DNS-Propagation: die häufigste Falle

Wenn du DNS-Records änderst, dauert es, bis sich die Änderung im gesamten Internet verbreitet — irgendwo zwischen 5 Minuten und 48 Stunden, abhängig von den Cache-Einstellungen. Während der Propagation sehen manche Nutzer die alte Version (oder gar keine), während andere schon die neue sehen. Das ist normal und kein Zeichen, dass etwas kaputt ist.

Tools wie whatsmydns.net lassen dich die Propagation über globale DNS-Server hinweg prüfen. Wenn deine Änderung nach 24 Stunden nicht propagiert ist, liegt meist ein TTL-Problem (Time-to-Live) oder ein falscher Record vor. Der AI-App-Builder gibt dir normalerweise die exakten Records, die du hinzufügen musst; sie exakt zu kopieren vermeidet die meisten Probleme.

Phase 4: SSL — das grüne Schloss bekommen

Moderne Browser warnen Nutzer vor Nicht-HTTPS-Seiten. SSL-Zertifikate (genau genommen TLS-Zertifikate) sorgen dafür, dass deine Seite über https:// statt http:// lädt. Ohne SSL zeigen Browser Warnungen an, Suchmaschinen bestrafen das Ranking, und Kunden vertrauen dir nicht.

Automatisches SSL über Let's Encrypt

Jeder größere AI-App-Builder stellt SSL-Zertifikate automatisch über Let's Encrypt aus — eine kostenlose, automatisierte Zertifizierungsstelle. Der Ablauf: Die Plattform beweist Let's Encrypt, dass du die Domain kontrollierst (per DNS- oder HTTP-Verifizierung), Let's Encrypt stellt ein Zertifikat aus, die Plattform installiert es. Zertifikate erneuern sich automatisch alle 90 Tage. Darum musst du dich meistens nicht kümmern.

Wenn SSL fehlschlägt

• DNS noch nicht propagiert — Die SSL-Ausstellung erfordert, dass die Domain auf die Server der Plattform aufgelöst wird
• Falscher DNS-Record-Typ — Ein A- statt CNAME-Konflikt bricht die Verifizierung
• DNS-Records zeigen woanders hin — Alte Records, die noch auf einen früheren Host zeigen
• CAA-Record blockiert Let's Encrypt — Manche Domains haben CAA-Records, die einschränken, welche Zertifizierungsstellen Zertifikate ausstellen dürfen

Die SSL-Ausstellung ist automatisch, aber nicht sofort. Nachdem sich das DNS korrekt auflöst, dauert SSL meist 5–60 Minuten.

Phase 5: Datenbank-Bereitstellung

Deine Vorschau-Datenbank (während der Entwicklung genutzt) ist getrennt von deiner Produktionsdatenbank (nach dem Launch genutzt). Produktionsdaten sind echte Kundendaten; du willst nicht, dass Entwicklungs-Experimente sie berühren.

Was während der Datenbank-Bereitstellung passiert

• Produktionsdatenbank wird erstellt — Meist bei einem Managed-Service (Supabase, Neon, MongoDB Atlas)
• Schema-Migration läuft — Tabellen, Spalten, Indizes und Beziehungen werden erstellt
• Row-Level-Security-Policies werden angewendet — Zugriffsregeln, die festlegen, wer was lesen/schreiben darf
• Seed-Daten werden geladen (optional) — Standardkategorien, Admin-Nutzer, Konfigurationsdaten
• Connection String wird generiert — Die URL, über die die App sich mit der Datenbank verbindet

Vorschau vs. Produktion: das Zwei-Datenbanken-Muster

Die meisten Plattformen halten Vorschau und Produktion als getrennte Datenbanken. Änderungen in der Vorschau wirken sich nicht auf die Produktion aus. Um Schemaänderungen von der Vorschau in die Produktion zu übernehmen, ist meist ein expliziter Schritt "Migrationen deployen" nötig. Das ist bewusste Sicherheit — ohne diesen Schritt würde ein Schemafehler in der Entwicklung echte Kundendaten beschädigen.

Phase 6: Umgebungsvariablen und Secrets

Deine App verbindet sich mit externen Diensten — Stripe, OpenAI, Resend, AWS — über API-Keys. Das sind sensible Secrets, die niemals im Quellcode auftauchen sollten. Umgebungsvariablen sind der Weg, wie Secrets in die laufende App gelangen, ohne in GitHub committet zu werden.

Wo Umgebungsvariablen liegen

• Vorschau-Umgebung — Test-Keys (Stripe-Testmodus, OpenAI-Dev-Key, Resend-Testdomain)
• Produktions-Umgebung — Live-Keys (Stripe-Livemodus, OpenAI-Prod-Key, Resend-Produktionsdomain)
• Build-Zeit vs. Laufzeit — Manche Umgebungsvariablen werden in den Build eingebacken; andere werden gelesen, wenn die App läuft

Warum Fehler bei Umgebungsvariablen häufig sind

• Test-Keys landen in Produktion — Stripe-Abbuchungen schlagen fehl, weil die Prod-App Test-Keys nutzt
• Produktions-Keys landen in der Vorschau — Echte Kundendaten werden während des Testens verschickt
• Fehlende Umgebungsvariablen beim Launch — Die App läuft, aber ein Kernfeature (Zahlungen, E-Mail) versagt lautlos
• Tippfehler in Namen von Umgebungsvariablen — STRIPE_SECRET_KEY vs. STRIPE_SECRETE_KEY bricht die Integration
• Vergessen, Keys nach einer Rotation zu aktualisieren — Alte Keys bleiben in der Plattform, nachdem du neue generiert hast

Die meisten Plattformen verwalten Umgebungsvariablen für Vorschau und Produktion getrennt. Die Disziplin: beide vor dem Launch prüfen und jeden Key rotieren, der in Screenshots sichtbar war oder in Chats geteilt wurde.

Was jeder große AI-App-Builder unterschiedlich macht

Die Plattformwahl beeinflusst die Flexibilität. Gebündeltes Hosting (Greta, Lovable) ist einfacher — ein Workflow, keine getrennten Konten. CDN-gekoppeltes Hosting (Bolt → Netlify/Cloudflare, v0 → Vercel) bietet mehr Flexibilität, erfordert aber Verständnis der Deployment-Ebene.

Nach dem Launch: die operative Ebene, die die meisten Gründer überspringen

Auf Launchen zu klicken ist der Anfang, nicht das Ende. Sechs operative Themen sind ab Tag eins wichtig.

Monitoring und Logs

• Fehler-Tracking — Sentry, Highlight oder in die Plattform integrierte Fehlerprotokolle fangen Exceptions ab, bevor Nutzer sich beschweren
• Performance-Monitoring — Ladezeiten von Seiten, API-Antwortzeiten, Datenbankabfragezeiten
• Real User Monitoring (RUM) — Wie echte Nutzer die App in unterschiedlichen Regionen erleben
• Server-Logs — Aufzeichnungen darüber, was das Backend wann getan hat (nützlich zum Debuggen)

Alerting

• Uptime-Monitoring — UptimeRobot, Better Uptime, Pingdom. Pingt deine App jede Minute an und alarmiert bei Ausfall.
• Fehlerraten-Alerts — Ein Anstieg der Fehler löst eine Benachrichtigung aus, bevor Nutzer es breit bemerken
• Kosten-Alerts — Budget-Alerts auf der Plattform und beim KI-API-Verbrauch verhindern ausufernde Rechnungen
• Datenbank-Alerts — Wenn die Free-Tier-Datenbank an ihre Grenzen kommt, löst das einen Alert aus

Backups

• Automatische Datenbank-Backups — Die meisten Managed Databases beinhalten tägliche automatische Backups
• Backup-Aufbewahrung — Wie lange Backups aufbewahrt werden (7 Tage, 30 Tage, länger bei bezahlten Tiers)
• Point-in-Time-Recovery — Wiederherstellung zu jedem beliebigen Moment der letzten N Tage, nicht nur zu täglichen Snapshots
• Backup außerhalb der Plattform — Für kritische Apps sorgen regelmäßige Exporte in deinen eigenen Speicher für zusätzliche Disaster Recovery

Rollback-Strategie

Jedes Deployment kann Bugs einführen. Zu wissen, wie man zurückrollt, ist operatives Überlebenswissen.

• Deployment-Historie — Die meisten Plattformen zeigen aktuelle Deployments mit Zeitstempeln und Änderungen
• 1-Klick-Rollback — Ein vorheriges Deployment zurück in Produktion befördern
• Rollback von Datenbank-Migrationen — Komplexer; nicht immer umkehrbar. Sei vorsichtig bei destruktiven Schemaänderungen.
• Kommunikationsplan — Sag Nutzern, wenn ein Rollback stattfindet; geh davon aus, dass manche Daten nicht durchgekommen sind

Status-Seite

• Öffentliche Status-Seite — status.deinemarke.de zeigt, ob Dienste laufen. Baut Vertrauen während Vorfällen auf.
• Vorlage für Incident-Kommunikation — Vorformulierte Vorlagen für gängige Vorfalltypen
• Abonnenten-Benachrichtigungen — Nutzer können Status-Updates per E-Mail/SMS abonnieren

BetterStack, Statuspage und Instatus bieten alle gehostete Status-Seiten mit vernünftigen kostenlosen Tiers an.

Incident Response

• On-Call-Rotation — Bei Solo-Betrieb: akzeptiere, dass du immer erreichbar bist; im Team: rotiert wöchentlich
• Schweregrad-Definitionen — SEV1 (jeder wird geweckt), SEV2 (innerhalb von Stunden bearbeiten), SEV3 (am nächsten Werktag bearbeiten)
• Post-Incident-Reviews — Nach der Behebung dokumentieren, was passiert ist und was sich geändert hat
• Kundenkommunikation — Kunden proaktiv per E-Mail informieren, wenn Vorfälle sie betreffen

Häufige Deployment-Probleme und wie man sie debuggt

• Domain löst nicht auf — Prüfe, ob DNS-Records exakt dem entsprechen, was die Plattform angefordert hat; prüfe die Propagation über whatsmydns.net
• SSL wird nicht ausgestellt — Meist ein DNS-Problem; stelle sicher, dass sich A-/CNAME-Records auflösen, bevor du SSL debuggst
• Build schlägt fehl — Lies die Build-Logs; die meisten Fehler sind überraschend verständlich, wenn du dir Zeit nimmst
• App live, aber Features kaputt — Fast immer ein Problem mit Umgebungsvariablen; prüfe, ob die Produktions-Env-Vars den von der App erwarteten Keys entsprechen
• Datenbank-Verbindungsfehler — Die Produktionsdatenbank hat die Migrationen möglicherweise nicht ausgeführt; prüfe die Schema-Version
• Langsame Seitenladezeiten — Oft fehlende CDN-Konfiguration oder große unoptimierte Bilder; prüfe den Performance-Monitor
• Sporadische Fehler — Oft werden Free-Tier-Limits erreicht (Datenbank, API, Funktionsausführung); Tier upgraden
• KI-Features scheitern in Produktion — Konflikt zwischen Testmodus- und Produktions-API-Key beim KI-Anbieter
• Stripe-Webhooks feuern nicht — Die Webhook-URL muss auf die Produktionsdomain zeigen, nicht auf die Vorschau; prüfe die Webhook-Konfiguration im Stripe Dashboard

Einrichtung einer eigenen Domain: die exakte Reihenfolge

Eine eigene Domain hinzuzufügen (deinemarke.de statt deineapp.greta.app) ist einer der wichtigsten Schritte nach dem Launch.

Schritt für Schritt

1. Domain kaufen — Namecheap, Cloudflare, Porkbun. Cloudflare fungiert gleichzeitig als DNS-Anbieter.
2. Domain im AI-App-Builder hinzufügen — Die Plattform zeigt dir die DNS-Records, die du hinzufügen musst
3. DNS-Records aktualisieren — Füge in den DNS-Einstellungen deines Domain-Registrars genau die von der Plattform geforderten Records hinzu
4. Auf Propagation warten — Meist 5–60 Minuten; in seltenen Fällen bis zu 48 Stunden
5. Auf SSL warten — Nachdem sich das DNS auflöst, wird SSL in 5–60 Minuten ausgestellt
6. Umgebungsvariablen aktualisieren — Manche Dienste (Stripe-Webhook-URL, OAuth-Callback-URLs) brauchen die neue Domain
7. Marketing aktualisieren — E-Mail-Signaturen, Social-Media-Bios, Visitenkarten auf die neue Domain umstellen
8. Weiterleitungen einrichten — Die alte Domain leitet auf die neue um; üblich sind www- und Apex-Weiterleitungen auf eine gewählte Hauptdomain

Für nicht-technische Gründer ist die korrekte Einrichtung der eigenen Domain oft die einschüchterndste einzelne Deployment-Aufgabe. Die meisten Plattformen führen sorgfältig hindurch; falls du feststeckst, übernimmt das Support-Team der Plattform das routinemäßig.

Häufig gestellte Fragen

F1: Warum dauert das Deployment manchmal 10 Minuten? Builds (Kompilieren und Bundling) können bei großen Projekten 2–5 Minuten dauern. Das Pushen zu globalen CDN-Standorten dauert weitere 1–2 Minuten. Datenbank-Migrationen können zusätzliche Zeit kosten. 10 Minuten Deployment ist normal für mittelgroße Projekte; schnellere Deployments nutzen inkrementelle Builds.

F2: Was ist der Unterschied zwischen Vorschau- und Produktions-Deployments? Vorschau ist die Staging-Umgebung, die bei jeder Änderung fürs Testen aktualisiert wird. Produktion ist die Live-Umgebung, die echte Nutzer sehen. Vorschau nutzt Test-API-Keys; Produktion nutzt Live-Keys. Die Vorschau-Datenbank ist von der Produktionsdatenbank getrennt.

F3: Muss ich DNS verstehen, um AI-App-Builder zu nutzen? Für die Standard-Subdomain in der Regel nicht. Für eigene Domains schon. Moderne AI-App-Builder machen das zugänglich, indem sie exakte Records zum Kopieren liefern, aber A- vs. CNAME-Records zu verstehen hilft bei der Fehlersuche.

F4: Was passiert, wenn ich ein Deployment lösche? Die meisten Plattformen bewahren die Deployment-Historie und erlauben für eine gewisse Zeit (oft 30–90 Tage) einen Rollback. Das aktuell aktive Deployment ist das, was Nutzer sehen. Das Löschen alter Deployments räumt die Historie auf, betrifft aber nicht die Live-App.

F5: Wie handhabe ich eine Datenbank-Migration in Produktion? Vorsichtig. Teste die Migration zuerst in der Vorschau. Sichere die Produktionsdatenbank vor dem Ausführen. Bei destruktiven Änderungen (Spalten löschen, Typen ändern) plane ein kurzes Wartungsfenster und kommuniziere es an die Nutzer.

F6: Was ist mit Uptime-SLAs? Die meisten AI-App-Builder-Plattformen bieten in bezahlten Tiers 99,9 % Uptime oder besser. Für die meisten Consumer-SaaS ist das in Ordnung. Für Enterprise-Produkte mit SLA-Zusagen prüfe, ob das SLA der Plattform dem entspricht, was du deinen Kunden zusagst.

F7: Kann ich meine App später auf ein anderes Hosting umziehen? Ja — die meisten AI-App-Builder exportieren echten Code, der überall laufen kann. Die Migrationskosten hängen von der Plattform ab: gebündelte Plattformen (Greta, Lovable) erfordern einen Neuaufbau der Deployment-Oberfläche; CDN-gekoppelte Plattformen (Bolt, v0) lassen sich meist leichter migrieren, weil die Hosting-Ebene stärker getrennt ist.

Fazit

• Wenn du auf Launchen klickst, passieren sechs Dinge: Build, Push zur Infrastruktur, DNS-Konfiguration, SSL-Ausstellung, Datenbank-Bereitstellung, Laden von Umgebungsvariablen. Jedes davon kann unabhängig fehlschlagen.
• Die häufigsten Fehlerquellen sind DNS-Propagation, falsch gesetzte Umgebungsvariablen und Build-Fehler. Für jede gibt es klare Debugging-Wege, sobald du weißt, wo du suchen musst.
• Operative Grundlagen nach dem Launch — Monitoring, Alerting, Backups, Rollback-Strategie, Status-Seite, Incident Response — trennen funktionierende Produkte von kaputten. Baue diese von Tag eins an auf.
• Die Einrichtung einer eigenen Domain ist die einschüchterndste Deployment-Aufgabe für Nicht-Entwickler, aber mit Geduld und exakt übernommenen DNS-Records gut zu bewältigen.

Wähl die Deployment-Ebene aus, die zu lernen du bisher vermieden hast — DNS, Umgebungsvariablen oder die Build-Pipeline. Verbring eine Stunde mit der Dokumentation der Plattform. Richte diese Woche Monitoring und Alerting ein. Konfiguriere nächste Woche die Status-Seite. Die operative Ebene, die funktionierende Produkte von kaputten trennt, wird meist einmal eingerichtet und dann gepflegt. Die Disziplin, diese Einrichtung durchzuziehen, unterscheidet Gründer, deren Apps laufen, von Gründern, deren Apps kaputtgehen — ohne dass sie wissen, warum.