Onde seu app está hospedado: encontre repo, hospedagem, BD e domínio

O que “onde seu app vive” realmente significa

Quando alguém pergunta onde seu app está hospedado, raramente é só uma coisa. Estão tentando traçar o caminho do clique do usuário até os sistemas que fazem seu app funcionar.

A maioria dos apps tem quatro “lares” separados. Misturá-los é uma forma fácil de perder horas:

• Código (repo): onde o código-fonte vive e é editado (GitHub, GitLab, Bitbucket, ou dentro de uma ferramenta como Replit).
• Hospedagem (runtime): onde o app ao vivo roda quando usuários o visitam (Vercel, Netlify, Render, Fly.io, AWS, um VPS, etc.).
• Banco de dados: onde os dados vivem (usuários, pedidos, conteúdo), como Postgres, MySQL, MongoDB ou um produto de banco hospedado.
• Domínio e DNS: as configurações que conectam seu nome de domínio à hospedagem e a outros serviços (registros de email, registros de verificação, e assim por diante).

Quem ajuda pede esses detalhes primeiro porque muitos bugs são, na verdade, problemas de “lugar errado”. Um erro de login pode ser código ou variáveis de ambiente ausentes nas configurações da hospedagem. “Dados não salvando” pode ser um bug no código ou o app apontando para o banco de dados errado.

Você pode compartilhar muita informação com segurança, e isso acelera as coisas. Normalmente é seguro compartilhar nomes de provedores, screenshots do painel (com segredos ocultos), mensagens de erro e nomes de serviços. Mantenha privados tudo que concede acesso: senhas, chaves privadas, tokens de API, strings de conexão do banco de dados e valores completos de variáveis de ambiente.

Saber onde estão essas partes transforma depuração de adivinhação em checagem. Na FixMyMess vemos frequentemente protótipos gerados por IA onde o repositório existe, mas o app implantado está rodando um branch diferente, ou segredos acabaram expostos. Uma vez que o repo, a implantação e o banco de dados estejam claramente identificados, os reparos ficam mais simples e rápidos.

Uma nota simples para capturar o básico

Se você conseguir nomear os quatro locais abaixo, o suporte fica muito mais rápido porque não há adivinhação sobre o que checar primeiro.

Copie e preencha isto:

• Repo: provedor + nome do repo + quem pode conceder acesso
• Hospedagem: provedor + nome do projeto/app + método de deploy (auto via git, manual)
• Banco de dados: provedor + nome do banco + onde credenciais são guardadas
• Domínio/DNS: registrador/provedor de DNS + domínio + quem pode editar registros
• Último funcionamento conhecido: quando funcionou por último e o que mudou

Se um protótipo construído por IA quebrou após “um pequeno ajuste”, esta única nota evita o erro clássico de consertar o ambiente errado.

Passo a passo: encontrar seu repositório de código

Se você ainda não tem certeza de onde seu app está hospedado, comece pelo repo mesmo assim. O repositório é o melhor lugar para ver o que você realmente tem, o que mudou por último e o que alguém pode realisticamente consertar.

Volte à ferramenta de IA ou ao editor que você usou. Muitas ferramentas (Lovable, Bolt, v0, Cursor, Replit) têm uma configuração como GitHub, Repository, Export ou Sync que mostra para onde o código foi empurrado. Se vir uma conta conectada, anote a org ou o nome de usuário.

Se não lembrar para onde o código foi:

• Abra a ferramenta onde você construiu e procure por qualquer conexão Git/Repository ou histórico de exportação.
• Procure no seu e-mail por convites de repo e notificações como “deployment succeeded”, “build failed” ou avisos do GitHub.
• Verifique qualquer conta GitHub, GitLab ou Bitbucket que você tenha usado e olhe em Organizations e Repositories.

Quando encontrar o repo, capture o que as pessoas vão pedir:

• Dono do repo (pessoa ou organização)
• Nome do repo
• Quem tem acesso (e quem pode conceder acesso)
• Branch padrão e data do último commit

Cheque rápido: se o último commit for de meses atrás mas seu app mudou recentemente, você pode estar olhando o repo errado, ou a ferramenta nunca enviou o código mais recente.

Passo a passo: identificar hospedagem e implantações

