Para: desarrolladores independientes y pequeños operadores recelosos del "repositorio público accidental" de GitHub y de los incidentes de fuga de secretos, que sopesan si ejecutar un servidor Git autoalojado (bare git, o Gitea/Forgejo/GitLab). Aquí no hay pasos de ataque — solo la decisión de cuál es más seguro para tu configuración.
La visión de este sitio: el autoalojamiento solo funciona si asumes lo que hacía GitHub
Este sitio ejecuta un servidor Git autoalojado. Pero la razón no es solo "la exposición accidental da miedo" — es separar el alcance del impacto: un servicio comprometido no debe arrastrar a los demás. Y como autoalojamos, siempre incluimos copias de seguridad externas a un servidor aparte, nunca poner secretos en git, y monitoreo automatizado de CVE de dependencias. La seguridad del autoalojamiento no viene de "no usar GitHub" sino de hacer tú mismo el trabajo que antes hacía GitHub.
1. Qué elimina de verdad el autoalojamiento
Tu preocupación tiene una base válida. Los clásicos "incidentes públicos" de GitHub simplemente no pueden ocurrir en un servidor autoalojado.
Los repositorios públicos los rastrean continuamente bots de escaneo automatizado. Envía por error un .env o una clave de API y los bots la recogen antes de que un humano se dé cuenta — explotada en minutos es lo habitual (casos reales → una clave filtrada vía un repositorio público y facturada por fraude · un .env entero expuesto). El autoalojamiento elimina esa superficie pública. "Debía ser privado pero estaba público", "un secreto que creíste haber borrado persistiendo en un fork público" — esas clases no pueden ocurrir por diseño. Eso no es un consuelo vago; es una ventaja real.
2. El trabajo que asumes al autoalojar
Este es el quid. GitHub manejaba mucha defensa por ti por defecto, fuera de la vista. Autoaloja y esas defensas no existen salvo que las construyas.
GitHub manejaba esto
- Bloquea commits de secretos (protección de push)
- Alertas automáticas de CVE de dependencias (Dependabot)
- Operación del servidor, parches, TLS
- 2FA, acceso granular, registros de auditoría
- Alta disponibilidad, copias de seguridad redundantes
Ahora es tu trabajo
- Añadir un hook de detección de secretos pre-commit
- Ejecutar tú mismo el monitoreo de CVE de dependencias (cron)
- Parchear las propias vulnerabilidades del servidor Git
- Gestión de claves = en la práctica todo el control de acceso
- Los datos perdidos no se recuperan salvo que prepares una restauración
Dos son especialmente fáciles de pasar por alto. Primero, una paradoja: la fuga de secretos que más temes es algo que GitHub en realidad detiene por ti, por máquina. La protección de push de GitHub rechaza los commits que contienen lo que parece una clave de API. Un git autoalojado simple no tiene esa comprobación. La exposición accidental desaparece, pero el commit accidental no — así que si autoalojas, un hook de secretos pre-commit es obligatorio.
Segundo, el propio servidor Git se convierte en objetivo. Servidores ricos en funciones como GitLab han tenido múltiples vulnerabilidades serias (ejecución remota de código sin autenticar, es decir, de clase RCE), y un servidor autoalojado sin parchear se convierte en la vía de entrada. Más funciones, más superficie de ataque. El bare git simple + SSH tiene la menor superficie; GitLab/Gitea son cómodos pero añaden la carga de perseguir parches tú mismo.
3. Cómo hacer el autoalojamiento más seguro que GitHub
El conjunto mínimo que hace el autoalojamiento genuinamente — no cosméticamente — seguro. Solo con esto es cierto el "más seguro que GitHub".
Detén los secretos antes del commit
Minimiza y parchea el servidor Git
Copias de seguridad externas + una restauración probada
Claves separadas, privilegio mínimo, sin root
Ejecuta tú mismo el monitoreo de CVE de dependencias
4. ¿Cuál deberías elegir?
El autoalojamiento no es "profesional" y GitHub no es "aficionado". Decide en función de si puedes seguir operándolo.
El autoalojamiento encaja (si cumples el listón)
- quieres eliminar la propia superficie de exposición pública
- puedes seguir parcheando y haciendo copias de seguridad del servidor
- no quieres que un tercero tenga tu código / quieres limitar el alcance del impacto
- puedes adoptar el hook de secretos y el monitoreo de dependencias como un conjunto
GitHub puede ser más seguro
- sin capacidad para seguir parcheando/respaldando → un autoalojamiento descuidado es lo más peligroso
- quieres apoyarte en la protección de push / Dependabot de defensa automática
- no puedes proporcionar disponibilidad / copias de seguridad redundantes por ti mismo
- puedes gestionar rigurosamente los repositorios privados (la exposición es prevenible con disciplina)
En resumen, autoalojar significa asumir el trabajo que GitHub hacía por ti. Asúmelo y hazlo, y eliminas una gran clase de incidentes. Asúmelo y descuídalo, y puedes terminar peor que con GitHub: un servidor sin parchear, un secreto mal enviado y una copia de seguridad que no puedes restaurar. Y el envenenamiento de la cadena de suministro (como la puerta trasera de xz-utils) se defiende con monitoreo continuo de dependencias dondequiera que viva tu código.
Qué hace este sitio
Este sitio ejecuta un servidor Git autoalojado (bare git simple + SSH) y lo conecta de modo que cada push se copia también a una copia de seguridad en un servidor aparte. Los secretos (claves, contraseñas, cadenas de conexión) nunca van a git ni a la documentación, y el monitoreo de CVE de dependencias se ejecuta vía pnpm audit antes de cada despliegue y a diario. "No usar GitHub" no es el objetivo — eliminar la clase de exposición accidental mientras haces tú mismo todo el trabajo que antes hacía GitHub lo es. Solo haciendo ambas cosas el autoalojamiento es seguro.
Sigue leyendo
- Glosario: archivos .env y secretos
- Incidentes: una clave filtrada vía un repositorio público · un .env entero expuesto
- Stacks: monitorea por máquina los CVE de dependencias con osv-scanner · no quedarse atrás con los CVE
- Cadena de suministro: cuando un solo npm install vacía tus credenciales (cómo los repositorios privados acaban copiados en público y por qué decide el alcance del token)