Recupera el acceso a GitHub y al hosting cuando un freelancer es el propietario

Con qué te enfrentas, en términos simples

Si un freelancer configuró tu código y hosting con su propio correo, en realidad no controlas los sistemas que ejecutan tu producto. Puede que tengas los archivos de la app en tu portátil, pero los puntos reales de control son las cuentas: tu host de repositorios (como GitHub), el registrador de dominios, el proveedor de hosting o cloud, el correo y cualquier herramienta de terceros.

Esto pasa por razones normales. Un contratista trabaja rápido, usa el correo que ya tiene logueado en su ordenador y crea todo como primer admin. Si nadie se toma el tiempo de añadirte como propietario, tu producto depende de la bandeja de entrada, gestor de contraseñas y la 2FA de una sola persona. A menudo no es malintencionado. Es simplemente cómo se hizo el trabajo.

Los riesgos son inmediatos y prácticos. Sin control de estas cuentas, puedes quedarte bloqueado para desplegar arreglos, renovar el dominio, pagar facturas de hosting, rotar claves comprometidas, eliminar accesos antiguos o incluso obtener ayuda del soporte porque no puedes probar la titularidad.

Cuando los fundadores dicen que necesitan recuperar GitHub y el hosting, generalmente significan pasar de “puedo ver la app” a “puedo cambiarla, lanzarla y asegurarla sin pedir permiso a nadie”. Ese es el objetivo.

Algunas partes suelen recuperarse con los pasos adecuados. Los repositorios a menudo pueden transferirse si el propietario actual coopera, o exportarse y reimportarse si no lo hace. El hosting suele poder recrearse en una cuenta nueva si tienes el código, la configuración del entorno y la forma de apuntar el dominio al nuevo servidor.

Otras partes pueden llevar más tiempo. Los dominios son lo más crítico. Si la cuenta del registrador y el correo del registrante no son tuyos, puede que necesites tickets de soporte, pruebas y tiempo. El correo puede ser otro bloqueador: si tu "correo admin" es en realidad la bandeja del freelancer o un dominio que no controlas, restablecer cualquier cosa se complica.

Fija expectativas desde el principio: esto es en parte negociación (lograr una transferencia limpia), en parte tickets de soporte (probar que eres el dueño del negocio) y en parte limpieza (rotar secretos, arreglar despliegues, eliminar atajos riesgosos). Si el proyecto se generó rápidamente con herramientas AI y luego se parcheó manualmente, también puedes descubrir código frágil y credenciales expuestas durante la entrega.

Primeros 60 minutos: reduce el riesgo antes de tocar la titularidad

Tu objetivo en la primera hora es evitar sorpresas. Antes de pedir transferencias o abrir tickets, reduce la posibilidad de que algo se cambie, borre o facture sin que te des cuenta.

Pausa despliegues y trabajo en curso. Si un freelancer aún tiene acceso, incluso un “arreglo rápido” puede sobrescribir configuraciones, rotar secretos o ensuciar la pista de auditoría. Dile a tu equipo que deje de hacer merges y deploys hasta que sepas quién controla qué.

Luego rota lo que puedas acceder ahora mismo. Esto suele ser la forma más rápida de reducir el daño, incluso antes de arreglar la titularidad. Prioriza cuentas que tocan dinero, datos de clientes y autenticación.

Haz lo básico primero:

• Cambia las contraseñas de admin de la app y elimina usuarios admin desconocidos.
• Rota contraseñas/usuarios de la base de datos y revoca los antiguos cuando sea posible.
• Reemite claves API (pagos, correo, mapas, analytics) y desactiva las antiguas.
• Actualiza cualquier variable de entorno a la que puedas llegar.
• Activa 2FA para las cuentas que ya controlas.

Después, captura el estado actual. Esto no es trabajo inútil. Si algo cambia más tarde, necesitarás prueba de lo que existía y quién pagaba. Haz capturas de pantalla o exportes de cualquier panel al que aún tengas acceso, especialmente páginas de facturación, permisos de repositorio, registros DNS, configuraciones de hosting y configuración de CI/CD.

Comienza un registro de incidentes de inmediato. Mantenlo simple y consistente, porque los equipos de soporte te pedirán fechas y evidencias.

Anota:

