Wo deine App gehostet wird: Repo, Hosting, DB, Domain finden

Was „wo deine App lebt“ eigentlich bedeutet

Wenn jemand fragt, wo deine App gehostet ist, meint er selten nur eine Sache. Es geht darum, den Weg nachzuzeichnen — vom Klick eines Nutzers bis zu den Systemen, die deine App am Laufen halten.

Die meisten Apps haben vier getrennte „Heime“. Sie zu verwechseln kostet leicht Stunden:

• Code (Repo): wo der Quellcode liegt und bearbeitet wird (GitHub, GitLab, Bitbucket oder in einem Tool wie Replit).
• Hosting (Runtime): wo die live App läuft, wenn Nutzer sie besuchen (Vercel, Netlify, Render, Fly.io, AWS, ein VPS, etc.).
• Datenbank: wo die Daten liegen (User, Bestellungen, Inhalte) wie Postgres, MySQL, MongoDB oder ein gehostetes Datenbankprodukt.
• Domain und DNS: die Einstellungen, die deinen Domainnamen mit Hosting und anderen Diensten verbinden (E-Mail-Records, Verifizierungs-Records usw.).

Helfer*innen fragen zuerst nach diesen Details, weil viele Bugs eigentlich „am falschen Ort“ liegen. Ein Loginfehler kann Code sein — oder fehlende Environment-Variablen in den Hosting-Einstellungen. „Daten werden nicht gespeichert“ kann ein Bug im Code sein — oder die App zeigt auf die falsche Datenbank.

Du kannst viel sicher teilen, und das beschleunigt die Arbeit. In der Regel ist es sicher, Anbieternamen, Dashboard-Screenshots (mit ausgeblendeten Secrets), Fehlermeldungen und Servicenamen zu teilen. Vertrauliche Dinge, die Zugang erlauben, musst du schützen: Passwörter, private Keys, API-Tokens, Datenbank-Verbindungsstrings und vollständige Environment-Variablen gehören nicht in Screenshots oder Chats.

Wenn diese Orte bekannt sind, wird Debuggen vom Raten zum Checken. FixMyMess sieht oft AI-generierte Prototypen, bei denen das Repo existiert, aber die deployte App von einem anderen Branch läuft oder Secrets falsch platziert wurden. Sind Repo, Deployment und Datenbank klar, werden Fixes einfacher und schneller.

Kurze Notiz, um die Basics festzuhalten

Wenn du alle vier Orte unten benennen kannst, geht Support viel schneller, weil niemand raten muss, was zuerst geprüft werden soll.

Kopiere und fülle das hier aus:

• Repo: Provider + Repo-Name + wer Zugriff gewähren kann
• Hosting: Provider + Projekt/App-Name + Deploy-Methode (auto von git, manuell)
• Datenbank: Provider + Datenbankname + wo die Zugangsdaten gespeichert sind
• Domain/DNS: Registrar/DNS-Provider + Domain + wer Records bearbeiten kann
• Zuletzt funktionierend: wann es zuletzt lief und was sich geändert hat

Wenn ein AI-built Prototyp nach „einer kleinen Änderung“ plötzlich kaputtgeht, verhindert diese eine Notiz den klassischen Fehler, die falsche Umgebung zu reparieren.

Schritt für Schritt: finde dein Code-Repository

Wenn du noch nicht sicher bist, wo deine App gehostet ist, fang trotzdem beim Repo an. Das Repository zeigt am besten, was du tatsächlich hast, was sich zuletzt geändert hat und was man realistisch reparieren kann.

Geh zurück zu dem AI-Builder oder Tool, das du verwendet hast. Viele Tools (Lovable, Bolt, v0, Cursor, Replit) haben eine Einstellung wie GitHub, Repository, Export oder Sync, die zeigt, wohin Code gepusht wurde. Siehst du ein verbundenes Konto, notiere die Organization oder den Benutzernamen.

Wenn du nicht mehr weißt, wohin der Code ging:

