Um eine Web-App zu deployen, bauen Sie sie zu statischen Dateien, legen diese auf einem Host ab, der sie über HTTPS ausliefert, geben dem Host die Geheimnisse, die die App braucht, und lassen einen Domainnamen darauf zeigen. Mit einem KI-App-Baukasten können Sie beim ersten Schritt aufhören: Der Baukasten veröffentlicht die App für Sie. Möchten Sie einen anderen Host, exportieren Sie den Code nach GitHub und verbinden das Repository mit Vercel oder Netlify, oder Sie betreiben die App auf einem eigenen Server.
Diese Anleitung geht von einer App mit Supabase-Backend aus, wie sie Cadrant, unser Baukasten, erzeugt. Preise von Hosts Dritter nennen wir nicht: Sie ändern sich oft, prüfen Sie also die Seiten der Anbieter.
Die drei Wege, eine KI-App zu deployen
Es gibt drei Orte, an denen die App laufen kann: das eigene Hosting des Baukastens, ein Host wie Vercel oder Netlify oder ein Server, den Sie selbst verwalten. Sie unterscheiden sich vor allem darin, wie viel Sie selbst erledigen.
- Das Hosting des Baukastens. Sie klicken auf Veröffentlichen, und die App geht unter einer URL des Baukastens oder unter Ihrer eigenen Domain online. Außer der Domain ist nichts zu konfigurieren. Ihr Code bleibt in der Pipeline des Baukastens.
- Ein Host nach einem GitHub-Export. Sie pushen den Code in ein GitHub-Repository, verbinden das Repository mit einem Host, und der Host baut und deployt bei jedem Push. Sie kontrollieren die Build-Einstellungen und die Umgebungsvariablen.
- Ihr eigener Server. Sie mieten eine virtuelle Maschine, installieren einen Webserver, kopieren die gebauten Dateien und kümmern sich um Zertifikat und Updates. Das bietet die meiste Kontrolle und macht die meiste Arbeit.
| Option | So geht die App online | Was Sie selbst verwalten | Grenzen |
|---|---|---|---|
| Hosting des Baukastens (Cadrant) | Button Veröffentlichen, URL des Baukastens oder Ihre Domain | Die DNS-Einträge der Domain, das Supabase-Projekt | An den Baukasten gebunden: Wer wechselt, muss den Code exportieren, was bei Cadrant den Pro-Tarif voraussetzt |
| Vercel oder Netlify | Repository mit dem Host verbunden, Deploy bei jedem Push | Repository, Build-Einstellungen, Umgebungsvariablen, DNS, der Tarif des Hosts | Es gelten die Limits des Host-Tarifs, und der Code wird an zwei Orten bearbeitet, sofern der Baukasten nicht selbst nach GitHub pusht |
| Eigener Server | Sie kopieren die gebauten Dateien auf eine Maschine, die Sie betreiben | Alles: Server, Webserver, Zertifikatserneuerung, Sicherheitsupdates, Backups, Monitoring | Zeit. Lohnt sich bei Compliance oder besonderen Anforderungen, selten für einen ersten Launch |
Was Deployen konkret umfasst
Deployen besteht aus vier Dingen: einem Build, der Konfiguration, die die App zur Laufzeit braucht, einer Datenbank, die dort bleibt, wo sie ist, und einem HTTPS-Zertifikat. Das erste und das letzte erledigt jeder moderne Host automatisch.
Der Build
Eine React-App besteht aus Dateien, die ein Browser nicht direkt ausführen kann. Der Build-Schritt kompiliert sie zu einfachen HTML-, JavaScript- und CSS-Dateien, meist in einem Ordner namens dist oder build. Der Host führt den Build-Befehl aus (oft npm run build) und liefert diesen Ordner aus.
Umgebungsvariablen und Geheimnisse
Es gibt zwei Arten von Werten, und sie zu vermischen ist der häufigste Fehler beim Launch. Öffentliche Werte, etwa die URL des Supabase-Projekts und der öffentliche (anon) Schlüssel, stecken in der App und sind dafür gedacht, sichtbar zu sein. Geheime Werte wie ein geheimer Stripe-Schlüssel oder ein Schlüssel eines E-Mail-Anbieters dürfen weder im Code der App noch in einer Variable stehen, die der Build an den Browser weitergibt. Sie gehören auf die Serverseite.
In einer mit Cadrant gebauten App liegen Geheimnisse im Reiter Umgebung des Datenbank-Panels und werden von Supabase Edge Functions gelesen, sodass sie nie Teil des Frontend-Bundles sind. Siehe die Dokumentation zu Umgebungsvariablen. Wenn Sie anderswo deployen, lässt der Host Sie nur die öffentlichen Werte neu eintragen; die Geheimnisse bleiben in Supabase. Vercel weist darauf hin, dass jede seiner Umgebungen (Preview, Produktion) eigene Variablen haben kann. So halten Sie Testschlüssel von den Live-Schlüsseln fern.
Die Datenbank bleibt bei Supabase
Wenn Sie das Frontend zu einem anderen Host verlegen, ziehen die Daten nicht mit um. Datenbank, Nutzerkonten und Dateien bleiben im Supabase-Projekt, das in Ihrem eigenen Supabase-Konto liegt. Deshalb dauert ein Hostwechsel nur Minuten und nichts geht verloren. Nach jedem Adresswechsel sind zwei Dinge zu tun: die neue Domain in den Auth-Einstellungen eintragen und die Anmeldung testen. Laut Dokumentation von Supabase sollte die Site URL, die standardmäßig auf localhost steht, auf Ihre Produktions-URL geändert werden, und die Redirect-URLs bilden eine Allowlist, der die Weiterleitungen nach der Anmeldung entsprechen müssen. Bleibt das unverändert, zeigen Bestätigungs- und Passwort-Reset-Mails an die falsche Stelle. Die Details stehen in der Anleitung von Supabase zu Redirect-URLs.
Das HTTPS-Zertifikat
Browser warnen Nutzer vor Seiten ohne HTTPS, und die Anmeldung funktioniert ohne HTTPS nicht richtig. Vercel, Netlify und Cadrant stellen das Zertifikat aus und erneuern es, sobald die Domain verifiziert ist. Auf einem eigenen Server installieren und erneuern Sie es selbst, meist mit einem Tool einer kostenlosen Zertifizierungsstelle, und Sie müssen darauf achten, dass die Erneuerung weiterläuft.
So verbinden Sie eine eigene Domain
Eine Domain zu verbinden heißt, DNS-Einträge bei dem Unternehmen anzulegen, bei dem Sie die Domain verwalten, damit der Name auf Ihren Host zeigt. Jeder Host nennt Ihnen die genauen Einträge; übernehmen Sie diese exakt, statt sie aus einem Tutorial abzuschreiben.
- Registrieren Sie die Domain, falls Sie noch keine haben. Hilfe bei Name und Endung finden Sie in unserem Beitrag So wählen Sie die richtige Domain-Endung.
- Fügen Sie die Domain in den Einstellungen des Hosts hinzu. Der Host zeigt dann die anzulegenden Einträge.
- Legen Sie diese Einträge bei Ihrem DNS-Anbieter an (Ihrem Registrar, Cloudflare und so weiter).
- Warten Sie, bis der Host die Domain als verifiziert anzeigt, öffnen Sie dann die Seite unter der Domain und testen Sie die Anmeldung.
A-Record oder CNAME
Ein A-Record lässt einen Namen auf eine IP-Adresse zeigen, ein CNAME-Record auf einen anderen Namen. Laut Dokumentation von Vercel wird eine Apex-Domain wie example.com mit einem A-Record konfiguriert und eine Subdomain wie app.example.com mit einem CNAME-Record, und jedes Projekt hat seinen eigenen CNAME-Wert. Die Dokumentation von Netlify empfiehlt für die Apex-Domain einen ALIAS-Record, wenn Ihr DNS-Anbieter ihn unterstützt, sonst einen A-Record, dazu einen CNAME für www. Die Werte unterscheiden sich je nach Host und Projekt, verwenden Sie also die in Ihrem Dashboard angezeigten.
Apex-Domain oder www
Die Apex-Domain (oder Root-Domain) ist example.com, ohne etwas davor. Eine Subdomain ist alles, was davor steht, etwa www oder app. Im Standard-DNS kann ein CNAME nicht auf der Apex-Domain liegen, weshalb Apex-Setups A-, ALIAS- oder ANAME-Einträge nutzen. Netlify empfiehlt ausdrücklich, eine www-Subdomain zur primären Domain zu machen, weil eine primäre Apex-Domain bei manchen DNS-Anbietern die Performance beeinträchtigen kann. Die Dokumentation von Cadrant gibt denselben Rat: Bevorzugen Sie eine Subdomain wie app.meineseite.de, um die Einschränkungen von Root-Domains zu vermeiden. Tragen Sie beide Varianten ein und leiten Sie eine auf die andere um, damit Besucher die App auf beiden Wegen erreichen.
DNS-Propagierung
Eine DNS-Änderung kann von wenigen Minuten bis zu einem Tag oder länger brauchen, bis sie überall ankommt. Die Dokumentation von Netlify nennt bis zu 48 Stunden. Den Fortschritt prüfen Sie mit einem Tool wie dnschecker.org oder dem Befehl dig, und suchen Sie nach alten, widersprüchlichen Einträgen auf demselben Namen: Ein alter A- oder CNAME-Record ist die übliche Ursache einer Domain, die nie validiert wird.
So veröffentlicht Cadrant
Cadrant veröffentlicht über den Button Veröffentlichen: Sie wählen einen Slug für eine Cadrant-URL wie ihre-app.cadrant.app oder eine eigene Domain, die Sie im Bereich Domains hinzugefügt haben. HTTPS-Hosting und eine eigene Domain sind in jedem kostenpflichtigen Tarif enthalten, und eine veröffentlichte App verbraucht keine Credits.
Für eine eigene Domain zeigt Cadrant drei DNS-Einträge, die Sie bei Ihrem Registrar anlegen: einen TXT-Record, der den Besitz belegt, einen CNAME, der das Zertifikat validiert und seine automatische Erneuerung ermöglicht, und einen CNAME für das Routing. Bei einer Root-Domain braucht der Routing-Eintrag einen ALIAS oder ANAME, sofern Ihr Anbieter das unterstützt. Die Validierung dauert von wenigen Minuten bis zu einigen Stunden; ein Button Aktualisieren lädt den Status neu. Ein erneuter Klick auf Veröffentlichen ersetzt die Live-Version, und Sie können die Veröffentlichung jederzeit zurücknehmen. Die vollständigen Schritte stehen in der Dokumentation zum Veröffentlichen.
Die Grenze, die Sie kennen sollten: Das ist das Hosting des Baukastens. Möchten Sie Ihren eigenen Host, sind Code-Export und GitHub-Push im Pro-Tarif enthalten. Die Preise finden Sie auf der Preisseite, der Baukasten selbst ist auf der Seite KI-App-Baukasten beschrieben.
Auf einer Staging-Kopie testen, bevor Sie die Live-App ändern
Eine Staging-Kopie ist ein zweites Deployment der App mit eigener Adresse und eigenen Testdaten, auf dem Sie eine Änderung prüfen, bevor echte Nutzer sie sehen. Sobald Menschen auf Ihre App angewiesen sind, testen Sie zuerst dort.
Bei einem Host ist das eingebaut. Vercel erzeugt für jeden Branch oder Pull Request ein Preview-Deployment mit eigener URL und lässt Sie eine Staging-Domain und getrennte Umgebungsvariablen zuweisen. Laut Dokumentation verwenden Preview-Deployments Ihre Produktionsvariablen nicht, und ein Produktions-Build kann zudem zurückgehalten werden, bis Sie ihn freigeben. Netlify bietet ähnliche Deploy-Vorschauen. Sinn getrennter Variablen ist ein eigenes Supabase-Projekt für Staging, damit ein Test nie echte Kunden berührt.
In einem Baukasten ist die einfachste Staging-Kopie ein dupliziertes Projekt, das mit einem zweiten Supabase-Projekt verbunden und unter einer zweiten Subdomain wie staging.ihredomain.de veröffentlicht ist. Ändern und testen Sie dort und wiederholen Sie die Änderung dann im Live-Projekt. Das kostet einen Projektplatz, und die beiden Kopien können auseinanderlaufen, halten Sie die Liste der Änderungen also kurz. Spielen Sie Datenbankänderungen zuerst im Staging ein und prüfen Sie die Policies, wie in unserem Leitfaden zu Supabase Row Level Security erklärt.
So rollen Sie ein fehlerhaftes Deployment zurück
Zurückrollen heißt, die Live-App auf die letzte funktionierende Version zurückzusetzen, und das geht nur schnell, wenn die vorherige Version aufbewahrt wurde. Legen Sie fest, wie Sie vorgehen würden, bevor Sie es brauchen.
- In Cadrant. Jeder Prompt erzeugt eine neue Version, die unbegrenzt aufbewahrt wird. Sie können jede frühere Version in der Vorschau ansehen und darauf zurückgehen. Das Zurücksetzen löscht spätere Versionen nicht, Sie können also wieder vorwärts gehen. Klicken Sie nach dem Zurücksetzen auf Veröffentlichen, um diese Version online zu stellen. Das Zurücksetzen stellt die App wieder her, nicht die Daten, die in der Datenbank bereits geändert wurden. Siehe die Dokumentation zur Versionierung.
- Bei einem Host. Hosts bewahren frühere Deployments auf und können die Produktionsdomain einem älteren zuweisen, oder Sie machen den Commit in Git rückgängig und lassen den Host neu deployen.
- Auf dem eigenen Server. Bewahren Sie den vorherigen Build-Ordner neben dem aktuellen auf und schalten Sie darauf zurück.
Checkliste vor dem Launch
Bevor Sie jemandem sagen, dass die App live ist, prüfen Sie diese zehn Punkte. Die meisten Launch-Probleme stehen auf dieser Liste.
Zur Sicherheit im Detail lesen Sie unseren Leitfaden zur Sicherheit beim Vibe Coding. Um zu vergleichen, was die App leisten kann, bevor Sie sich für einen Baukasten entscheiden, beginnen Sie mit der Liste der KI-App-Baukästen.