Where your app is hosted: find repo, hosting, DB, domain

What “where your app lives” actually means

When someone asks where your app is hosted, they’re rarely asking one thing. They’re trying to trace the path from a user clicking a button to the systems that make your app work.

Most apps have four separate “homes.” Mixing them up is an easy way to lose hours:

• Code (repo): where the source code lives and gets edited (GitHub, GitLab, Bitbucket, or inside a tool like Replit).
• Hosting (runtime): where the live app runs when users visit it (Vercel, Netlify, Render, Fly.io, AWS, a VPS, etc.).
• Database: where the data lives (users, orders, content) like Postgres, MySQL, MongoDB, or a hosted database product.
• Domain and DNS: the settings that connect your domain name to hosting and other services (email records, verification records, and so on).

Helpers ask for these details first because many bugs are really “wrong place” problems. A login error might be code, or it might be missing environment variables in the hosting settings. “Data not saving” could be a code bug, or it could be the app pointing at the wrong database.

You can share a lot safely, and it speeds things up. It’s usually safe to share provider names, dashboard screenshots (with secrets hidden), error messages, and service names. Keep private anything that unlocks access: passwords, private keys, API tokens, database connection strings, and full environment variable values.

Knowing these locations turns debugging from guessing into checking. FixMyMess often sees AI-generated prototypes where the repo exists, but the deployed app is running a different branch, or secrets ended up exposed. Once the repo, deployment, and database are clearly identified, fixes get simpler and faster.

A simple note to capture the basics

If you can name all four locations below, support gets much faster because there’s no guessing about what to check first.

Copy and fill this in:

• Repo: provider + repo name + who can grant access
• Hosting: provider + project/app name + deploy method (auto from git, manual)
• Database: provider + database name + where credentials are stored
• Domain/DNS: registrar/DNS provider + domain + who can edit records
• Last known good: when it last worked and what changed

If an AI-built prototype suddenly breaks after “a small tweak,” this one note prevents the classic mistake of fixing the wrong environment.

Step by step: find your code repository

If you’re not sure where your app is hosted yet, start with the repo anyway. The repository is the best place to see what you actually have, what changed last, and what someone can realistically fix.

Go back to the AI builder or tool you used. Many tools (Lovable, Bolt, v0, Cursor, Replit) have a setting like GitHub, Repository, Export, or Sync that shows where code was pushed. If you see a connected account, note the org or username.

If you don’t remember where the code went:

• Open the tool you built in and look for any Git/Repository connection or export history.
• Search your email for repo invites and notifications like “deployment succeeded,” “build failed,” or GitHub notices.
• Check any GitHub, GitLab, or Bitbucket account you’ve used and look under Organizations and Repositories.

Once you find the repo, capture what people will ask for:

• Repo owner (person or organization)
• Repo name
• Who has access (and who can grant access)
• Default branch and last commit date

Sanity check: if the last commit is months old but your app changed recently, you may be looking at the wrong repo, or the tool never pushed the latest code.

Step by step: identify hosting and deployments

When someone asks “where your app is hosted,” they usually mean two things: where the live site runs, and how new code gets pushed there.

Start with the place you used to build the app. Many AI builders and starter templates have a Deploy page that shows a connected provider account (for example, Vercel or Netlify). If it says “connected to GitHub,” deployments are often automatic from a repo.

If you’re not sure which host it is, check your inbox and billing statements for names like Vercel, Netlify, Render, Fly.io, Railway, or cloud providers (AWS, GCP, Azure). If you find more than one, write down which one serves the public website vs background jobs or the database.

In the hosting dashboard for the right project, note:

• Project/app name as shown in the host
• Environment names (production, preview, staging) and which URL is production
• Last successful deployment time (and what commit/version)
• Where build and runtime logs live

Then confirm how deployments happen. Look for settings like “deploy on push” or “connected to main branch.” If it’s manual, note who can deploy and what they click.

Practical example: your homepage updates when you merge to main, but the API stays broken. That often means the frontend is on Vercel, while the backend runs elsewhere (Render, Fly.io, or a separate cloud project). Writing down both targets saves time.

