Guías de seguridad
Git autoalojado vs GitHub: ¿cuál es realmente más seguro?
Qué elimina de verdad un servidor Git autoalojado (la exposición pública accidental), qué asumes a cambio (parches, copias de seguridad, escaneo de secretos) y cómo hacerlo más seguro que GitHub — desde la perspectiva operativa de este sitio.
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 acompañado de su precio
Este sitio ejecuta un servidor Git autoalojado. Pero la razón no es solo "la exposición accidental da miedo" — es la separación del radio de la explosión: un servicio comprometido no debe encadenarse 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 rellenar el hueco que dejó el manejo que desapareció.
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. Qué asumes a cambio (los puntos ciegos)
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
- Si desaparece, desaparece — prepara 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 red. 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 separación del radio de la explosión
- 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, el autoalojamiento es un contrato para 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 propaga 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 se rellena cada hueco que dejó el manejo perdido lo es. Solo haciendo ambas cosas el autoalojamiento es seguro.
Sigue leyendo
FAQ
Q¿Es un servidor Git autoalojado más seguro que GitHub?
No de forma inherente. El autoalojamiento elimina estructuralmente la clase de 'exposición pública accidental', pero las responsabilidades que GitHub manejaba por ti — parchear el servidor, copias de seguridad, detección de secretos pre-commit — pasan a ti. Es una buena decisión si pagas ese precio, y peor que GitHub si lo descuidas.
Q¿Qué aleja a la gente de GitHub por miedo?
Sobre todo dos incidentes: un repositorio que debía ser privado pero quedó público, y una clave de API enviada a un repositorio público y explotada en minutos. Los repositorios públicos los rastrean continuamente bots de escaneo automatizado, así que un secreto filtrado se convierte en daño real de inmediato. El autoalojamiento elimina por completo esa superficie pública.
QSi autoalojo, ¿cuál es el mínimo que debo hacer?
1) un hook pre-commit que detecte secretos (gitleaks, etc.), 2) parchear y minimizar el servidor Git y el SO, 3) copias de seguridad externas con restauración probada, 4) claves separadas, sin root, privilegio mínimo, 5) ejecutar tú mismo el monitoreo de CVE de dependencias (osv-scanner / pnpm audit). Solo entonces es cierto el 'más seguro que GitHub'.