• Öffne das Tool, in dem du gebaut hast, und suche nach Git-/Repository-Verknüpfungen oder einer Export-Historie.
• Durchsuche dein E-Mail-Postfach nach Repo-Einladungen und Benachrichtigungen wie „deployment succeeded“, „build failed“ oder GitHub-Notices.
• Prüfe alle GitHub-, GitLab- oder Bitbucket-Konten, die du genutzt hast, und schaue unter Organizations und Repositories.

Wenn du das Repo gefunden hast, halte fest, was Leute fragen werden:

• Repo-Owner (Person oder Organisation)
• Repo-Name
• Wer hat Zugriff (und wer kann Zugriff gewähren)
• Default-Branch und Datum des letzten Commits

Sanity-Check: Wenn der letzte Commit Monate alt ist, die App sich aber kürzlich verändert hat, schaust du eventuell das falsche Repo an oder das Tool hat den aktuellen Code nie gepusht.

Schritt für Schritt: Hosting und Deployments identifizieren

Wenn jemand fragt „wo ist deine App gehostet“, meinen sie meist zwei Dinge: wo die Live-Seite läuft und wie neuer Code dorthin kommt.

Beginne mit dem Ort, an dem du die App gebaut hast. Viele AI-Builder und Starter-Templates haben eine Deploy-Seite, die ein verbundenes Provider-Konto zeigt (zum Beispiel Vercel oder Netlify). Wenn dort „connected to GitHub“ steht, sind Deploys oft automatisch vom Repo.

Wenn du nicht sicher bist, welcher Host es ist, checke dein Postfach und Rechnungen nach Namen wie Vercel, Netlify, Render, Fly.io, Railway oder Cloud-Providern (AWS, GCP, Azure). Findest du mehrere, schreibe auf, welcher den öffentlichen Webauftritt bedient und welcher Background-Jobs oder die Datenbank betreut.

Im Hosting-Dashboard des richtigen Projekts notiere:

• Projekt/App-Name wie im Host angezeigt
• Umgebungsnamen (production, preview, staging) und welche URL Produktion ist
• Zeitpunkt des letzten erfolgreichen Deploys (und welcher Commit/Version)
• Wo Build- und Runtime-Logs liegen

Bestätige dann, wie Deploys passieren. Suche nach Einstellungen wie „deploy on push“ oder „connected to main branch“. Ist es manuell, notiere, wer deployen kann und was geklickt wird.

Praktisches Beispiel: Deine Homepage aktualisiert sich, wenn du in main mergest, aber die API bleibt fehlerhaft. Das bedeutet oft, dass das Frontend auf Vercel liegt, während das Backend woanders läuft (Render, Fly.io oder ein separates Cloud-Projekt). Beide Ziele aufzuschreiben spart Zeit.

Bringst du diese Infos zu FixMyMess für ein kostenloses Code-Audit, können wir direkt in die richtigen Logs und die Pipeline schauen statt Zeit mit der Suche zu verlieren.

Schritt für Schritt: finde die Datenbank hinter deiner App

Wenn du Anbieter und Projekt der Datenbank benennen kannst, beschleunigt das Debugging stark. Viele Probleme sind eigentlich „die App erreicht die Datenbank nicht“ oder „zeigt auf die falsche Datenbank“.

1) Fang bei den üblichen Managed-Datenbanken an

Bei AI-Tools und Templates ist die Datenbank oft ein Managed-Service. Suche nach Supabase, Neon, PlanetScale, Firebase, MongoDB Atlas oder AWS RDS in deinen Tools, Rechnungen oder E-Mails. Im Hosting-Dashboard gibt es oft auch einen Bereich „connected resources“.

2) Schau in die Hosting-Einstellungen nach Environment-Variablen

Im Hosting-Provider findest du oft eine Sektion Environment Variables oder Secrets. Du sollst nicht den geheimen Wert kopieren, sondern den Anbieter und die Ziel-Datenbank identifizieren.