If you bring this info to FixMyMess for a free code audit, we can go straight to the right logs and deployment pipeline instead of spending time just locating where things run.

Step by step: locate the database behind your app

If you can name the database provider and the exact project, debugging gets faster. Many “my app is broken” issues are really “the app can’t reach the database” or “it’s pointing at the wrong database.”

1) Start with the common managed databases

For AI tools and templates, the database is often a managed service. Look for Supabase, Neon, PlanetScale, Firebase, MongoDB Atlas, or AWS RDS in your tools list, invoices, or emails. If you have a hosting dashboard, check any “connected resources” section too.

2) Check hosting settings for database environment variables

In your hosting provider’s app settings, find Environment Variables or Secrets. You’re not trying to copy the secret value. You’re trying to identify the provider and the target database.

Common variable names:

• DATABASE_URL or DB_URL
• POSTGRES_URL or PGHOST
• MONGO_URL or MONGODB_URI
• SUPABASE_URL (often paired with keys)
• FIREBASE_PROJECT_ID

From the variable name and non-secret parts (like the hostname), you can usually tell the provider.

3) Scan the repo for database clues

In your repo, search for “supabase”, “prisma”, “mongoose”, “firebase”, “postgres”, “mysql”, or “mongodb”. Also check config files like .env.example, prisma/schema.prisma, firebase.json, or docker-compose.yml. These often reveal the database type even if the live secret is stored elsewhere.

4) Record the minimum details (no secrets)

Write down:

• Provider
• Project name or project ID
• Region (if shown)
• Database name
• Whether you have separate dev and prod databases

Example: if your host has DATABASE_URL and the hostname includes “neon.tech”, you can tell support “Neon Postgres, project X, region Y, separate prod and dev.” That’s usually enough to start diagnosing without exposing credentials.

Step by step: map auth and key integrations (often the blocker)

Auth is usually the first bottleneck. “Where is it hosted?” isn’t enough if nobody can tell which auth product is in charge, which domains are allowed, and where the secrets are set.

Start by identifying the auth provider and where it’s configured. Look in your repo for auth-related files (auth, middleware, providers), and in your hosting settings for environment variables. Common providers include Clerk, Auth0, Supabase Auth, Firebase Auth, or a custom login route.

Write down:

• Which provider you use (and the project/app name inside that provider)
• Which sign-in methods are enabled (email, Google, GitHub, etc.)
• Your production redirect URLs and allowed domains
• Where sessions are stored (cookies, JWT, or database)
• The exact error text (or a screenshot with secrets hidden)

Most “works locally, fails live” issues are small mismatches: redirect URLs still point to localhost, allowed domain lists don’t include the real domain, or cookie settings don’t match HTTPS.

Symptom map:

• Redirect loop after login: wrong redirect URL or cookie domain
• “Invalid redirect_uri”: allowed redirect URLs not updated for production
• “Unauthorized” only on live: missing env var/secret in hosting settings
• Login works but user is always logged out: session cookie blocked or wrong JWT secret

Example: Google sign-in works on a laptop, but the live site shows “Invalid redirect_uri.” The fix is often adding the production callback URL in the auth dashboard and updating the hosting environment variables.

Step by step: find domain and DNS settings

The domain is the front door. If DNS points to the wrong place (or no one has access), fixes that should take minutes can stall for days.

Start with the domain name (example: yourapp.com). Search your email for “domain renewal,” “registrar,” or the domain name itself. The company sending renewal receipts is often the registrar (GoDaddy, Namecheap, Cloudflare, and similar).

Next, confirm where DNS is actually managed. It’s sometimes different from the registrar. In the registrar dashboard, look for DNS, Nameservers, or DNS Management. If the nameservers mention another company (often Cloudflare), that other company is where edits happen.

Inside the DNS zone, the records people usually need to see are:

• A record: points the root domain to an IP address
• CNAME: often points www to another hostname
• TXT: used for domain verification, email settings, and some auth providers

Then confirm what the domain points to and whether SSL is active. Browser warnings, recent DNS changes, or conflicting records are common signs the domain doesn’t match the current hosting setup.