Quando alguém pergunta “onde seu app está hospedado”, normalmente querem duas coisas: onde o site ao vivo roda e como novo código chega até lá.

Comece pelo lugar que você usou para construir o app. Muitos builders de IA e templates têm uma página Deploy que mostra uma conta de provedor conectada (por exemplo, Vercel ou Netlify). Se diz “connected to GitHub”, as implantações frequentemente são automáticas a partir de um repo.

Se não souber qual host é, verifique sua caixa de entrada e faturas por nomes como Vercel, Netlify, Render, Fly.io, Railway, ou provedores de nuvem (AWS, GCP, Azure). Se encontrar mais de um, anote qual serve o site público vs jobs em background ou o banco de dados.

No painel de hospedagem do projeto certo, anote:

• Nome do projeto/app conforme exibido no host
• Nomes de ambiente (production, preview, staging) e qual URL é produção
• Hora do último deploy bem-sucedido (e qual commit/versão)
• Onde ficam os logs de build e runtime

Então confirme como os deploys acontecem. Procure por configurações como “deploy on push” ou “connected to main branch”. Se for manual, anote quem pode implantar e o que devem clicar.

Exemplo prático: sua homepage atualiza quando você faz merge para main, mas a API continua quebrada. Isso geralmente significa que o frontend está no Vercel, enquanto o backend roda em outro lugar (Render, Fly.io ou um projeto de nuvem separado). Anotar ambos os alvos economiza tempo.

Se você levar essa informação para a FixMyMess para uma auditoria gratuita de código, podemos ir direto aos logs e ao pipeline de implantação corretos em vez de gastar tempo só localizando onde as coisas rodam.

Passo a passo: localizar o banco de dados por trás do seu app

Se você conseguir nomear o provedor do banco e o projeto exato, a depuração fica muito mais rápida. Muitos problemas de “meu app está quebrado” são, na verdade, “o app não consegue alcançar o banco” ou “ele está apontando para o banco errado”.

1) Comece pelos bancos gerenciados comuns

Para ferramentas de IA e templates, o banco costuma ser um serviço gerenciado. Procure por Supabase, Neon, PlanetScale, Firebase, MongoDB Atlas ou AWS RDS nas listas de ferramentas, nas faturas ou nos e-mails. Se tiver um painel de hospedagem, verifique também qualquer seção de “recursos conectados”.

2) Verifique as configurações da hospedagem por variáveis de ambiente do banco

No provedor de hospedagem, encontre Environment Variables ou Secrets. Você não precisa copiar o valor secreto. Está tentando identificar o provedor e o banco alvo.

Nomes comuns de variáveis:

• DATABASE_URL ou DB_URL
• POSTGRES_URL ou PGHOST
• MONGO_URL ou MONGODB_URI
• SUPABASE_URL (frequentemente acompanhada de chaves)
• FIREBASE_PROJECT_ID

Pelo nome da variável e partes não secretas (como o hostname) você geralmente identifica o provedor.

3) Escaneie o repo em busca de pistas sobre o banco

No seu repositório, pesquise por “supabase”, “prisma”, “mongoose”, “firebase”, “postgres”, “mysql” ou “mongodb”. Verifique também arquivos de configuração como .env.example, prisma/schema.prisma, firebase.json ou docker-compose.yml. Eles frequentemente revelam o tipo de banco mesmo que o segredo ao vivo esteja armazenado em outro lugar.

4) Registre os detalhes mínimos (sem segredos)

Anote:

• Provedor
• Nome do projeto ou ID do projeto
• Região (se exibida)
• Nome do banco
• Se há bancos separados para dev e prod

Exemplo: se seu host tem DATABASE_URL e o hostname inclui “neon.tech”, você pode dizer ao suporte “Neon Postgres, projeto X, região Y, prod e dev separados.” Isso normalmente é suficiente para começar a diagnosticar sem expor credenciais.

Passo a passo: mapear autenticação e integrações de chave (quase sempre o bloqueador)

Autenticação costuma ser o primeiro gargalo. “Onde está hospedado?” não basta se ninguém souber qual produto de auth está em uso, quais domínios estão permitidos e onde os segredos estão configurados.

