Cómo autoalojar GitLab CE en un VPS

Es viernes por la tarde, la pull request de tu equipo está pendiente de revisión y tu portátil suena con un mensaje conocido: GitHub vuelve a tener problemas.

Quizá las Actions se han quedado atascadas.

Quizá git push devuelve un error 500 por tercera vez este mes.

El hilo del chat de tu equipo ya tiene ocho mensajes.

La primera vez que pasa, te ríes. La segunda, alguien comparte la página de estado de GitHub y os vais todos a por un café. La tercera, normalmente justo antes de una ventana de lanzamiento, alguien por fin formula la pregunta en voz alta: ¿Y si montamos el nuestro?

Para la mayoría de los equipos, la respuesta sincera es no. GitLab.com Free cubre de sobra a los equipos pequeños, y el coste operativo de mantener tu propio servidor de control de versiones no es cero.

Es el tipo de compromiso que solo asumes por una buena razón.

Quizá tu equipo tenga una de esas razones: un contrato con un cliente que prohíbe el SaaS de terceros, un requisito de cumplimiento normativo o una factura de licencias por usuario que empieza a parecer absurda. En ese caso, autoalojar GitLab CE es la opción más limpia que tienes. Es de código abierto, funciona en un solo VPS y, una vez ajustado, su mantenimiento lleva alrededor de una hora al mes.

En DreamHost hemos alojado innumerables servidores autogestionados y vemos un patrón que se repite. Los desarrolladores que tienen éxito con GitLab autoalojado eligen el plan adecuado desde el principio y preparan bien el Secure Shell Protocol (SSH) y el Domain Name System (DNS). Después, resisten la tentación de seguir trasteando cuando todo está estable.

¿Por qué autoalojar GitLab en lugar de usar GitLab.com?

Autoalojas GitLab cuando GitLab.com o GitHub.com no pueden cubrir tus necesidades de privacidad, cumplimiento normativo o control de costes. Para la mayoría de los demás equipos, la opción alojada compensa más.

Hay tres razones reales que resisten un análisis serio:

1. Privacidad y soberanía de los datos: tu código fuente vive en una infraestructura que tú gestionas y parcheas según tu propio calendario. Sin acceso de terceros, sin plataforma compartida y sin que el alcance de una brecha vaya más allá de tu propio servidor.
2. Cumplimiento normativo: los sectores regulados, como la sanidad, las finanzas o la administración pública, suelen necesitar control sobre la residencia de los datos. GitLab CE autoalojado es la forma más sencilla de mantener el código dentro de un perímetro controlado.
3. Control de costes a escala: GitLab.com cobra por usuario activo. Según la página de precios de GitLab, Premium cuesta 29 $ por usuario al mes, mientras que el precio de Ultimate solo está disponible bajo petición. Un equipo de 50 personas en Premium supone 17.400 $ al año sin contar complementos. Un VPS autogestionado más una hora de mantenimiento mensual suele costar menos.

Si tu equipo es de dos personas y no tiene razones de privacidad ni de cumplimiento normativo, la respuesta correcta es el plan gratuito de GitLab. (Sí, sabemos que suena raro viniendo de una empresa de hosting).

Al autoalojar, cambias una factura mensual de SaaS por tiempo operativo continuo. Solo merece la pena si tienes una buena razón para dar el paso.

Aquí tienes cuándo tiene sentido esta opción y cuándo no:

GitLab Community Edition es gratuito con una licencia de código abierto de tipo MIT. No hay límite de usuarios, ni funciones básicas bloqueadas, ni avisos para que pagues más. Toda la plataforma es tuya para gestionarla.

¿Cuáles son los requisitos de hardware de GitLab CE?

GitLab CE tiene umbrales de hardware claros, y acertar con ellos marca la diferencia entre una instalación ágil y otra que se arrastra usando memoria swap (espacio en disco que tu sistema operativo usa cuando se llena la RAM).

Según los requisitos oficiales de instalación de GitLab, el dimensionamiento se expresa en peticiones por segundo y no en niveles fijos por usuario. La referencia publicada es de 8 vCPU y 16 GB de RAM para hasta 1000 usuarios (unas 20 peticiones por segundo). Los equipos más pequeños pueden funcionar con menos, hasta un mínimo documentado de 2 GB de RAM más 1 GB de swap para evaluación, aunque el rendimiento se resiente por debajo de 4 GB.

