Dónde se aloja tu app: encuentra repo, hosting, BD y dominio

Qué significa realmente “dónde vive tu app”

Cuando alguien pregunta dónde está alojada tu app, rara vez se refiere a una sola cosa. Están tratando de trazar el camino desde que un usuario hace clic en un botón hasta los sistemas que hacen que tu app funcione.

La mayoría de las apps tienen cuatro “hogares” separados. Confundirlos es una forma fácil de perder horas:

• Código (repo): donde vive y se edita el código fuente (GitHub, GitLab, Bitbucket, o dentro de una herramienta como Replit).
• Hosting (runtime): donde se ejecuta la app en vivo cuando los usuarios la visitan (Vercel, Netlify, Render, Fly.io, AWS, un VPS, etc.).
• Base de datos: donde vive la información (usuarios, pedidos, contenido) como Postgres, MySQL, MongoDB o un producto de base de datos gestionado.
• Dominio y DNS: la configuración que conecta tu nombre de dominio con el hosting y otros servicios (registros de email, verificación y demás).

Quienes ayudan piden estos detalles primero porque muchos errores son realmente problemas de “lugar equivocado”. Un error de login puede ser código, o puede ser variables de entorno faltantes en la configuración del hosting. “Los datos no se guardan” podría ser un bug en el código o que la app apunte a la base de datos equivocada.

Puedes compartir mucho de forma segura, y eso acelera las cosas. Suele ser seguro compartir nombres de proveedores, capturas del panel (con secretos ocultos), mensajes de error y nombres de servicios. Mantén privados todo lo que permita el acceso: contraseñas, claves privadas, tokens de API, cadenas de conexión de bases de datos y valores completos de variables de entorno.

Saber estas ubicaciones convierte la depuración de adivinar a comprobar. En FixMyMess a menudo vemos prototipos generados por IA donde el repo existe, pero la app desplegada está corriendo otra rama, o los secretos quedaron expuestos. Una vez identificados claramente el repo, el despliegue y la base de datos, las correcciones son más simples y rápidas.

Una nota simple para capturar lo básico

Si puedes nombrar las cuatro ubicaciones de abajo, el soporte será mucho más rápido porque no habrá que adivinar qué comprobar primero.

Copia y completa esto:

• Repo: proveedor + nombre del repo + quién puede dar acceso
• Hosting: proveedor + nombre del proyecto/app + método de despliegue (auto desde git, manual)
• Base de datos: proveedor + nombre de la base + dónde se almacenan las credenciales
• Dominio/DNS: registrador/proveedor de DNS + dominio + quién puede editar los registros
• Último estado bueno conocido: cuándo funcionó por última vez y qué cambió

Si un prototipo construido por IA se rompe tras “un pequeño ajuste”, esta nota evita el error clásico de arreglar el entorno equivocado.

Paso a paso: encuentra tu repositorio de código

Si no sabes aún dónde está alojada tu app, empieza por el repo. El repositorio es el mejor lugar para ver qué tienes realmente, qué cambió último y qué puede arreglar alguien razonablemente.

Vuelve a la herramienta o builder que usaste. Muchas herramientas (Lovable, Bolt, v0, Cursor, Replit) tienen un ajuste como GitHub, Repository, Export o Sync que muestra dónde se empujó el código. Si ves una cuenta conectada, anota la organización o el usuario.

Si no recuerdas dónde fue el código:

• Abre la herramienta en la que la construiste y busca cualquier conexión Git/Repository o historial de exportaciones.
• Busca en tu correo invitaciones a repos y notificaciones como “deployment succeeded”, “build failed” o avisos de GitHub.
• Revisa cualquier cuenta de GitHub, GitLab o Bitbucket que hayas usado y mira en Organizaciones y Repositorios.

Una vez encuentres el repo, captura lo que la gente preguntará:

• Propietario del repo (persona u organización)
• Nombre del repo
• Quién tiene acceso (y quién puede conceder acceso)
• Rama por defecto y fecha del último commit

Chequeo de sentido común: si el último commit tiene meses pero tu app cambió recientemente, puede que estés viendo el repo equivocado o que la herramienta no haya empujado el código más reciente.

Paso a paso: identifica hosting y despliegues

