Recuperar acesso ao GitHub e hospedagem quando um freelancer é o proprietário

O que você está enfrentando, em termos simples

Se um freelancer configurou seu código e hospedagem usando o próprio e‑mail, você na verdade não controla os sistemas que executam seu produto. Você pode ter os arquivos do app no seu laptop, mas os pontos reais de controle são as contas: o host de repositório (como GitHub), registrador de domínio, provedor de hospedagem ou cloud, e‑mail e quaisquer ferramentas de terceiros.

Isso acontece por razões normais. Um contratado trabalha rápido, usa o e‑mail já logado no computador dele e cria tudo como primeiro admin. Se ninguém para para adicioná‑lo como proprietário, seu produto fica dependente da caixa de entrada, gerenciador de senhas e da autenticação em dois fatores (2FA) de uma só pessoa. Muitas vezes não é maldade — é só como o trabalho foi feito.

Os riscos são imediatos e práticos. Sem controlar essas contas, você pode ser bloqueado de deployar correções, renovar o domínio, pagar hospedagem, rotacionar chaves vazadas, remover acessos antigos ou até conseguir suporte porque não consegue provar propriedade.

Quando fundadores dizem que precisam recuperar acesso ao GitHub e à hospedagem, normalmente querem ir de “consigo ver o app” para “consigo alterar, enviar e proteger sem depender de ninguém”. Esse é o objetivo.

Algumas partes costumam ser recuperáveis com os passos certos. Repositórios podem ser transferidos se o dono cooperar, ou exportados e reimportados se não. A hospedagem pode ser recriada em uma conta nova se você tiver o código, as configurações de ambiente e uma maneira de apontar o domínio para o novo servidor.

Outras partes podem levar mais tempo. Domínios são o principal. Se a conta do registrador e o e‑mail do registrante não são seus, você pode precisar de tickets de suporte, provas e tempo. E‑mail pode ser outro bloqueio: se o e‑mail “admin” for na verdade a caixa do freelancer, resetar qualquer coisa fica doloroso.

Defina expectativas cedo: isso é parte negociação (obter uma transferência limpa), parte suporte (provar que você é o proprietário do negócio) e parte limpeza (rotacionar segredos, consertar deploys, remover atalhos arriscados). Se o projeto foi gerado rapidamente com ferramentas de IA e depois emendado manualmente, você também pode descobrir código frágil e credenciais expostas durante a entrega.

Primeiros 60 minutos: reduza o risco antes de mexer na propriedade

Seu objetivo na primeira hora é evitar surpresas. Antes de pedir transferências ou abrir tickets, reduza a chance de algo ser alterado, apagado ou cobrado sem que você note.

Pause deploys e trabalhos em andamento. Se o freelancer ainda tem acesso, mesmo um “conserto rápido” pode sobrescrever configurações, rotacionar segredos ou atrapalhar o rastro de auditoria. Diga ao time para parar de mesclar e enviar até você saber quem controla o quê.

Depois, rotacione o que você consegue acessar agora. Frequentemente essa é a forma mais rápida de reduzir danos, mesmo antes de fixar a propriedade. Priorize contas que toquem dinheiro, dados de clientes e autenticação.

Faça o básico primeiro:

• Troque senhas de admin do app e remova usuários admin desconhecidos.
• Rotacione senhas/usuários do banco e revogue os antigos quando possível.
• Reemita chaves de API (pagamentos, e‑mail, mapas, analytics) e desative chaves antigas.
• Atualize variáveis de ambiente que você conseguir alcançar.
• Ative 2FA para contas que você já controla.

Depois disso, capture o estado atual. Isso não é trabalho perdido. Se algo mudar depois, você precisará de provas do que existia e de quem estava pagando por isso. Faça screenshots ou exportações de qualquer dashboard que você ainda acessar, especialmente páginas de faturamento, permissões de repositório, registros DNS, configurações de hospedagem e configuração de CI/CD.

Comece um registro de incidentes imediatamente. Mantenha simples e consistente, porque times de suporte vão pedir datas e evidências.

Anote:

• Datas e horários (com fuso)
• Quem você contatou (freelancer, agência, suporte)
• Onde os contatou (e‑mail, chat)
• O que pediu (transferência, acesso admin, mudança de faturamento)
• Números de ticket e resultados