Comece identificando o provedor de auth e onde ele é configurado. Procure no repo por arquivos ou middleware de auth e nas configurações da hospedagem por variáveis de ambiente. Provedores comuns incluem Clerk, Auth0, Supabase Auth, Firebase Auth ou uma rota de login customizada.

Anote:

• Qual provedor você usa (e o nome do projeto/app dentro desse provedor)
• Quais métodos de entrada estão habilitados (email, Google, GitHub, etc.)
• Suas URLs de redirect/redirects de produção e domínios permitidos
• Onde as sessões são armazenadas (cookies, JWT ou banco de dados)
• O texto exato do erro (ou uma screenshot com segredos ocultos)

A maioria dos problemas “funciona localmente, falha ao vivo” são pequenas incompatibilidades: URLs de redirect ainda apontam para localhost, a lista de domínios permitidos não inclui o domínio real, ou as configurações de cookie não coincidem com HTTPS.

Mapa de sintomas:

• Loop de redirecionamento após login: URL de redirect errada ou domínio do cookie
• “Invalid redirect_uri”: URLs de redirect permitidas não atualizadas para produção
• “Unauthorized” apenas no vivo: variável de ambiente/secreto ausente nas configurações da hospedagem
• Login funciona mas o usuário é sempre deslogado: cookie de sessão bloqueado ou segredo JWT errado

Exemplo: o login do Google funciona no laptop, mas o site ao vivo mostra “Invalid redirect_uri.” A correção costuma ser adicionar a URL de callback de produção no painel do provedor de auth e atualizar as variáveis de ambiente na hospedagem.

Passo a passo: encontrar configurações de domínio e DNS

O domínio é a porta de entrada. Se o DNS aponta para o lugar errado (ou ninguém tem acesso), correções que deveriam levar minutos podem atrasar dias.

Comece pelo nome do domínio (exemplo: yourapp.com). Procure no seu e-mail por “domain renewal”, “registrar” ou pelo próprio nome do domínio. A empresa que envia recibos de renovação geralmente é o registrador (GoDaddy, Namecheap, Cloudflare e similares).

Em seguida, confirme onde o DNS é realmente gerenciado. Às vezes é diferente do registrador. No painel do registrador, procure por DNS, Nameservers ou DNS Management. Se os nameservers apontarem para outra empresa (frequentemente Cloudflare), essa outra empresa é onde as edições acontecem.

Dentro da zona de DNS, os registros que as pessoas geralmente precisam ver são:

• A record: aponta o domínio raiz para um endereço IP
• CNAME: frequentemente aponta www para outro hostname
• TXT: usado para verificação de domínio, configurações de email e alguns provedores de auth

Então confirme para onde o domínio aponta e se o SSL está ativo. Avisos no navegador, mudanças recentes de DNS ou registros conflitantes são sinais comuns de que o domínio não corresponde à configuração de hospedagem atual.

Exemplo: um protótipo “funciona no link de preview” mas não no domínio real. A correção costuma ser atualizar um CNAME ou adicionar um TXT, mas só se você souber qual provedor de DNS tem controle.

Antes de pedir ajuda, escreva:

• Nome(s) de domínio e se usa www
• Registrador e provedor de DNS (se diferentes)
• Quem tem acesso para editar o DNS
• Registros chave atuais (A, CNAME, TXT) e mudanças recentes

Checklist rápido para reunir antes de pedir ajuda

A maioria dos atrasos acontece porque o código, hospedagem, banco de dados e domínio pertencem a contas diferentes, e ninguém sabe quem pode aprovar acesso.

Mantenha isto como uma nota simples que você pode colar em um pedido de suporte. Se não souber um item, escreva “unknown” em vez de chutar.

• Repo (código): dono e nome do repo, branch main, data/hora do último commit que você consegue ver.
• Hospedagem: provedor, nome do projeto/app, URL de produção, hora do último deploy bem-sucedido.
• Banco de dados: provedor, nome/ID do projeto, se produção e desenvolvimento são separados.
• Domínio e DNS: registrador, onde o DNS é gerenciado e para onde o domínio aponta atualmente (IP do A record ou alvo do CNAME).
• Acesso e propriedade: quem pode conceder permissões hoje e quais e-mails são donos das contas.