Cuando alguien pregunta “dónde está alojada tu app”, normalmente se refieren a dos cosas: dónde corre el sitio en vivo y cómo se empuja nuevo código allí.

Empieza por el lugar donde la construiste. Muchos builders y templates tienen una página Deploy que muestra una cuenta de proveedor conectada (por ejemplo Vercel o Netlify). Si indica “conectado a GitHub”, los despliegues suelen ser automáticos desde un repo.

Si no estás seguro de qué host es, revisa tu correo y tus facturas buscando nombres como Vercel, Netlify, Render, Fly.io, Railway o proveedores cloud (AWS, GCP, Azure). Si encuentras más de uno, anota cuál sirve el sitio público y cuál se encarga de jobs en segundo plano o la base de datos.

En el panel del hosting para el proyecto correcto, anota:

• Nombre del proyecto/app tal como aparece en el host
• Nombres de entornos (production, preview, staging) y cuál URL es producción
• Último despliegue exitoso (y qué commit/versión fue)
• Dónde están los logs de build y runtime

Luego confirma cómo ocurren los despliegues. Busca ajustes como “deploy on push” o “connected to main branch”. Si es manual, anota quién puede desplegar y qué pasos hace.

Ejemplo práctico: tu página principal se actualiza cuando haces merge a main, pero la API sigue rota. Eso suele significar que el frontend está en Vercel y el backend corre en otro lugar (Render, Fly.io o un proyecto cloud separado). Anotar ambos destinos ahorra tiempo.

Si traes esta información a FixMyMess para una auditoría gratuita, podemos ir directamente a los logs y a la pipeline correcta en vez de perder tiempo localizando dónde corren las cosas.

Paso a paso: localiza la base de datos detrás de tu app

Si puedes nombrar el proveedor de la base de datos y el proyecto exacto, la depuración será más rápida. Muchos problemas de “mi app está rota” son realmente “la app no alcanza la base de datos” o “apunta a la base equivocada”.

1. Empieza por las bases administradas comunes

Para herramientas y templates de IA, la base suele ser un servicio gestionado. Busca Supabase, Neon, PlanetScale, Firebase, MongoDB Atlas o AWS RDS en la lista de herramientas, facturas o correos. Si tienes un panel de hosting, revisa la sección “recursos conectados”.

2. Revisa la configuración de hosting para variables de entorno de la base

En la configuración del hosting, busca Environment Variables o Secrets. No se trata de copiar el valor secreto, sino de identificar el proveedor y la base objetivo.

Nombres de variables comunes:

• DATABASE_URL o DB_URL
• POSTGRES_URL o PGHOST
• MONGO_URL o MONGODB_URI
• SUPABASE_URL (a menudo va con keys)
• FIREBASE_PROJECT_ID

Por el nombre de la variable y las partes no secretas (como el hostname) normalmente puedes deducir el proveedor.

3. Escanea el repo en busca de pistas de base de datos

En tu repo, busca “supabase”, “prisma”, “mongoose”, “firebase”, “postgres”, “mysql” o “mongodb”. También revisa archivos de configuración como .env.example, prisma/schema.prisma, firebase.json o docker-compose.yml. Suelen revelar el tipo de base de datos aunque el secreto real esté en otro lugar.

4. Anota los detalles mínimos (sin secretos)

Escribe:

• Proveedor
• Nombre o ID del proyecto
• Región (si aparece)
• Nombre de la base
• Si hay bases separadas para dev y prod

Ejemplo: si tu host tiene DATABASE_URL y el hostname incluye “neon.tech”, puedes decir “Neon Postgres, proyecto X, región Y, prod y dev separados.” Eso suele ser suficiente para empezar a diagnosticar sin exponer credenciales.

Paso a paso: mapea auth e integraciones clave (a menudo el bloqueo)

La autenticación suele ser el primer cuello de botella. “¿Dónde está hospedada?” no basta si nadie puede decir qué producto de auth controla el acceso, qué dominios están permitidos y dónde se configuran los secretos.

Empieza identificando el proveedor de auth y dónde está configurado. Busca en el repo archivos relacionados con auth (auth, middleware, providers) y en la configuración del hosting variables de entorno. Proveedores comunes: Clerk, Auth0, Supabase Auth, Firebase Auth o una ruta de login personalizada.