Exemplo: você ainda acessa Stripe e o dashboard do app, mas GitHub e hospedagem estão no e‑mail do freelancer. Na primeira hora você pausa releases, rotaciona secrets de webhooks do Stripe e senhas admin do app, faz screenshot dos registros DNS e salva a mensagem exata enviada solicitando a transferência. Isso te coloca em posição mais forte para prosseguir sem adivinhar o que mudou.

Faça um inventário de contas, proprietários e provas

Antes de tentar retomar algo, escreva o que existe e quem controla hoje. Isso evita que você esqueça a conta que pode te travar depois (geralmente o registrador de domínio, uma caixa de e‑mail compartilhada ou um sistema de CI).

Liste todo serviço que toca seu app. Para muitas startups, isso inclui um host de repositório, provedor de hospedagem, registrador de domínio, provedor de e‑mail, banco de dados e um punhado de ferramentas silenciosas como analytics e monitoramento de erros.

Use um formato simples para cada serviço:

• O que controla (código, DNS, servidores, e‑mail, pagamentos)
• E‑mail da conta e nome exibido
• Quem paga e nome que aparece nas faturas
• Método de 2FA e quem o detém
• Opções de recuperação que você conhece (códigos de backup, e‑mail/telefone de recuperação)
• Status: acesso total, acesso parcial ou sem acesso

Acesso parcial importa. Você pode ver um repo mas não gerenciar configurações da org, ou acessar logs de hospedagem mas não o faturamento, ou editar DNS mas não transferir o domínio.

Em seguida, destaque o que você já controla. Esses são seus pontos de apoio:

• Uma caixa de e‑mail da empresa que você consegue logar
• O método de pagamento que está sendo cobrado
• Qualquer login admin que você ainda tenha (mesmo que não seja o owner de topo)
• Acesso ao domínio (domínios frequentemente decidem todo o resto)

Por fim, junte provas que poderá precisar para suporte. Coloque em uma pasta para não ficar correndo depois: faturas, extratos bancários ou de cartão, contrato ou SOW, histórico de mensagens onde propriedade e acesso admin foram discutidos. Se tiver documentos de formação da empresa, mantenha à mão também.

Como pedir ao freelancer uma transferência adequada

Trate isso como uma entrega, não uma separação. Você quer uma transferência limpa com o mínimo de drama e risco. Um pedido calmo e específico geralmente recebe um sim mais rápido, especialmente se o freelancer não sentir que está sendo acusado.

Facilite o cumprimento. Em vez de “me dá tudo”, envie uma lista curta de ações, em ordem, com um prazo. Diga também que você vai confirmar assim que conseguir logar e ver as configurações, para que saibam que termina de forma limpa.

O que pedir (na ordem certa)

Peça para adicionarem seu e‑mail primeiro, depois transferir a propriedade após você verificar. Isso mantém o projeto estável enquanto o acesso é alterado.

1. Adicione seu e‑mail como admin/owner na org ou repo do GitHub, no provedor de hospedagem e no registrador do domínio.
2. Confirme que você consegue logar, ver faturamento e permissões, e gerenciar 2FA/opções de recuperação.
3. Transfira a propriedade (repo/org, projeto de hospedagem, domínio) para o e‑mail da empresa.
4. Compartilhe materiais de handover: clone do repo, dump do banco, lista das variáveis de ambiente atuais (não cole segredos em chat), passos de deploy e onde os logs/alertas residem.
5. Remova o acesso deles apenas depois que você confirmar que tudo funciona.

Uma frase que ajuda a manter as coisas tranquilas: “Por favor, me adicione como admin primeiro para eu verificar se nada quebra; em seguida faremos a transferência de propriedade.”

Uma mensagem que você pode copiar

"Oi [Nome], precisamos de uma entrega limpa das contas do projeto criadas com seu e‑mail. Pode adicionar [seu e‑mail] como admin no GitHub, na hospedagem e na conta do domínio hoje? Assim que eu verificar o acesso, por favor transfira a propriedade para [e‑mail da empresa]. Também envie um backup (clone do repo, exportação mais recente do BD) e notas básicas de deploy. Prazo: [data/hora]. Se estiver ocupado, diga um horário que funcione e eu me adapto. Se não conseguirmos concluir até lá, abrirei tickets de suporte nas plataformas e revisarei nosso contrato para prosseguir sem bloquear o negócio."