Una instalación nueva de GitLab consume entre 4 y 6 GB en reposo. En cuanto empiezan a ejecutarse los trabajos de CI/CD, la memoria se dispara rápido. Así que planifica con margen… o prepárate para la lentitud.

En cuanto al almacenamiento, la referencia oficial de GitLab es de 40 GB más el tamaño de los repositorios, pero en la práctica 50 GB es un punto de partida más seguro. Los repositorios crecen y los artefactos de compilación se acumulan. NVMe, un tipo de almacenamiento de estado sólido más rápido, marca una diferencia notable en las operaciones de Git y en las lecturas de la caché de CI.

Así encajan esos umbrales con los niveles de hosting VPS de DreamHost:

El plan adecuado para la mayoría de los equipos que ejecutan pipelines de CI/CD reales es Stack 32, el único Stack que cumple la referencia de 8 vCPU de GitLab. Stack 16 tiene la memoria, pero la mitad de núcleos, así que considéralo un tamaño de prueba. Parece excesivo hasta que ves arrancar la primera compilación y Sidekiq, Postgres y un runner se disparan a la vez*.*

16 GB de RAM te dan margen suficiente para el conjunto de servicios de GitLab (unos 4 a 6 GB en reposo en una instalación por defecto). También permiten que un par de workers de CI (de 1 a 2 GB cada uno) funcionen a pleno rendimiento a la vez sin que nadie en el chat del equipo lo note.

¿Cómo preparas tu VPS antes de instalar GitLab?

Dedica 10 minutos a la preparación: lo agradecerás la primera vez que reinicies. Solo tienes que seguir estos pasos:

1. Aprovisiona el VPS: elige Ubuntu 24.04 LTS. Es compatible con los paquetes oficiales Omnibus de GitLab (el instalador todo en uno que distribuye GitLab) y tiene por delante años de actualizaciones de seguridad gratuitas.
   
2. Apunta un dominio a la IP del servidor: crea un registro A (el tipo de registro DNS que asocia un dominio a una dirección IP) y deja que se propague al menos entre 15 y 30 minutos antes de instalar. Sin él, la configuración automática de SSL fallará porque la autoridad de certificación no tendrá dónde validar.
   
3. Actualiza los paquetes: conéctate al VPS con ssh root@your-server-ip y ejecuta sudo apt update && sudo apt upgrade -y.
   
4. Instala las dependencias: ejecuta sudo apt install -y curl openssh-server ca-certificates perl postfix. El paquete postfix es un servidor de correo que gestiona el correo saliente para que GitLab pueda enviar notificaciones de merge requests y restablecimientos de contraseña.
   Cuando el instalador te pregunte por la configuración del correo, elige Internet Site y usa tu dominio. Así GitLab empezará a enviar correo de inmediato.
   Para producción: prescinde de postfix local y configura en su lugar un relay SMTP en gitlab.rb. Las IP de los VPS suelen aparecer en listas negras de spam, y los correos de restablecimiento de contraseña enviados a través de postfix local a menudo acaban en spam. SendGrid, Mailgun y otros relays SMTP similares funcionan bien. Consulta la documentación de configuración SMTP de GitLab.
   
5. Abre los puertos necesarios: configura un cortafuegos con UFW (la herramienta de cortafuegos integrada en Ubuntu) y permite los puertos 80, 443 y 22.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

¿Cómo instalas GitLab CE en Ubuntu con el paquete Omnibus?

Añade el repositorio de GitLab CE:

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Después, instala GitLab CE con tu dominio como URL externa:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Configurar https:// aquí indica a GitLab que solicite automáticamente un certificado de Let’s Encrypt durante la instalación, siempre que los puertos 80 y 443 estén abiertos y el DNS apunte correctamente. Si alguna de esas dos cosas no está lista, la instalación se completa pero el SSL falla, y te pasas la siguiente media hora solucionando algo que en realidad no está roto.

A continuación, espera al paso de reconfiguración.

