KI-gebaute App exportieren und selbst hosten

Um eine KI-gebaute App selbst zu hosten, holst du den Code heraus (als Download oder über einen Sync mit einem GitHub-Repository, das dir gehört), legst die Geheimnisse als Umgebungsvariablen neu an, verschiebst oder erstellst die Datenbank neu und deployst die App auf einen Host, der zu ihr passt: ein statischer Host für ein reines Frontend oder eine Plattform, die Server oder Container ausführt, für alles mit Backend. Der Code ist meist der einfache Teil. Daten, Geheimnisse und die Dienste, die der Builder im Hintergrund für dich betrieben hat, sind der eigentliche Aufwand.

Warum überhaupt exportieren

Es gibt gute Gründe, deinen Code mitzunehmen, und einige weniger gute.

Gute Gründe:

• Eigentum und Absicherung. Eine Kopie des Codes in deinem eigenen Repository schützt dich, falls der Builder Preise, Funktionen oder Bedingungen ändert.
• Übergabe an Entwickler. Ein Engineering-Team will den Code in Git, in seinen gewohnten Tools und seinem Review-Prozess.
• Bestimmte Anforderungen. Datenstandort, ein bestimmter Cloud-Anbieter, Sicherheitsrichtlinien des Unternehmens oder eine Infrastruktur, die der Builder nicht bietet.
• Skalierung oder Kosten in einer Größenordnung, in der sich eigene Infrastruktur wirklich lohnt.

Weniger gute Gründe: eine kleine App mit einer Handvoll Nutzern zu verschieben, um einen kleinen Monatsbetrag zu sparen. Selbst-Hosting verlagert Arbeit zu dir – Updates, Backups, Monitoring, Sicherheitspatches. Das kann der richtige Tausch sein; triff ihn nur bewusst.

Ein vernünftiger Mittelweg: Bau und hoste weiter dort, wo du bist, aber synchronisiere früh mit einem eigenen GitHub-Repository. Du bekommst die Absicherung ohne den operativen Aufwand. Wenn Git für dich neu ist, lies was GitHub ist.

Was ein Export enthält und was nicht

Bevor du dich auf einen Export verlässt, öffne ihn und prüfe ihn. Typischerweise:

Geheimnisse bleiben absichtlich draußen – ein Archiv, das du per E-Mail verschickst oder committest, sollte niemals aktive Schlüssel enthalten. Abhängigkeiten bleiben draußen, weil sie aus der Lock-Datei neu aufgebaut werden.

Schritt 1: Den Code herausholen

Zwei gängige Wege:

• Archiv herunterladen vom Projekt. Schnell, passend für einen einmaligen Umzug oder ein Backup.
• Mit GitHub synchronisieren. Besser für alles Laufende: vollständige Historie, leicht überall klonbar, und die meisten Hosts deployen bei jedem Push direkt aus einem GitHub-Repository.

Wie auch immer du es machst: Klone oder entpacke es auf einem Rechner (oder in einer Cloud-Entwicklungsumgebung) und such nach einer README. Gibt es keine, bitte die KI im Builder, eine zu schreiben, bevor du gehst:

Schreibe eine README, damit dieses Projekt außerhalb dieser Plattform läuft: der Stack, die benötigten Laufzeitversionen, die Befehle zum Installieren und Bauen, der Startbefehl und der Port, jede Umgebungsvariable, die der Code liest (Namen und Zweck, keine Werte), und wie Datenbankmigrationen ausgeführt werden.

Dieser eine Prompt spart Stunden, weil er die implizite Einrichtung in Text zwingt.

Schritt 2: Zuerst lokal laufen lassen

Bevor du irgendwo deployst, beweise, dass die App für sich allein läuft:

1. Installiere die Laufzeit, die die README nennt – Node.js, Python, Java, .NET – in passender Version.
2. Installiere die Abhängigkeiten (npm install, pnpm install, pip install -r requirements.txt oder das Entsprechende).
3. Lege eine lokale .env-Datei mit den Umgebungsvariablen an, nach Möglichkeit mit Testschlüsseln. Halte sie aus Git heraus. Was Umgebungsvariablen und Geheimnisse sind erklärt die Idee.
4. Verbinde sie mit einer Datenbank – einem lokalen Postgres oder einer kostenlosen Entwicklungsdatenbank eines verwalteten Anbieters.
5. Führe die Migrationen aus, starte die App und klicke die wichtigsten Abläufe durch.

Was hier nicht läuft, läuft auch auf einem Host nicht, und lokal ist es viel einfacher zu debuggen. Typische Überraschungen: eine fest eingetragene URL der Builder-Vorschau, eine fehlende Umgebungsvariable, die der Builder automatisch gesetzt hat, oder ein Dienst (Dateispeicher, Bildskalierung), den es nur auf der Plattform gab.

Schritt 3: Die Daten umziehen

Wenn die App echte Nutzer hat, sind die Daten wichtiger als der Code.