• Fechas y horas (con zona horaria)
• A quién contactaste (freelancer, agencia, soporte)
• Dónde los contactaste (correo, chat)
• Qué solicitaste (transferencia, acceso admin, cambio de facturación)
• Números de ticket y resultados

Ejemplo: puedes seguir entrando a Stripe y al panel de la app, pero GitHub y el hosting están con el correo del freelancer. En la primera hora, pausan los releases, rotan secretos de webhooks de Stripe y contraseñas admin de la app, hacen capturas de los registros DNS y guardan el mensaje exacto que enviaron solicitando la transferencia. Eso te pone en mejor posición para seguir sin adivinar qué cambió.

Haz un inventario de cuentas, propietarios y pruebas

Antes de intentar recuperar algo, escribe qué existe y quién lo controla hoy. Esto evita que te saltes la única cuenta que puede bloquearte después (a menudo el registrador del dominio, una bandeja compartida de correo o un sistema de CI).

Lista cada servicio que toca tu app. Para muchas startups, eso incluye un host de repos, proveedor de hosting, registrador de dominios, proveedor de correo, base de datos y un puñado de herramientas silenciosas como analytics y tracking de errores.

Usa un formato simple para cada servicio:

• Qué controla (código, DNS, servidores, correo, pagos)
• Correo de la cuenta y nombre visible
• Quién paga y qué nombre aparece en las facturas
• Método de 2FA y quién lo tiene
• Opciones de recuperación que conoces (códigos de respaldo, correo/teléfono de recuperación)
• Estado: acceso total, acceso parcial o sin acceso

El acceso parcial importa. Puedes ver un repo pero no gestionar la org, acceder a logs de hosting pero no a facturación, o editar DNS pero no transferir el dominio.

Después, resalta lo que ya controlas. Estos son tus anclas:

• Un buzón de correo de la empresa al que puedes entrar
• El método de pago que está cobrando
• Cualquier login admin que aún tengas (aunque no sea el owner de más alto nivel)
• Acceso al dominio (los dominios suelen decidirlo todo)

Finalmente, recopila pruebas que puedas necesitar para soporte. Ponlas en una carpeta para no tener que buscarlas después: facturas, extractos bancarios o de tarjeta, tu contrato o SOW, e historial de mensajes donde se habló de titularidad y acceso admin. Si tienes documentos de constitución de la empresa, tenlos a mano también.

Cómo pedir al freelancer una transferencia correcta

Trátalo como una entrega, no como una ruptura. Quieres una transferencia limpia con el menor drama y riesgo posible. Una solicitud calma y concreta suele obtener un sí más rápido, especialmente si el freelancer siente que lo están acusando.

Haz que sea fácil cumplirla. En lugar de “dame todo”, envía una lista corta de acciones, en orden, con un intervalo de tiempo. Di también que confirmarás una vez que puedas entrar y ver la configuración, para que sepan que esto termina limpio.

Qué pedir (en el orden correcto)

Pídeles que te añadan primero y luego transfieran la titularidad después de que verifiques. Eso mantiene el proyecto estable mientras cambian los accesos.

1. Añade tu correo como admin/owner en la org o repo de GitHub, en el proveedor de hosting y en la cuenta del registrador de dominio.
2. Confirma que puedes iniciar sesión, ver facturación y permisos, y gestionar 2FA/opciones de recuperación.
3. Transfiere la titularidad (repo/org, proyecto de hosting, dominio) al correo de la empresa.
4. Comparte materiales de entrega: clon del repo, dump de la BD, lista de variables de entorno actuales (no pegues secretos en chat), pasos de despliegue y dónde están logs/alertas.
5. Elimina su acceso solo después de que confirmes que todo funciona.

Una frase que mantiene las cosas fluidas: “Por favor, añádeme como admin primero para que pueda verificar que nada se rompe, luego haremos la transferencia de titularidad inmediatamente después.”

Un mensaje que puedes copiar

“Hi [Name], necesitamos una entrega ordenada de las cuentas del proyecto creadas con tu correo. ¿Puedes añadir [tu correo] como admin en GitHub, hosting y la cuenta del dominio hoy? Una vez que verifique el acceso, por favor transfiere la titularidad a [correo de la empresa]. También comparte un respaldo (clon del repo, exportación DB más reciente) y notas básicas de despliegue. Fecha límite: [fecha/hora]. Si estás ocupado, dime qué hora te viene bien y me adapto. Si no podemos completar esto para entonces, abriré tickets de soporte con las plataformas y revisaré nuestro contrato para avanzar sin bloquear el negocio.”