Mantenha tudo por escrito. Se houver resistência, pergunte qual parte é difícil (tempo, falta de acesso, incerteza sobre o que transferir) e ajuste o plano sem mudar o objetivo.

Passo a passo: transferir GitHub, hospedagem, domínio e 2FA

O objetivo é simples: você torna‑se o proprietário em todos os lugares, e quaisquer chaves usadas para deploys e logins são substituídas.

Faça as transferências em uma ordem que evite quebrar a produção.

GitHub: mover a propriedade sem quebrar deploys

Comece obtendo controle da organização do GitHub onde o código deve ficar. Se você ainda não tem uma org, crie uma com um e‑mail gerenciado pela empresa.

Passos-chave:

• Faça o freelancer adicionar sua conta GitHub da empresa como Owner (não apenas colaborador).
• Transfira cada repositório para a org.
• Rotacione itens sensíveis (especialmente GitHub Actions e secrets do repositório). Presuma que qualquer coisa que o freelancer pudesse ver está comprometida.
• Revise chaves de deploy e quaisquer OAuth/GitHub Apps ligados ao repo. Remova o que você não reconhece e recrie chaves sob seu controle.
• Verifique proteção de branches para que um ex‑colaborador não possa pushar direto no main.

Antes de rotacionar secrets, anote como os deploys funcionam hoje (provedor de CI, destino da hospedagem, nomes de ambiente). Isso evita uma interrupção evitável.

Hospedagem, domínio e 2FA: tomar as chaves do reino

A propriedade do código ajuda, mas quem controla hospedagem e DNS ainda pode alterar o que os usuários veem.

• Hospedagem/cloud: seja adicionado como admin/top owner primeiro, depois mova o faturamento para um método da empresa e então remova o freelancer.
• Equipes/workspaces: onde a plataforma suportar, mova projetos para uma equipe/org da empresa para que o acesso não dependa de uma pessoa.
• Domínio/registrador: transfira o domínio para uma conta que você controla e confirme que pode editar registros DNS. Confirme também quem controla SSL/TLS e renovações.
• E‑mail da empresa: troque logins de plataforma que usam o e‑mail do freelancer para uma caixa controlada pela empresa.
• 2FA: reatribua 2FA para seus dispositivos ou para um método gerenciado pela empresa. Gere novos códigos de backup e armazene com segurança.

Checagem de sanidade após transfers: abra uma janela anônima e verifique se sua conta admin pode (1) alterar DNS, (2) mudar faturamento e (3) implantar uma alteração de teste. Se alguma dessas ainda depender do freelancer, você não terminou.

Quando o freelancer não responde: trabalhar com suporte das plataformas

Se o freelancer não responder, suporte é a sua próxima alavanca. O objetivo é provar que você é o legítimo proprietário da empresa e mover o ativo para uma conta que você controla.

Escreva uma história curta e consistente para usar em todos os tickets. Mantenha factual: o que é o projeto, quais contas estão bloqueadas, quem as criou, quando você pagou e qual mudança solicita.

O que o suporte normalmente pede de você

A maioria das plataformas solicita categorias parecidas de prova:

• Prova de pagamento (faturas, recibos, extratos)
• Prova de negócio (registro da empresa, comprovação de que você representa a empresa)
• Prova de controle de domínio (habilidade de adicionar um registro DNS, acesso ao e‑mail de faturamento, histórico de pagamento do registrador)
• Pistas da conta (usernames, nomes de org, nomes de repositório, domínios, datas aproximadas de criação)
• Checagens de segurança (endereço de cobrança, 4 últimos dígitos do cartão, PIN de suporte se houver)

Quando o suporte pedir follow‑ups, responda em uma única mensagem clara com anexos rotulados (por exemplo: “Anexo A - fatura”).

O que solicitar (e o que evitar)

Peça a menor mudança que lhe dê controle. Muitos times de suporte não “entregam uma conta inteira” sem provas fortes.