Gängige Variablennamen:

• DATABASE_URL oder DB_URL
• POSTGRES_URL oder PGHOST
• MONGO_URL oder MONGODB_URI
• SUPABASE_URL (oft kombiniert mit Keys)
• FIREBASE_PROJECT_ID

Anhand des Variablennamens und nicht-geheimer Teile (z. B. Hostname) erkennt man meist den Provider.

3) Scanne das Repo nach Datenbank-Hinweisen

Durchsuche dein Repo nach „supabase“, „prisma“, „mongoose“, „firebase“, „postgres“, „mysql“ oder „mongodb“. Schau auch in Konfigurationsdateien wie .env.example, prisma/schema.prisma, firebase.json oder docker-compose.yml. Dort sieht man oft den Datenbanktyp, auch wenn das Live-Secret woanders liegt.

4) Notiere die Mindestdetails (ohne Secrets)

Schreib auf:

• Provider
• Projektname oder Projekt-ID
• Region (falls angezeigt)
• Datenbankname
• Ob dev und prod getrennt sind

Beispiel: Wenn dein Host DATABASE_URL hat und der Hostname „neon.tech“ enthält, kannst du Support mitteilen: „Neon Postgres, Projekt X, Region Y, separat prod und dev.“ Das reicht meist, um ohne Credentials zu starten.

Schritt für Schritt: Auth und Key-Integrationen abbilden (oft der Blocker)

Auth ist oft der erste Engpass. „Wo ist es gehostet?“ reicht nicht, wenn niemand sagen kann, welches Auth-Produkt zuständig ist, welche Domains erlaubt sind und wo die Secrets gesetzt sind.

Fang an, den Auth-Provider und dessen Konfiguration zu identifizieren. Suche im Repo nach auth-bezogenen Dateien (auth, middleware, providers) und in den Hosting-Einstellungen nach Environment-Variablen. Häufige Anbieter sind Clerk, Auth0, Supabase Auth, Firebase Auth oder eine eigene Login-Route.

Schreibe auf:

• Welcher Provider genutzt wird (und Projekt-/App-Name im Provider)
• Welche Anmeldemethoden aktiviert sind (E-Mail, Google, GitHub, etc.)
• Produktions-Redirect-URLs und erlaubte Domains
• Wo Sessions gespeichert werden (Cookies, JWT oder Datenbank)
• Den genauen Fehlertext (oder einen Screenshot mit ausgeblendeten Secrets)

Die meisten „lokal ok, live kaputt“-Probleme sind kleine Abweichungen: Redirect-URLs zeigen noch auf localhost, erlaubte Domains listen die Produktionsdomain nicht, oder Cookie-Settings passen nicht zu HTTPS.

Symptom-Übersicht:

• Redirect-Loop nach Login: falsche Redirect-URL oder Cookie-Domain
• „Invalid redirect_uri": erlaubte Redirect-URLs nicht für Produktion aktualisiert
• „Unauthorized“ nur live: fehlende Env-Var/Secret in Hosting-Einstellungen
• Login funktioniert, aber Nutzer sind immer ausgeloggt: Session-Cookie blockiert oder falsches JWT-Secret

Beispiel: Google-Sign-In funktioniert lokal, live kommt „Invalid redirect_uri“. Die Lösung ist oft, die Produktions-Callback-URL im Auth-Dashboard hinzuzufügen und die Hosting-Env-Variablen zu prüfen.

Schritt für Schritt: Domain- und DNS-Einstellungen finden

Die Domain ist die Haustür. Wenn DNS auf den falschen Ort zeigt (oder niemand Zugriff hat), können eigentlich einfache Fixes Tage dauern.

Beginne mit dem Domainnamen (z. B. yourapp.com). Durchsuche dein Postfach nach „domain renewal“, „registrar“ oder dem Domainnamen selbst. Die Firma, die dir Verlängerungs-E-Mails schickt, ist oft der Registrar (GoDaddy, Namecheap, Cloudflare usw.).