Mantén todo por escrito. Si ponen resistencia, pregunta qué parte es difícil (tiempo, acceso perdido, duda sobre qué transferir) y ajusta el plan sin cambiar el objetivo.

Paso a paso: transferir GitHub, hosting, dominio y 2FA

El objetivo es sencillo: que tú seas el propietario en todas partes y que cualquier clave oculta usada para despliegues y accesos se reemplace.

Haz las transferencias en un orden que evite romper la producción.

GitHub: mover la titularidad sin romper despliegues

Empieza por controlar la organización de GitHub donde debería vivir el código. Si no tienes aún una org, crea una bajo un correo gestionado por la empresa.

Pasos clave:

• Pide al freelancer que añada tu cuenta de GitHub de empresa como Owner (no solo colaborador).
• Transfiere cada repositorio a la org.
• Rota elementos sensibles (especialmente GitHub Actions y los secretos del repositorio). Asume que todo lo que el freelancer pudo ver está comprometido.
• Revisa las deploy keys y cualquier OAuth/GitHub App ligada al repo. Elimina lo que no reconozcas y recrea claves bajo tu control.
• Revisa las protecciones de ramas para que un antiguo colaborador no pueda pushear directamente a main.

Antes de rotar secretos, anota qué usa hoy para desplegar (proveedor de CI, destino de hosting, nombres de entornos). Eso evita una caída evitable.

Hosting, dominio y 2FA: toma el control de las llaves del reino

Tener el código ayuda, pero quien controla el hosting y el DNS sigue pudiendo cambiar lo que ven los usuarios.

• Hosting/cloud: que te añadan como admin/owner de más alto nivel primero, luego mueve la facturación a un método de pago de la empresa y después elimina al freelancer.
• Equipos/workspaces: donde la plataforma lo permita, mueve proyectos a un equipo u org de la empresa para que el acceso no dependa de una persona.
• Dominio/registrador: transfiere el dominio a una cuenta que controlas y confirma que puedes editar registros DNS. También confirma quién controla SSL/TLS y las renovaciones.
• Correo de la empresa: cambia los inicios de sesión de la plataforma fuera del correo del freelancer y hacia un buzón controlado por la empresa.
• 2FA: reconfigura la 2FA a tus dispositivos o a un método gestionado por la empresa. Regenera códigos de respaldo y guárdalos de forma segura.

Chequeo de cordura tras las transferencias: abre una ventana de incógnito y verifica que tu cuenta admin puede (1) cambiar DNS, (2) cambiar facturación y (3) desplegar un cambio de prueba. Si algo de eso aún depende del freelancer, no has terminado.

Cuando el freelancer no responde: trabajar con el soporte de las plataformas

Si el freelancer no contesta, el soporte es tu siguiente palanca. El objetivo es probar que eres el propietario legítimo y mover el activo a una cuenta que controles.

Escribe una historia corta y consistente que reusarás en cada ticket. Mantén los hechos: qué es el proyecto, qué cuentas están bloqueadas, quién las creó, cuándo pagaste y qué cambio pides.

Qué suele pedir soporte

La mayoría de plataformas solicita las mismas categorías de pruebas:

• Prueba de pago (facturas, recibos, extractos)
• Prueba de negocio (registro de la empresa, prueba de que representas al negocio)
• Prueba de control de dominio (capacidad para añadir un registro DNS, acceso al correo de facturación, historial de pagos al registrador)
• Pistas de cuenta (nombres de usuario, nombres de org, nombres de repo, nombres de dominio, fechas aproximadas de creación)
• Comprobaciones de seguridad (dirección de facturación, últimos 4 dígitos de la tarjeta, PIN de soporte si lo tienes)

Cuando soporte responda con preguntas de seguimiento, contesta en un mensaje claro con adjuntos etiquetados (por ejemplo: “Adjunto A - factura”).

Qué solicitar (y qué evitar)

Pide el cambio más pequeño que te dé control. Muchos equipos de soporte no “entregan una cuenta entera” sin pruebas muy sólidas.

Peticiones que suelen ser realistas:

• Añadir tu correo como owner/admin en la org, repo o proyecto de hosting
• Cambiar el correo de la cuenta a una dirección controlada por la empresa
• Ayudar a migrar repos, proyectos o suscripciones a una cuenta nueva que crees
• Restablecer o eliminar 2FA solo como parte de un proceso verificado de titularidad

Evita solicitudes vagas como “devuélvanme la cuenta”. Mejor: “Por favor, añadan mi correo como admin para que pueda transferir la titularidad y rotar credenciales.”

Los tiempos varían. Algunos hosts responden en horas. Los registradores de dominio y los equipos de identidad pueden tardar días y varios intercambios. Planea 2-5 días hábiles, abre un ticket por plataforma y mantén actualizado tu registro de incidentes.

Errores comunes que hacen la recuperación más difícil

La mayor trampa es pensar “el sitio está arriba, así que estamos bien”. Un prototipo puede funcionar y aún ser inseguro. Las builds hechas a prisas suelen incluir claves API expuestas, reglas de login débiles o rutas admin que nunca se aseguraron. Si esperas hasta después de una brecha para arreglar la titularidad, el mismo problema de acceso se convierte en un incidente de seguridad.

Otro error es tratarlo como un problema de contraseña. Si el freelancer creó todo con su correo, conseguir “la contraseña correcta” no te da control real. Necesitas transferencia de titularidad: rol admin, propietario de facturación, control del registrante del dominio y 2FA que tú gestiones.

Los equipos también tropiezan con secretos. La gente cambia la contraseña del hosting pero olvida los tokens que quedan en tres sitios distintos. Antes de mover nada, identifica dónde existen credenciales:

• Ajustes de CI/CD (pipelines de build, deploy keys, tokens de servicio)
• Variables de entorno del hosting (prod y preview)
• El propio repo (archivos de configuración, commits antiguos, .env de muestra)
• Código cliente (todo lo enviado al navegador es, en efecto, público)
• Dashboards de terceros (pagos, correo, analytics, tracking de errores)

Se suelen omitir backups porque todos quieren “solo transferir”. Entonces se sobrescriben registros DNS, se reemplaza una base de datos o se pierde el historial del repositorio durante una exportación apresurada. Toma una snapshot limpia primero: repo, base de datos, buckets de almacenamiento y configuración DNS actual.

Finalmente, no hagas movimientos que provoquen bloqueos sin plan. Revocar accesos o cambiar correos demasiado pronto puede causar despliegues fallidos o una reacción defensiva. Muévete en un orden controlado: confirma que puedes desplegar y revertir, luego transfiere la titularidad y después rota claves.

Lista rápida: ¿estás a salvo ya?

"A salvo" significa que el negocio puede seguir funcionando aunque el freelancer desaparezca hoy.

Empieza por el mayor punto único de fallo: tu dominio. Si no puedes entrar al registrador, no controlas realmente tu producto. Los cambios DNS pueden dejar tu sitio y correo fuera de servicio rápidamente.

Usa esto como chequeo práctico:

• Control del dominio: puedes iniciar sesión en el registrador, editar DNS y el dominio no puede transferirse sin tu aprobación.
• Cobertura admin: cada plataforma crítica tiene al menos dos admins de confianza (no inicios de sesión compartidos).
• Identidad de la empresa: el correo de facturación, el correo de recuperación y la 2FA están atados a buzones y dispositivos controlados por la empresa.
• Seguridad de los datos: tienes un clon reciente del repo, una exportación de la base de datos y una copia segura de las variables de entorno necesarias.
• Seguridad de despliegue: puedes redeployar desde tu propia cuenta y sabes exactamente dónde corre la app en vivo y quién puede acceder.

Si algún ítem está en “no sé”, trátalo como “no”.

Una prueba simple: escribe el login cuya pérdida dejaría a la empresa parada. Para muchos equipos, es el registrador, el admin del correo principal y el owner del host de código. Arregla esos primero.

Escenario de ejemplo: una fundadora que intenta recuperar control en 2 días

Maya es una fundadora en solitario. Un freelancer construyó su MVP y lo lanzó rápido: un repositorio de GitHub (backend y frontend en uno), una base de datos gestionada en un proveedor de hosting y un dominio apuntando a un frontend simple. Funciona, pero el freelancer creó todo con su propio correo y Maya no tiene acceso admin en ningún lado.