Pedidos frequentemente realistas:

• Adicionar seu e‑mail como owner/admin na org, repo ou projeto de hospedagem
• Trocar o e‑mail da conta para um endereço controlado pela empresa
• Ajudar a migrar repositórios, projetos ou assinaturas para uma conta nova que você crie
• Resetar ou remover 2FA apenas como parte de um processo de verificação de propriedade

Evite pedidos vagos como “Me dê a conta.” Uma frase melhor: “Por favor, adicione meu e‑mail como admin para que eu possa transferir a propriedade e rotacionar credenciais.”

O tempo varia. Alguns hosts respondem em horas. Registradores de domínio e times de identidade podem levar dias e várias trocas. Planeje 2–5 dias úteis, mantenha um ticket por plataforma e atualize seu registro de incidentes.

Erros comuns que dificultam a recuperação

A maior armadilha é achar que “o site está no ar, então estamos bem.” Um protótipo pode rodar e ainda ser inseguro. Builds apressados frequentemente incluem chaves expostas, regras de login fracas ou rotas admin nunca protegidas. Se você esperar até um incidente para consertar a propriedade, o problema vira um incidente de segurança.

Outro erro é tratar isso como um problema de senha. Se o freelancer criou tudo com o e‑mail dele, “a senha certa” não dá controle real. Você precisa de transferência de propriedade: papel de admin, dono do faturamento, controle do registrante do domínio e 2FA que você gerencia.

Times também tropeçam em segredos. Pessoas mudam a senha da hospedagem e esquecem tokens que ficam em três outros lugares. Antes de mover qualquer coisa, identifique onde as credenciais existem:

• Configurações de CI/CD (pipelines, chaves de deploy, tokens de serviço)
• Variáveis de ambiente na hospedagem (prod e preview)
• O próprio repositório (arquivos de config, commits antigos, .env de exemplo)
• Código client‑side (qualquer coisa enviada ao navegador é efetivamente pública)
• Dashboards de terceiros (pagamentos, e‑mail, analytics, monitoramento de erros)

Backups são pulados porque todos querem “apenas transferir.” Aí registros DNS são sobrescritos, um banco é substituído ou o histórico do repositório se perde durante uma exportação apressada. Faça um snapshot limpo primeiro: repo, banco, buckets de storage e configurações DNS atuais.

Por fim, não faça movimentos que possam causar lockouts sem plano. Revogar acesso ou trocar e‑mails cedo demais pode causar deploys falhando ou uma reação defensiva. Mova-se em ordem controlada: confirme que consegue implantar e reverter, depois transfira propriedade e então rotacione chaves.

Checklist rápido: estamos seguros agora?

"Seguro" significa que o negócio continua rodando mesmo se o freelancer desaparecer hoje.

Comece pelo maior ponto único de falha: seu domínio. Se você não consegue logar no registrador, você não controla realmente o produto. Mudanças de DNS podem tirar site e e‑mail do ar rapidamente.

Use isto como checagem prática:

• Controle do domínio: você consegue logar no registrador, editar DNS e o domínio não pode ser transferido sem sua aprovação.
• Cobertura admin: cada plataforma crítica tem pelo menos dois admins de confiança (sem logins compartilhados).
• Identidade da empresa: e‑mail de faturamento, e‑mail de recuperação e 2FA estão vinculados a caixas e dispositivos controlados pela empresa.
• Segurança dos dados: você tem um clone recente do repo, uma exportação do banco e uma cópia segura das variáveis de ambiente necessárias.
• Segurança de deploy: você consegue redeployar da sua própria conta, e sabe exatamente onde o app está rodando e quem tem acesso.

Se algum item for “não sei”, trate como “não”.

Um teste simples de realidade: escreva o único login que derrubaria a empresa se perdido. Para muitas equipes é o registrador, o admin do e‑mail principal e o dono do host de código. Conserte esses primeiro.

Cenário exemplo: uma fundadora tentando retomar controle em 2 dias

Maya é uma fundadora solo. Um freelancer construiu seu MVP e lançou rápido: um repositório no GitHub (backend e frontend no mesmo repo), um banco gerenciado em um provedor de hospedagem e um domínio apontando para um frontend simples. Tudo funciona, mas o freelancer criou tudo com o próprio e‑mail e Maya não tem acesso admin.