• Datenbank exportieren. Bei Postgres erzeugt pg_dump eine Datei, die du mit pg_restore oder psql in die neue Datenbank einspielen kannst. Bitte die KI des Builders, es auszuführen, wenn du keinen direkten Zugriff hast, und zu erklären, was dabei entstanden ist.
• Hochgeladene Dateien verschieben. Wenn Nutzer Bilder oder Dokumente hochgeladen haben, liegen sie in einem Objektspeicher getrennt von der Datenbank. Kopiere sie in deinen neuen Speicher (etwa einen S3-kompatiblen Bucket) und aktualisiere die gespeicherten URLs, falls sie den alten Host enthalten.
• Die Umstellung planen. Bei einer Live-App ist der einfache Weg ein kurzes Wartungsfenster: Schreibzugriffe stoppen, einen letzten Export machen, auf dem neuen Host wiederherstellen, DNS umstellen, dann wieder öffnen. Schreib jeden Schritt vorher auf.
• Eine Wiederherstellung testen, zuerst in eine Test-Datenbank, bevor der echte Umzug passiert.

Falls dir Postgres fremd ist, erklärt was Postgres ist die Grundlagen.

Schritt 4: Den Host wählen

Passe den Host an das an, was die App ist. Die genannten Namen sind Beispiele bekannter Anbieter jeder Kategorie Stand September 2026, keine Rangliste; prüfe Funktionen und Preise auf deren Websites.

Du brauchst außerdem:

• Eine verwaltete Datenbank – viele App-Hosts bieten Postgres an, und spezialisierte Dienste wie Neon oder Supabase stellen es eigenständig bereit. Verwaltet lohnt sich: Backups und Updates übernimmt jemand anderes.
• Objektspeicher für Uploads, falls die App welche hat.
• E-Mail-Versand, Zahlungen und KI-Anbieter – diese brauchen meist nur dieselben API-Schlüssel auf dem neuen Host.

Fair bei den Abwägungen: Plattform-Hosts (die ersten vier Zeilen) sind schneller eingerichtet und gepflegt, aber du hast weniger Kontrolle, und die Kosten können mit dem Traffic steigen. Ein virtueller Server ist bei gleichbleibender Last oft günstiger und vollständig in deiner Hand, aber du übernimmst Patches, TLS, Backups, Monitoring und Wiederherstellung. Wenn niemand im Team diese Aufgabe will, wähle eine Plattform. Die Grundlagen von Hosting erklärt was Webhosting ist.

Schritt 5: Deployen und umstellen

1. Verbinde das Repository mit dem Host oder schiebe ein Container-Image hoch.
2. Setze die Umgebungsvariablen im Dashboard des Hosts – jede aus deiner README, mit echten Werten.
3. Lege Build- und Startbefehl sowie den Port fest. Viele Hosts übergeben den Port in einer Umgebungsvariable PORT; die App sollte darauf und auf allen Schnittstellen (0.0.0.0) lauschen, nicht nur auf localhost.
4. Führe die Migrationen auf der neuen Datenbank aus.
5. Teste unter der temporären URL des Hosts, bevor du das DNS anfasst.
6. Aktualisiere externe Dienste, die auf deine alte URL zeigen: Zahlungs-Webhooks, OAuth-Weiterleitungs-URLs für den Login, Links in E-Mails, erlaubte Ursprünge.
7. Verschiebe die Domain, indem du die DNS-Einträge auf den neuen Host setzt. Wie du eine eigene Domain verbindest erklärt die Einträge.
8. Lass das alte Deployment kurz weiterlaufen, bis du sicher bist, und nimm es dann vom Netz.

Schritt 6 wird am häufigsten vergessen: Logins und Zahlungen, die nach einem Umzug still scheitern, lassen sich meist auf eine Callback-URL zurückführen, die noch auf den alten Host zeigt.

Schritt 6: Den Betrieb übernehmen

Sobald du selbst hostest, werden die Aufgaben, die der Builder übernommen hat, deine. Mindestens: automatische Datenbank-Backups mit getesteter Wiederherstellung, Fehlererfassung, Uptime-Alarme, Abhängigkeits-Updates und eine Liste, wer Zugriff auf welche Konten hat. Wie du einen KI-Prototyp in den Produktivbetrieb bringst geht diese Liste ausführlicher durch.

Export-Checkliste

• Code in einem Repository, das dir gehört, mit einer README zu Ausführung, Build und Umgebungsvariablen
• App läuft lokal aus einem sauberen Klon
• Datenbank exportiert und Wiederherstellung getestet; hochgeladene Dateien kopiert
• Host passend zur Art der App gewählt, plus verwaltete Datenbank und Speicher
• Alle Umgebungsvariablen mit echten Werten auf dem neuen Host gesetzt
• Webhooks, OAuth-Weiterleitungen und E-Mail-Links aktualisiert
• DNS umgestellt, altes Deployment kurz behalten, dann entfernt
• Backups, Monitoring und Zugriffsliste eingerichtet

Export aus Mythex

In Mythex gehört dir der Code, den du baust. Im Pro-Tarif kannst du das Projekt unter Projekteinstellungen → Export als Archiv herunterladen oder GitHub verbinden und mit deinem eigenen Repository per Push und Pull arbeiten. Im Free-Tarif kannst du den Code nur schreibgeschützt ansehen, nicht exportieren oder synchronisieren. Geheimnisse und node_modules sind nicht im Export enthalten; lege deine Geheimnisse daher auf dem neuen Host neu an. Die Dokumentation beschreibt die Schritte unter Exportieren und anderswo betreiben und GitHub, Export und Import. Du kannst auch bei Mythex hosten und GitHub-Sync nur als eigene Kopie und Übergabeweg nutzen; wenn du umziehst, nimm die Mythex-App vom Netz, sobald der neue Host läuft.

Fragen