Anota:

• Qué proveedor usas (y el nombre del proyecto/app dentro de ese proveedor)
• Qué métodos de inicio están habilitados (email, Google, GitHub, etc.)
• Tus URLs de redirect en producción y dominios permitidos
• Dónde se guardan las sesiones (cookies, JWT o base de datos)
• El texto exacto del error (o una captura con secretos ocultos)

La mayoría de los problemas “funciona localmente, falla en vivo” son desajustes pequeños: URLs de redirect apuntando a localhost, listas de dominios permitidos que no incluyen el dominio real o configuraciones de cookies que no coinciden con HTTPS.

Mapa de síntomas:

• Bucle de redirección tras el login: URL de redirect equivocada o dominio de cookie erróneo
• “Invalid redirect_uri”: URLs de redirect permitidas no actualizadas para producción
• “Unauthorized” solo en vivo: variable de entorno/secret faltante en la configuración del hosting
• Login funciona pero el usuario siempre aparece desconectado: cookie de sesión bloqueada o secreto JWT incorrecto

Ejemplo: el inicio con Google funciona en tu portátil, pero el sitio en vivo muestra “Invalid redirect_uri.” La solución suele ser añadir la URL de callback de producción en el dashboard de auth y actualizar las variables de entorno en el hosting.

Paso a paso: encuentra dominios y configuración DNS

El dominio es la puerta de entrada. Si el DNS apunta al lugar equivocado (o nadie tiene acceso), arreglos que deberían tomar minutos pueden bloquearse días.

Empieza con el nombre de dominio (ejemplo: yourapp.com). Busca en tu correo “renovación de dominio”, “registrador” o el propio dominio. La compañía que envía recibos de renovación suele ser el registrador (GoDaddy, Namecheap, Cloudflare y similares).

Confirma luego dónde se gestiona realmente el DNS. A veces es distinto del registrador. En el panel del registrador busca DNS, Nameservers o DNS Management. Si los nameservers mencionan otra compañía (a menudo Cloudflare), esa otra compañía es donde se hacen las ediciones.

Dentro de la zona DNS, los registros que la gente suele necesitar ver son:

• A record: apunta el dominio raíz a una IP
• CNAME: suele apuntar www a otro hostname
• TXT: usado para verificación de dominio, configuración de email y algunos proveedores de auth

Luego confirma a qué apunta el dominio y si SSL está activo. Advertencias del navegador, cambios DNS recientes o registros en conflicto son señales comunes de que el dominio no coincide con la configuración de hosting actual.

Ejemplo: un prototipo “funciona en el link de preview” pero no en el dominio real. La solución suele ser actualizar un CNAME o añadir un TXT, pero solo si sabes qué proveedor de DNS lo controla.

Antes de pedir ayuda, anota:

• Nombre(s) de dominio y si usas www
• Registrador y proveedor de DNS (si son distintos)
• Quién tiene acceso para editar DNS
• Registros clave actuales (A, CNAME, TXT) y cambios recientes

Checklist rápido para reunir antes de pedir ayuda

La mayoría de los retrasos ocurren porque el código, el hosting, la base de datos y el dominio están en cuentas diferentes y nadie sabe quién puede aprobar acceso.

Mantén esto como una nota simple que puedas pegar en una solicitud de soporte. Si no sabes un elemento, escribe “desconocido” en vez de adivinar.

• Repo (código): propietario y nombre del repo, rama principal, fecha/hora del último commit que puedas ver.
• Hosting: proveedor, nombre del proyecto/app, URL de producción, última vez que se desplegó con éxito.
• Base de datos: proveedor, nombre/ID del proyecto, si producción y desarrollo están separados.
• Dominio y DNS: registrador, dónde se gestiona el DNS y a qué apunta actualmente el dominio (IP A o destino CNAME).
• Acceso y propiedad: quién puede conceder permisos hoy y qué emails son propietarios de las cuentas.

Ejemplo: el login está roto, pero el repo está en el GitHub de un contratista, el sitio se despliega desde una cuenta distinta y el DNS sigue apuntando a una URL de preview antigua. Con la checklist anterior, un desarrollador puede solicitar el acceso correcto y encontrar la configuración de producción real en minutos en vez de días.