Bestätige als Nächstes, wo DNS tatsächlich verwaltet wird. Das kann anders sein als der Registrar. Im Registrar-Dashboard schaue nach DNS, Nameservers oder DNS-Management. Wenn die Nameserver eine andere Firma nennen (häufig Cloudflare), ist dort die Bearbeitung nötig.

In der DNS-Zone sind die Records, die Helfer*innen sehen wollen:

• A-Record: zeigt die Root-Domain auf eine IP-Adresse
• CNAME: zeigt www oft auf einen anderen Hostnamen
• TXT: verwendet für Domain-Verifizierung, E-Mail-Settings und einige Auth-Provider

Prüfe außerdem, wohin die Domain zeigt und ob SSL aktiv ist. Browser-Warnungen, kürzliche DNS-Änderungen oder widersprüchliche Records sind Hinweise darauf, dass die Domain nicht zum aktuellen Hosting-Setup passt.

Beispiel: Ein Prototyp „funktioniert auf dem Preview-Link“, aber nicht auf der echten Domain. Die Lösung ist oft das Aktualisieren eines CNAMEs oder das Hinzufügen eines TXT-Records — vorausgesetzt, du weißt, welcher DNS-Provider die Zone kontrolliert.

Bevor du um Hilfe bittest, notiere:

• Domainname(n) und ob du www nutzt
• Registrar und DNS-Provider (falls unterschiedlich)
• Wer Zugriff hat, DNS zu bearbeiten
• Aktuelle Schlüssel-Records (A, CNAME, TXT) und kürzliche Änderungen

Schnelle Checkliste vor der Hilfe-Anfrage

Die meisten Verzögerungen entstehen, weil Code, Hosting, Datenbank und Domain in verschiedenen Accounts liegen und niemand weiß, wer Zugriff gewähren kann.

Behalte das als kurze Notiz, die du in eine Support-Anfrage kopieren kannst. Wenn du etwas nicht weißt, schreibe „unknown“ statt zu raten.

• Repo (Code): Owner und Repo-Name, main-Branch, letztes sichtbares Commit-Datum/Zeit
• Hosting: Provider, Projekt/App-Name, Produktions-URL, Zeitpunkt des letzten erfolgreichen Deploys
• Datenbank: Provider, Projektname/ID, ob Produktion und Entwicklung getrennt sind
• Domain und DNS: Registrar, wo DNS verwaltet wird und worauf die Domain aktuell zeigt (A-IP oder CNAME-Ziel)
• Zugriff & Besitz: wer heute Berechtigungen geben kann und welche E-Mail-Adressen die Konten besitzen

Beispiel: Login ist kaputt, das Repo liegt aber bei einem Auftragnehmer in dessen GitHub, die Seite wird aus einem anderen Account deployed und DNS zeigt noch auf eine alte Preview-URL. Mit der Checkliste kann ein Entwickler den richtigen Zugriff anfordern und die echte Produktions-Konfiguration in Minuten statt Tagen finden.

Häufige Fehler, die Support verlangsamen

Wenn du nicht sicher bist, wo deine App gehostet ist, verbringt die helfende Person die erste Stunde damit, die Basics zu finden, statt das Problem zu lösen.

Häufige Blocker:

• „Es ist auf GitHub“ annehmen, obwohl nur ein heruntergeladenes Zip oder eine Kopie im Builder existiert. Ohne echtes Repo (History, Branches, klarer main) ist Review oder Rollback schwer.
• Preview-URLs mit echter Produktion verwechseln. Eine Preview kann funktionieren, während die bezahlte Produktionsdomain woanders hinzeigt.
• Kein Zugriff auf die richtigen Konten. Du hast vielleicht Zugang zum AI-Builder, aber nicht zum Hosting-, Domain-Registrar- oder Datenbank-Dashboard.

Einige Fehler, die du beim Sammeln vermeiden solltest:

• Poste keine Screenshots mit API-Keys, DB-Passwörtern oder privaten Tokens. Falls etwas exponiert wurde, rotiere es.
• Mache keine „schnellen“ DNS-Änderungen ohne Dokumentation dessen, was du geändert hast. Propagation braucht Zeit und es ist leicht, den Überblick zu verlieren.
• Lösche oder benenne Projekte nicht um, entferne keine Umgebungen und trenne keine Integrationen „zur Aufräumung“, bevor jemand nachsehen konnte. Du nimmst sonst Hinweise weg, die zur Diagnose nötig sind.

Realistisches Beispiel: aus einem wackeligen AI-Prototyp ein reparierbares Projekt machen

Eine Gründerin hat einen Demo, das in Screenshots großartig aussieht. Es wurde mit einem AI-Builder generiert, und die Landing-Page lädt. Sobald echte Nutzer sich einloggen wollen, wirft die Live-Seite Fehler und leitet zurück zur Startseite.

Sie kommt wieder in Gang, indem sie eine einzige Frage Ende-zu-Ende beantwortet: wo lebt die App. Nicht nur die Website, sondern Code, Deploy, Datenbank und Domain.

Sie durchsucht ihr Postfach, findet ein vergessenes GitHub-Repo, prüft Hosting und entdeckt das Projekt auf Vercel. Deploys schlagen fehl, weil notwendige Environment-Variablen nie im Hosting-Dashboard gesetzt wurden.

Sind die Deploys erfolgreich, funktioniert der Login noch nicht. Sie findet die Datenbank: ein Supabase-Projekt mit einem älteren Tabellen-Schema aus einem früheren Prototyp. Eine kleine Schema-Anpassung (oder Migration) stellt den Auth-Fluss wieder her.

Zuletzt zeigt die Domain noch auf ein altes Ziel. Nach dem DNS-Update auf den richtigen Host und der Bestätigung, dass SSL gültig ist, verschwinden die Browser-Warnungen.

Was den Fix schnell machte, war nicht Glück, sondern diese Details:

• Repo-Standort und Zugriffsrechte
• Hosting-Provider und letzter Deploy-Status
• Namen der Environment-Variablen (nicht die geheimen Werte)
• Datenbank-Provider und Projektname
• Domain-Registrar und wo DNS verwaltet wird

Nächste Schritte: pack die Informationen zusammen und bekomme schneller Hilfe

Sende eine klare Nachricht, die beantwortet, wo deine App gehostet ist und wie alles verbunden ist. Das Ziel ist, das Rätselraten zu eliminieren, damit die helfende Person von Fakten ausgehen und sofort loslegen kann.

Halte dein „App-Inventar“ kurz, aber vollständig:

• Repo: wo der Code liegt + Name des main-Branches
• Hosting: Provider + Projekt/App-Name + wie Deploys passieren (manuell oder automatisch)
• Datenbank: Provider + Datenbankname + wo die App Verbindungsinformationen liest (Env-Variablen)
• Domain/DNS: Registrar + DNS-Host + wohin sie zeigt
• Auth/Integrationen: Login-Provider + wichtige Drittanbieter (Payments, E-Mail, Storage)

Zugriff ist meist der Engpass, aber Passwörter zu teilen ist riskant. Bevorzuge Einladung per E-Mail mit minimal nötigen Rechten und entferne den Zugriff nach Abschluss der Arbeit.

Wenn deine App von Tools wie Lovable, Bolt, v0, Cursor oder Replit erzeugt wurde, ist ein fokussiertes Audit oft der schnellste erste Schritt. AI-generierte Prototypen verbergen häufig Probleme wie exponierte Secrets, kaputte Auth-Flows oder fragile Datenbank-Logik. FixMyMess (fixmymess.ai) ist für genau diese Situationen gebaut: wir diagnostizieren die Codebasis und reparieren, was nötig ist, damit die App zuverlässig in Produktion läuft.