Hora 0 a 2 (estabilizar): Maya reduce el riesgo primero. Hace capturas de pantalla de todo lo que puede (emails de facturación, facturas, credenciales antiguas, avisos de renovación de dominio). Cambia contraseñas en las cuentas que controla (correo de la empresa, portal de pagos) y pausa pagos automáticos ligados a servicios a los que no puede acceder.

Al final del Día 1 (recoger pruebas y pedir transferencia): Maya reúne pruebas de que el proyecto es suyo: el contrato firmado, recibos de pago, el sitio público con su marca y mensajes del freelancer sobre la puesta en marcha. Envía una solicitud clara: transferir el repo a su org de GitHub, añadirla como dueña de facturación en el hosting y mover el dominio a su cuenta de registrador.

Qué puede hacer inmediatamente vs qué depende de otros:

• Inmediatamente: recolectar pruebas, asegurar el correo de la empresa, listar servicios, preparar nuevas cuentas dueñas (org de GitHub, hosting, registrador).
• Depende del contratista: iniciar transferencias, añadir a Maya como owner/admin, proporcionar códigos de recuperación de 2FA o eliminar dispositivos antiguos.
• Depende del soporte: recuperación forzada de dominio, disputas de repos o comprobaciones de identidad cuando el freelancer desaparece.

Día 2 (rotar secretos y crear un camino limpio): Una vez que Maya tiene algún acceso, rota todo lo que podría haberse copiado: contraseñas de BD, claves API, secretos de auth, tokens de despliegue. Si no puede obtener acceso, ejecuta un plan alternativo: crea cuentas nuevas, restaura desde backups (o exporta lo que puedas desde la app en vivo) y redeploya en infraestructura que poseas. Luego escribe un mapa simple de titularidad: quién posee GitHub, hosting, dominio, base de datos y 2FA.

Próximos pasos: asegurar la titularidad y evitar que pase de nuevo

Una vez recuperes el control, no te quedes en “funciona”. Haz que sea difícil que tu producto vuelva a quedar detrás del correo de una persona.

Crea una identidad raíz controlada por la empresa que sea la propietaria de lo esencial. Usa un buzón controlado por la empresa (a menudo un mailbox administrativo compartido en tu dominio) como correo de facturación y recuperación para el registrador de dominios, la org de GitHub y las cuentas de hosting. Que sea aburrido y estable. No debería pertenecer a un freelancer ni depender del correo personal de un empleado.

Establece reglas simples que casen con cómo trabajan los equipos reales:

• Mantén al menos dos owners/admins verificados en cada cuenta crítica.
• Guarda códigos de recuperación y licencias en un gestor de contraseñas del equipo.
• Exige que los contratistas usen sus propias cuentas como miembros, nunca como propietarios.
• Usa una lista de verificación de entrega al final del contrato (qué construyeron, dónde corre, cómo desplegar, dónde están los secretos).
• Ejecuta un simulacro trimestral de acceso: confirma que puedes iniciar sesión y rotar un token sin el constructor original.

Si tu app se construyó con rapidez usando herramientas AI o se ensambló a base de prototipos, planifica tiempo para limpiar antes de tratarla como producción. Las correcciones de titularidad son solo la mitad del trabajo. El código desordenado y los despliegues apresurados a menudo ocultan problemas como secretos codificados, flujos de auth rotos o consultas inseguras.

Un enfoque práctico: congela cambios por un día, mueve los secretos a variables de entorno correctas o a un almacén de secretos, y escribe una única fuente de verdad para el despliegue (dónde está hosteada, cómo desplegar, qué significa “saludable”). Incluso una página de notas ahorra semanas después.

Si quieres ayuda externa, FixMyMess (fixmymess.ai) se especializa en tomar prototipos generados por IA y convertirlos en apps listas para producción. Una auditoría rápida también puede revelar minas comunes en la entrega, como secretos expuestos, autenticación rota y configuraciones de despliegue que solo funcionan desde la máquina del constructor original.

Trata la titularidad de cuentas como parte del producto, no como papeleo. Haz seguimiento de accesos, propietarios y pasos de recuperación igual que haces con bugs y features, para que ninguna persona pueda bloquear el negocio otra vez.