Errores comunes que retrasan el soporte

Cuando no estás seguro de dónde se aloja tu app, quienes ayudan pasan la primera hora encontrando lo básico en lugar de arreglar el problema.

Bloqueadores comunes:

• Asumir “está en GitHub” cuando lo único que existe es un zip descargado o una copia dentro de una herramienta builder. Sin un repo real (historia, ramas, una versión principal clara) es difícil revisar cambios o revertir de forma segura.
• Confundir URLs de preview con el sitio de producción. Un enlace de preview puede funcionar mientras que el dominio de producción pagado apunta a otro sitio.
• No tener acceso a las cuentas correctas. Puedes tener acceso al builder de IA, pero no a los paneles de hosting, al registrador del dominio o a la base de datos.

Algunos errores a evitar mientras recopilas detalles:

• No publiques capturas que incluyan claves API, contraseñas de base de datos o tokens privados. Si algo se expuso, gíralo.
• No hagas ediciones “rápidas” en DNS sin anotar qué cambiaste. La propagación lleva tiempo y es fácil perder la pista de qué se rompió frente a qué sigue actualizándose.
• No renombres proyectos, borres entornos o desconectes integraciones “para limpiar” antes de que alguien lo revise. Puede eliminar pistas necesarias para diagnosticar el problema.

Ejemplo realista: convertir un prototipo AI inestable en un proyecto arreglable

Un fundador tiene una demo que se ve genial en capturas. Se generó con un builder de IA y la landing carga bien. Pero cuando usuarios reales intentan iniciar sesión, el sitio en vivo lanza errores y los devuelve a la página principal.

Se desbloquean respondiendo una pregunta de extremo a extremo: dónde vive la app. No solo la web, sino el código, el despliegue, la base de datos y el dominio.

Buscan en su correo, encuentran un repo de GitHub que habían olvidado, y luego revisan el hosting descubriendo que el proyecto está en Vercel. Los despliegues fallaban porque nunca se configuraron las variables de entorno requeridas en el panel del hosting.

Con los despliegues en verde, el login todavía falla. Localizan la base de datos y se dan cuenta de que es un proyecto Supabase con un esquema de tabla antiguo de un prototipo anterior. Una pequeña migración de esquema soluciona el flujo de auth.

Finalmente, el dominio seguía apuntando a un objetivo antiguo. Actualizan el DNS al host correcto y confirman que SSL es válido, así que los navegadores dejan de advertir a los usuarios.

Lo que hizo que la reparación fuera rápida no fue suerte, sino tener listos estos detalles:

• Ubicación del repo y acceso
• Proveedor de hosting y estado del último deploy
• Nombres de variables de entorno (sin valores secretos)
• Proveedor de base de datos y nombre de proyecto
• Registrador de dominio y dónde se gestiona el DNS

Siguientes pasos: empaqueta la información y consigue ayuda más rápido

Envía un mensaje claro que responda dónde está alojada tu app y cómo se conecta con todo lo demás. El objetivo es eliminar las conjeturas para que quien te ayuda pueda comenzar con hechos.

Mantén tu “inventario de app” corto pero completo:

• Repo: dónde vive el código + nombre de la rama principal
• Hosting: proveedor + nombre del proyecto/app + cómo se despliega (manual o automático)
• Base de datos: proveedor + nombre de la base + dónde la app lee los detalles de conexión (env vars)
• Dominio/DNS: registrador + host de DNS + a qué apunta
• Auth/integraciones: proveedor de login + terceros clave (pagos, email, almacenamiento)

El acceso suele ser el cuello de botella, pero compartir contraseñas es arriesgado. Prefiere invitaciones por email con los permisos mínimos necesarios y elimina el acceso cuando termine el trabajo.

Si tu app fue generada por herramientas como Lovable, Bolt, v0, Cursor o Replit, una auditoría enfocada suele ser el primer paso más rápido. Los prototipos generados por IA con frecuencia esconden problemas como secretos expuestos, flujos de auth rotos o lógica de base de datos frágil. FixMyMess (fixmymess.ai) está diseñado para esa situación específica: diagnosticar la base de código y reparar lo necesario para que la app funcione de forma fiable en producción.