Example: a prototype “works on the preview link” but not on the real domain. The fix is often updating one CNAME or adding a TXT record, but only if you know which DNS provider controls it.

Before you ask for help, write down:

• Domain name(s) and whether you use www
• Registrar and DNS provider (if different)
• Who has login access to edit DNS
• Current key records (A, CNAME, TXT) and any recent changes

Quick checklist to gather before asking for help

Most delays happen because the code, hosting, database, and domain are owned by different accounts, and nobody knows who can approve access.

Keep this as a simple note you can paste into a support request. If you don’t know an item, write “unknown” rather than guessing.

• Repo (code): owner and repo name, main branch, last commit date/time you can see.
• Hosting: provider, project/app name, production URL, last successful deploy time.
• Database: provider, project name/ID, whether production and development are separated.
• Domain and DNS: registrar, where DNS is managed, and what the domain currently points to (A record IP or CNAME target).
• Access and ownership: who can grant permissions today and which emails own the accounts.

Example: login is broken, but the repo is in a contractor’s GitHub, the site is deployed from a different account, and DNS still points to an old preview URL. With the checklist above, a developer can request the right access and find the real production setup in minutes, not days.

Common mistakes that slow down support

When you’re not sure where your app is hosted, helpers spend the first hour finding basics instead of fixing the problem.

Common blockers:

• Assuming “it’s on GitHub” when the only thing that exists is a downloaded zip or a copy inside a builder tool. Without a real repo (history, branches, a clear main version), it’s hard to review changes or roll back safely.
• Mixing up preview URLs with the real production site. A preview link may work while the paid production domain points somewhere else.
• Not having access to the right accounts. You might have access to the AI builder, but not hosting, domain registrar, or database dashboards.

A few mistakes to avoid while you gather details:

• Don’t post screenshots that include API keys, database passwords, or private tokens. If something was exposed, rotate it.
• Don’t make “quick” DNS edits without writing down what changed. Propagation takes time, and it’s easy to lose track of what’s broken vs what’s still updating.
• Don’t rename projects, delete environments, or disconnect integrations “to clean things up” before someone looks. It can remove the clues needed to diagnose the issue.

Realistic example: turning a shaky AI prototype into a fixable project

A founder has a demo that looks great in screenshots. It was generated with an AI builder, and the landing page loads fine. But when real users try to log in, the live site throws errors and sends them back to the homepage.

They get unstuck by answering one question end to end: where the app lives. Not just the website, but the code, the deploy, the database, and the domain.

They search their inbox, find a GitHub repo they forgot existed, then check hosting and discover the project is on Vercel. Deployments are failing because required environment variables were never set in the hosting dashboard.

Once deploys are green, login still fails. They locate the database and realize it’s a Supabase project using an older table schema from an earlier prototype. A quick schema fix (or small migration) brings the auth flow back.

Finally, the domain is still pointing at an old target. They update DNS to the correct host and confirm SSL is valid, so browsers stop warning users.

What made the fix fast wasn’t luck. It was having these details ready:

• Repo location and access
• Hosting provider and latest deploy status
• Environment variable names (not secret values)
• Database provider and project name
• Domain registrar and where DNS is managed

Next steps: package the info and get the right help faster

Send one clear message that answers where your app is hosted and how it connects to everything else. The goal is to remove guesswork so the person helping you can start from facts.

Keep your “app inventory” short but complete:

• Repo: where the code lives + main branch name
• Hosting: provider + project/app name + how deploys happen (manual or auto)
• Database: provider + database name + where the app reads connection details (env vars)
• Domain/DNS: registrar + DNS host + where it points
• Auth/integrations: login provider + key third parties (payments, email, storage)

Access is usually the bottleneck, but sharing passwords is risky. Prefer invite-by-email access with the least permissions needed, and remove access after the work is done.

If your app was generated by tools like Lovable, Bolt, v0, Cursor, or Replit, a focused audit is often the fastest first step. AI-built prototypes frequently hide problems like exposed secrets, broken auth flows, or fragile database logic. FixMyMess (fixmymess.ai) is built for that specific situation: diagnosing the codebase and repairing what’s needed so the app can run reliably in production.