Exemplo: o login está quebrado, mas o repo está no GitHub de um contratado, o site é implantado de outra conta, e o DNS ainda aponta para uma URL de preview antiga. Com a checklist acima, um desenvolvedor pode pedir o acesso certo e encontrar a configuração de produção real em minutos, não dias.

Erros comuns que atrasam o suporte

Quando você não sabe onde seu app está hospedado, quem ajuda passa a primeira hora encontrando o básico em vez de consertar o problema.

Bloqueadores comuns:

• Assumir “está no GitHub” quando a única coisa existente é um zip baixado ou uma cópia dentro de uma ferramenta builder. Sem um repo real (histórico, branches, uma versão principal clara), é difícil revisar mudanças ou reverter com segurança.
• Misturar URLs de preview com o site de produção real. Um link de preview pode funcionar enquanto o domínio pago aponta para outro lugar.
• Não ter acesso às contas certas. Você pode ter acesso ao builder de IA, mas não aos dashboards de hospedagem, registrador de domínio ou do banco de dados.

Alguns cuidados ao reunir detalhes:

• Não publique screenshots que incluam API keys, senhas de banco ou tokens privados. Se algo foi exposto, rode a rotação das credenciais.
• Não faça edições rápidas de DNS sem anotar o que mudou. A propagação leva tempo e é fácil perder o controle do que está quebrado vs. o que ainda está atualizando.
• Não renomeie projetos, delete ambientes ou desconecte integrações “para limpar as coisas” antes de alguém olhar. Isso pode apagar pistas necessárias para diagnosticar o problema.

Exemplo realista: transformar um protótipo IA instável em um projeto consertável

Um fundador tem um demo que parece ótimo em screenshots. Foi gerado com um builder de IA e a landing carrega bem. Mas quando usuários reais tentam logar, o site ao vivo lança erros e os manda de volta para a homepage.

Eles se desatam respondendo a uma pergunta de ponta a ponta: onde o app vive. Não só o site, mas o código, o deploy, o banco de dados e o domínio.

Eles procuram a caixa de entrada, encontram um repo no GitHub que tinham esquecido, então checam a hospedagem e descobrem que o projeto está no Vercel. Os deploys estão falhando porque variáveis de ambiente necessárias nunca foram definidas no painel de hospedagem.

Com os deploys em ordem, o login ainda falha. Localizam o banco de dados e percebem que é um projeto Supabase usando um schema antigo de um protótipo anterior. Uma correção rápida de esquema (ou uma pequena migração) restaura o fluxo de autenticação.

Por fim, o domínio ainda aponta para um alvo antigo. Atualizam o DNS para o host correto e confirmam que o SSL está válido, então os navegadores pararam de avisar usuários.

O que tornou o conserto rápido não foi sorte. Foi ter estes detalhes prontos:

• Localização do repo e acesso
• Provedor de hospedagem e status do último deploy
• Nomes de variáveis de ambiente (não os valores secretos)
• Provedor de banco de dados e nome do projeto
• Registrador de domínio e onde o DNS é gerenciado

Próximos passos: empacote a informação e consiga a ajuda certa mais rápido

Envie uma mensagem clara que responda onde seu app está hospedado e como isso se conecta ao resto. O objetivo é remover a adivinhação para que quem ajuda possa sair dos fatos.

Mantenha seu “inventário do app” curto mas completo:

• Repo: onde o código vive + nome do branch principal
• Hospedagem: provedor + nome do projeto/app + como os deploys acontecem (manual ou auto)
• Banco de dados: provedor + nome do banco + onde o app lê os detalhes de conexão (env vars)
• Domínio/DNS: registrador + host do DNS + para onde aponta
• Auth/integrations: provedor de login + terceiros chave (pagamentos, email, storage)

Acesso costuma ser o gargalo, mas compartilhar senhas é arriscado. Prefira convite por e-mail com as permissões mínimas necessárias e remova o acesso após o trabalho.

Se seu app foi gerado por ferramentas como Lovable, Bolt, v0, Cursor ou Replit, uma auditoria focada costuma ser o passo mais rápido. Protótipos gerados por IA frequentemente escondem problemas como segredos expostos, fluxos de auth quebrados ou lógica de banco frágil. FixMyMess (fixmymess.ai) foi feito para essa situação específica: diagnosticar a base de código e reparar o necessário para que o app rode de forma confiável em produção.