Hora 0 a 2 (estabilizar): Maya reduz risco primeiro. Ela faz screenshots de tudo que consegue achar (e‑mails de faturamento, faturas, credenciais antigas, avisos de renovação de domínio). Ela troca senhas nas contas que controla (e‑mail da empresa, portal de pagamentos) e pausa pagamentos automáticos ligados a serviços que não consegue acessar.

Fim do Dia 1 (juntar provas e pedir transferência): Maya reúne provas de que o projeto é dela: contrato assinado, recibos de pagamento, site público mostrando sua marca e mensagens do freelancer sobre as configurações. Ela envia pedido claro: transferir o repo para sua org do GitHub, adicioná‑la como owner do faturamento na hospedagem e mover o domínio para a conta do registrador dela.

O que pode fazer imediatamente vs o que depende de outros:

• Imediato: coletar provas, proteger o e‑mail da empresa, listar serviços, preparar contas‑donas novas (org GitHub, hospedagem, registrador).
• Depende do contratado: iniciar transferências, adicioná‑la como owner/admin, fornecer códigos de recuperação 2FA ou remover dispositivos antigos.
• Depende do suporte da plataforma: recuperação forçada de domínio, disputas de repositório ou checagens de identidade quando o freelancer some.

Dia 2 (rotacionar segredos e criar caminho limpo): Assim que Maya obtiver algum acesso, ela rotaciona tudo que poderia ter sido copiado: senhas do banco, chaves de API, segredos de autenticação, tokens de deploy. Se não conseguir acesso, executa um plano alternativo: cria contas novas, restaura de backups (ou exporta o que puder do app ao vivo) e redeploya na infraestrutura que ela controla. Depois escreve um mapa simples de propriedade: quem possui GitHub, hospedagem, domínio, banco de dados e 2FA.

Próximos passos: travar propriedade e evitar que isso se repita

Depois de retomar o controle, não pare em “está funcionando”. Torne difícil que seu produto fique preso ao e‑mail de uma pessoa novamente.

Crie uma identidade raiz da empresa que possua o essencial. Use uma caixa controlada pela empresa (geralmente um e‑mail administrativo compartilhado no seu domínio) como e‑mail de faturamento e recuperação para registrador, org do GitHub e contas de hospedagem. Mantenha chato e estável. Não deve pertencer a um freelancer nem depender da caixa pessoal de um funcionário.

Defina regras simples que combinem com como times reais trabalham:

• Mantenha pelo menos dois owners/admins verificados em cada conta crítica.
• Armazene códigos de recuperação e chaves em um gerenciador de senhas da equipe.
• Exija que contratados usem suas próprias contas como membros, nunca como owners.
• Use um checklist curto de handover ao fim do contrato (o que foi construído, onde roda, como deployar, onde os segredos vivem).
• Faça um exercício trimestral de acesso: confirme que você consegue logar e rotacionar um token sem o construtor original.

Se seu app foi feito rápido com IA ou montado de protótipos, planeje tempo para limpeza antes de tratá‑lo como produção. Correções de propriedade são só metade da história. Código bagunçado e deploys apressados geralmente escondem problemas como segredos hardcoded, fluxos de autenticação quebrados ou queries inseguras.

Uma abordagem prática: congele mudanças por um dia, mova segredos para variáveis de ambiente corretas ou um cofre de segredos, e escreva uma fonte única de verdade para deploy (onde está hospedado, como implantar, o que significa “saudável”). Mesmo uma página de notas economiza semanas depois.

Se quiser ajuda externa, FixMyMess (fixmymess.ai) é especializada em transformar protótipos gerados por IA em apps prontos para produção. Uma auditoria rápida também revela armadilhas comuns de handover, como segredos expostos, autenticação quebrada e setups de deploy que só funcionam na máquina do construtor original.

Trate propriedade de contas como parte do produto, não só papelada. Acompanhe acessos, proprietários e passos de recuperação da mesma forma que acompanha bugs e features, para que nenhuma pessoa única consiga bloquear o negócio novamente.