GitLab ejecuta gitlab-ctl reconfigure (el comando que aplica cualquier cambio en la configuración de GitLab) automáticamente al final de la instalación. Tarda entre 5 y 10 minutos. Y sí, el paso de reconfiguración de verdad tarda tanto.

Obtén la contraseña inicial de root:

sudo cat /etc/gitlab/initial_root_password

Este archivo se genera automáticamente y se elimina a las 24 horas, así que copia la contraseña e inicia sesión. Abre tu dominio en un navegador, inicia sesión como root y cambia la contraseña de inmediato.

Por último, verifica la instalación.

Desde la pantalla de bienvenida de GitLab, crea un proyecto de prueba. Haz push de un commit desde tu máquina local. Si el push funciona y el archivo aparece en la interfaz web, la instalación está en buen estado.

Si el paso de reconfiguración se queda colgado, revisa tail -f /var/log/gitlab/reconfigure/*.log. Ahí es donde está el error real.

¿Cómo proteges una instancia de GitLab autoalojada?

GitLab viene con valores por defecto razonables, pero están pensados para un servidor comunitario abierto, no para la instancia privada de tu equipo. Dedica una hora a esto.

1. Desactiva el registro abierto. El registro abierto está activado por defecto. En el Admin Area, ve a Settings > General > Sign-up restrictions y desmarca la casilla Sign-up enabled. Si no, cualquiera con la URL puede crear una cuenta.
2. Activa la autenticación de dos factores. Ve a Admin Area > Settings > General > Sign-in restrictions y exige la 2FA a todos los usuarios. Reduce el periodo de gracia de las 48 horas predeterminadas a 8 horas.
3. Restringe la creación de proyectos. Configura Default Project Creation como Maintainers o No one, según lo restrictivo que quieras que sea.
4. Verifica la renovación del SSL. GitLab renueva automáticamente los certificados de Let’s Encrypt por defecto. Para confirmarlo, ejecuta sudo gitlab-ctl renew-le-certs una vez y revisa la salida.
5. Protege el SSH del propio VPS. Desactiva el inicio de sesión de root con contraseña, permite solo la autenticación con clave SSH y, si puedes, saca el SSH del puerto 22. Un servidor Git autoalojado es tan seguro como la máquina que lo sostiene.

Si quieres una versión más detallada, GitLab ha publicado una guía de refuerzo de seguridad que cubre autenticación, cifrado y ajustes de la instancia. Léela una vez, aplica lo que encaje con tu modelo de amenazas y sigue adelante.

¿Cómo haces copias de seguridad y restauras una instancia de GitLab autoalojada?

GitLab incluye una herramienta de copias de seguridad integrada. La primera vez que la necesites, te alegrarás de haberla configurado.

Crea una copia de seguridad:

sudo gitlab-backup create

Esto deja un tarball en /var/opt/gitlab/backups. Prográmalo a diario con cron y una retención de siete días. Ejecuta sudo crontab -e y añade estas dos líneas:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

La opción CRON=1 suprime la salida de progreso para que no llene de ruido los registros de cron.

Consejo: la copia de seguridad de datos no incluye /etc/gitlab/gitlab-secrets.json ni /etc/gitlab/gitlab.rb.

Esos archivos contienen la clave de cifrado de la base de datos, las semillas de la autenticación de dos factores y las variables de CI/CD. Los secretos de configuración no forman parte de la copia de seguridad habitual y deben guardarse por separado. Si restauras los datos sin el archivo de secretos, las cuentas con dos factores dejan de funcionar y las variables cifradas se convierten en basura. Y tú te pasas una larga noche averiguando por qué.

Añade esto al mismo cron job:

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Una copia de seguridad solo puede restaurarse en la misma versión y edición (de CE a CE, no de CE a EE) de GitLab en la que se creó.

Actualiza con cuidado: no restaures una copia antigua en un GitLab recién instalado sin antes bajar la instalación a la versión correspondiente.

Prueba el proceso de restauración al menos una vez. Una copia de seguridad que nunca has probado no es más que un archivo.

¿De verdad compensa autoalojar GitLab para tu equipo?

Para la mayoría de los equipos, autoalojar GitLab es una decisión de control. A veces las cuentas salen, pero el motivo por el que la gente se queda con el autoalojamiento rara vez es el ahorro.

Este es el coste real en tiempo al mes de una instalación para un equipo pequeño:

• ~30 minutos de parches – actualizaciones con apt, versiones menores de GitLab
• ~15 minutos de verificación de copias de seguridad – no te fíes de una copia que no hayas restaurado
• ~15 minutos de revisión de capacidad – uso de disco, margen de RAM
• ~2x si el CI/CD se ejecuta en la misma máquina – un runner con mucha actividad puede duplicar la carga

Eso supone alrededor de una hora al mes en una semana tranquila, o dos en una ajetreada.

A unos 150 $ la hora, 12 horas de tiempo operativo suponen unos 1800 $, aproximadamente cinco licencias Premium de GitLab.com.

Un caso práctico de Mad Devs explica cómo su equipo ahorra más de 10.000 $ al año usando GitLab CE autoalojado en lugar de pagar licencias Premium. El ahorro solo se materializa cuando el equipo es lo bastante grande como para que las licencias por usuario dominen el presupuesto.

Dicho esto, autoalojar es la opción equivocada para:

• Equipos de dos o tres personas sin requisitos de cumplimiento normativo. Con GitLab.com Free tienes suficiente. El tiempo operativo supera lo que te ahorras.
• Equipos en los que nadie se maneja con soltura en la línea de comandos. Con soltura no significa a nivel de administrador de sistemas. Significa que puedes leer los errores de /var/log/gitlab sin entrar en pánico.
• Equipos cuyo mayor obstáculo es contratar, no las herramientas. El autoalojamiento le resta atención al producto. Si lo que te limita es la velocidad de desarrollo del producto, lo acertado es una solución alojada.

Entonces, ¿cuándo tiene sentido el autoalojamiento? Estos son algunos escenarios:

• Sectores regulados con requisitos explícitos de residencia de datos o de cadena de custodia
• Equipos de la UE o el Reino Unido preocupados por la soberanía de un código alojado en EE. UU.
• Equipos de más de 30 personas en los que las licencias por usuario se comen el presupuesto
• Contratos con clientes que prohíben usar SaaS de terceros para el código fuente

Si tu motivo es que GitHub cobra por usuario, probablemente salgas ganando. Si tu motivo es que quieres sentir que tienes el control, puede que la realidad operativa te resulte menos romántica de lo que esperabas.

¿Deberías ejecutar los runners de CI/CD de GitLab en el mismo VPS?

Para pruebas, sí. Para producción, no.

Un runner de CI en la misma máquina le roba memoria y CPU a la interfaz de GitLab. El síntoma clásico es «GitLab va lento a las 9 de la mañana», que suele deberse a una compilación que arranca el primer pipeline del día y deja sin recursos al frontend web. La configuración más limpia es un VPS independiente para el runner (un Stack 8 por runner), registrado en la instancia de GitLab a través de la red.

Si no te queda más remedio que mantener los runners en la misma máquina, usa Stack 32 y deja margen para los trabajos.

Según los requisitos del sistema para el runner de GitLab, el proceso del runner en sí es ligero. Las cargas de trabajo que ejecuta no lo son, y comparten la CPU y el disco de la máquina con todo lo demás que hace GitLab.

¿Listo para dar el salto?

Volvamos al chat del equipo de aquel viernes por la tarde.

Si GitHub se pone en amarillo y tu equipo vuelve a reírse y se va a por un café, no pasa nada.

Pero ¿y si las caídas de GitHub empiezan a parecer algo serio?

¿Quizá pone en riesgo un contrato con un cliente? ¿Sale a relucir en una auditoría de cumplimiento? ¿O la factura de licencias por usuario por fin ha cruzado la línea?

Autoalojar GitLab CE pasa a ser una opción totalmente razonable. Solo necesitas un VPS, un dominio, una instalación con Omnibus y una hora de refuerzo de seguridad.

La próxima vez que la página de estado de GitHub se ilumine, tu código seguirá subiéndose sin problemas.

Preguntas frecuentes sobre autoalojar GitLab