DevOps de código abierto a escala: alojar GitLab por tu cuenta
El código fuente es el único activo que casi todas las empresas tecnológicas coinciden en considerar crítico, y también el que la mayoría guarda en una infraestructura que no posee, en una jurisdicción que no eligió y bajo un contrato que no leyó con atención. Normalmente ese arreglo funciona. Aun así conviene saber cuánto cuesta la alternativa, porque GitLab lleva más de una década haciendo que alojar todo el ciclo de desarrollo sea realmente practicable.
Es además un producto cuyo nivel gratuito es más generoso y cuya carga operativa es más pesada de lo que casi nadie espera. Ambas cosas hay que entenderlas antes de comprometerse, así que esta guía explica qué es de verdad GitLab autoalojado, qué te da realmente el nivel gratuito y los tres problemas operativos que concentran casi todo el dolor.
Qué es GitLab
No es un alojamiento de Git con extras atornillados encima. Una aplicación en Rails, PostgreSQL, Redis, Gitaly para el almacenamiento de repositorios, Sidekiq para tareas en segundo plano y un registro de contenedores, empaquetados juntos como un solo sistema que cubre control de versiones, revisión de código, seguimiento de incidencias, CI/CD, registros de paquetes y contenedores, análisis de seguridad y despliegue.
Esa amplitud es todo el argumento. GitHub más Actions más Dependabot más un registro de paquetes más un gestor de proyectos da un conjunto de funciones comparable, ensamblado a partir de piezas. GitLab es una aplicación con un modelo de permisos y una base de datos. Eso es exactamente lo que quieres o más de lo que necesitas, y cuál de las dos cosas sea depende de cuánto del ciclo pienses ejecutar realmente en un mismo sitio.
El hecho arquitectónico importante es el mismo que en autoalojar la analítica con Matomo, la automatización de marketing con Mautic o el chat de equipo con Mattermost: corre donde tú lo pongas. Tus repositorios, tus registros de CI, tus artefactos, tu base de datos.
El panorama de licencias, dicho sin rodeos
Esto es genuinamente confuso y merece precisión, porque la confusión va en sentido contrario a lo que la gente espera.
Hay dos distribuciones del código. La Community Edition está bajo licencia MIT. La Enterprise Edition tiene su propia licencia, más restrictiva, que cubre el directorio ee/ del repositorio. Hasta aquí suena al modelo de núcleo abierto de siempre.
Lo que sorprende: el paquete de Linux que instala casi todo el mundo es la compilación de Enterprise Edition, y sin clave de licencia aplicada funciona en el nivel Free, comportándose como la Community Edition. No estás ejecutando la distribución bajo MIT salvo que hayas elegido deliberadamente el paquete CE. En la práctica rara vez importa, pero si tu motivo para autoalojar es una política estricta de código abierto y no el control de los datos, importa muchísimo, y casi nadie lo comprueba.
Los niveles comerciales son Free, Premium a 29 dólares por usuario y mes con facturación anual, y Ultimate con precio a medida. Premium añade CI/CD avanzada, mejor gestión de proyectos y soporte prioritario. Ultimate añade el paquete de seguridad y cumplimiento: pruebas de seguridad de aplicaciones, seguridad de la cadena de suministro, análisis de dependencias. Ambos niveles de pago incluyen ya GitLab Credits para las funciones de IA, 12 dólares por usuario y mes en Premium y 24 en Ultimate.
Y aquí está el dato que cambia el cálculo para la mayoría de los equipos, y el inverso exacto de la situación de Mattermost: el nivel Free en autoalojado no tiene límite de usuarios. El tope de cinco usuarios del que la gente ha oído hablar solo se aplica a los grupos privados en GitLab.com. En autoalojado, Free te da usuarios ilimitados, control de versiones, CI/CD y registros, y tú pones el almacenamiento y los runners. Una organización de cien ingenieros puede funcionar entera sobre él.
Lo que cedes es el análisis de seguridad, los informes de cumplimiento, las reglas de aprobación avanzadas y el soporte. Si te aplica el Reglamento de Ciberresiliencia y quieres el análisis de dependencias y la generación de SBOM integrados en tus pipelines en lugar de ensamblados desde herramientas separadas, esa es una conversación de Ultimate. Para casi todos los demás equipos, Free no es una prueba. Es una respuesta permanente y viable.
La instalación
Un despliegue pequeño
GitLab pesa más de lo que parece. La base documentada para un solo nodo son 8 vCPU y 16 GB de RAM, y a diferencia de la mayoría de los mínimos de fabricante esa cifra es honesta y no optimista. Puede apretarse en 8 GB, pero se nota, y conviene desactivar el swap, porque hacer que esta aplicación tire de intercambio es peor que no tener la memoria.
PostgreSQL es la única base de datos soportada. Qué versión depende de tu versión de GitLab: 17.x quiere PostgreSQL de 14.14 a 16.x, 18.x quiere de 16.5 a 17.x, y 19.x quiere 17.x. Se recomienda Redis 7.2, con 7.0 como mínimo, y Valkey 7.2 sirve como sustituto. Solo instancias autónomas, porque las variantes en clúster y serverless de Redis no están soportadas.
Instala con el paquete de Linux. Hay charts de Helm, un Operator, imágenes de Docker y una vía desde el código fuente, pero el paquete de Linux es la opción más madura y es sobre lo que corre el propio GitLab.com. Trae PostgreSQL, Redis y Sidekiq incluidos, así que una máquina y un fichero de configuración bastan para tener una instancia funcionando.
# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'
# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']
# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9
# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'AWS',
'region' => 'eu-central-1',
'aws_access_key_id' => 'REPLACE_ME',
'aws_secret_access_key' => 'REPLACE_ME'
}
Un gitlab-ctl reconfigure después tienes una instancia. Configura external_url bien a la primera, porque ese valor acaba grabado en las URL de clonado, los webhooks y las direcciones del registro.
Un despliegue de producción
GitLab publica arquitecturas de referencia de 1.000 a 50.000 usuarios, y merece la pena leerlas aunque no implementes ninguna, porque muestran qué componente se convierte antes en cuello de botella.
El consejo que más dinero ahorra es del propio GitLab y argumenta en contra de la complejidad: por debajo de 3.000 usuarios recomiendan una estrategia sólida de copias de seguridad antes que alta disponibilidad. La documentación es inusualmente franca al respecto, señalando que el enfoque de copias tiene un tiempo de recuperación más lento pero supone una arquitectura mucho más pequeña y menores costes de mantenimiento. Por encima de 3.000 usuarios, o allí donde una caída detiene de verdad a la empresa, la alta disponibilidad pasa a ser la recomendación.
Tómatelo en serio. Un único nodo bien respaldado, con una restauración probada, es en la práctica más fiable que un clúster de alta disponibilidad entendido a medias, y bastante más barato.
Mueve artefactos, subidas, objetos LFS e imágenes del registro a almacenamiento de objetos desde el principio. El mismo razonamiento que en todo lo demás: mantiene el nodo sin estado, las copias manejables y la migración posible.
Las tres cosas que salen mal
Todo lo anterior está en la documentación. Esto es lo que produce incidencias.
Tu copia de seguridad no contiene lo que la descifra
Este es el párrafo más importante del artículo.
gitlab-backup create captura bastante: la base de datos, los repositorios, los objetos LFS, los artefactos de CI y los registros de los trabajos, las imágenes del registro, los wikis, las subidas, el contenido de Pages, el estado de Terraform, los snippets. Lo que no captura es el directorio de configuración, y en concreto /etc/gitlab/gitlab-secrets.json.
Ese fichero guarda la clave de cifrado de la base de datos. La documentación es rotunda sobre la consecuencia: si lo pierdes, la aplicación de GitLab no podrá descifrar ningún valor cifrado de la base de datos. Es decir, variables de CI/CD, tokens, secretos de doble factor y credenciales de integraciones. Tendrías una copia que se restaura en una instancia incapaz de leer sus propios secretos.
También quedan fuera: /etc/gitlab/gitlab.rb, las claves y certificados TLS, las claves de host SSH y el contenido del almacenamiento de objetos cuando este está configurado. Esto último pilla justo a quien hizo lo correcto en lo arquitectónico y luego dio por supuesto que la copia lo cubría.
Así que respalda /etc/gitlab por separado, guárdalo en un sitio distinto al del archivo, ya que es la llave del archivo, y después restaura todo en una máquina desechable y comprueba que puedes iniciar sesión y leer una variable de CI. Una copia sin probar no es una copia, y en el caso de GitLab una restauración sin probar suele estar rota.
No puedes actualizar de un salto
GitLab tiene paradas obligatorias de actualización, y esto no es orientativo. No puedes saltártelas. Desde la 17.5 las paradas son predecibles y caen en x.2, x.5, x.8 y x.11, así que pasar de 18.0 a 19.2 implica atravesar 18.2, 18.5, 18.8, 18.11 y 19.0.
Cada parada implica migraciones en segundo plano que deben completarse del todo antes de pasar a la siguiente. Empezar la actualización siguiente mientras las migraciones aún corren es la forma en que las instancias acaban en estados que solo el soporte desenreda. En una instancia grande esas migraciones pueden llevar horas.
Dos consecuencias prácticas. Actualiza con regularidad, porque un año de actualizaciones aplazadas es un fin de semana de actualizaciones consecutivas. Y coge siempre la última versión de parche de la versión menor objetivo en lugar de la primera, cosa que la documentación dice explícitamente. GitLab mantiene una herramienta que calcula la ruta de actualización por ti, y conviene usarla en lugar de razonarla a mano.
El coste de verdad está en los runners
El servidor de GitLab no ejecuta tu CI. GitLab Runner es un componente aparte que instalas, configuras y pagas, sobre infraestructura que aportas tú. Free autoalojado no incluye ningún minuto de cómputo, porque no hay cómputo incluido que dar: pones tus propias máquinas.
Normalmente es un buen trato, porque un runner dedicado sale más barato por minuto que cualquier CI alojada en cuanto hay volumen serio, y puedes darle a cada build el hardware que necesite. Pero es trabajo de infraestructura real. Tomarás decisiones sobre executors, ya sea shell, Docker o Kubernetes; sobre autoescalado, para que los runners no estén ociosos a las tres de la madrugada; y sobre caché, que es la diferencia entre un pipeline de cuatro minutos y uno de catorce.
Presupuesta la flota de runners como una partida propia. Los equipos que modelan el coste de autoalojar mirando solo el nodo de GitLab se quedan muy cortos, y luego descubren el hueco en forma de cola de trabajos pendientes.
Salir de GitHub
El importador de GitHub es bueno, bastante mejor que la mayoría de las herramientas de migración de los fabricantes, y trae los datos del repositorio, las ramas, los objetos LFS, las incidencias y las pull requests con sus comentarios, revisiones y respuestas de discusión, las páginas de wiki, las releases y sus adjuntos, las etiquetas, los hitos, las reglas de protección de ramas y los colaboradores con correspondencia de roles.
Las lagunas documentadas conviene preverlas. Las organizaciones y los grupos no pasan, así que la estructura de grupos es tuya para diseñarla en vez de heredarla, lo que suele ser una mejora. Los flujos de GitHub Actions no se convierten en GitLab CI. Los comentarios de pull requests anteriores a 2017 llegan como hilos separados por restricciones de la API de GitHub, y los repositorios con más de unos 30.000 comentarios necesitan activar el método alternativo de importación de comentarios.
Como GitHub usa # tanto para incidencias como para pull requests, y GitLab las distingue, algunas referencias cruzadas no resolverán. No se pierde nada, pero los enlaces de discusiones antiguas pueden apuntar a lo que no es.
Planifica la reescritura de la CI como el proyecto de verdad, porque lo es. Todo lo demás es una importación que lanzas y revisas.
El ángulo europeo
Para las empresas que operan en Europa, al coste se le suma una dimensión de cumplimiento. El código fuente, los pipelines de compilación y los artefactos están entre lo más sensible que tiene una empresa tecnológica, y dónde residen es cada vez más una pregunta que te hacen y no una que eliges responder.
Autoalojar los sitúa dentro de un perímetro que controlas, lo que simplifica de una vez el análisis de transferencias del RGPD y las preguntas de cadena de suministro de NIS2, y es el mismo argumento de soberanía sobre el que está construida la Ley de desarrollo de la nube y la IA.
La conexión más nítida es el Reglamento de Ciberresiliencia. Si pones software en el mercado de la UE necesitarás inventarios de dependencias, gestión de vulnerabilidades y un proceso de divulgación coordinada. Esas obligaciones se satisfacen en el pipeline de compilación y no en un documento, y tener el pipeline, el registro y el análisis en un solo sistema que operas tú hace que producir las pruebas duela bastante menos que reunirlas desde cuatro proveedores.
Cuándo no molestarse
Si sois menos de veinte ingenieros, sin presión regulatoria ni opiniones fuertes sobre dónde vive el código, usad el SaaS. GitLab.com y GitHub son ambos excelentes, y el trabajo operativo costará más que la suscripción.
Si tu organización está metida a fondo en el ecosistema de GitHub, cuenta con honestidad lo que perderías. Actions, el marketplace y la simple familiaridad de la plataforma para cada candidato que contratas son activos reales, y la respuesta no es automáticamente que gane GitLab.
Y si nadie va a hacerse cargo de la instancia, no empieces. GitLab premia a quien la parchea, vigila la flota de runners y prueba la restauración. Sin esa persona degenera en una máquina sin parchear que contiene tu activo más valioso, lo cual es peor que el SaaS del que intentabas salir.
Cómo podemos ayudar
Desplegamos y operamos infraestructura de desarrollo autoalojada para empresas que trabajan en Europa, incluidas las partes que no gustan a nadie: secuencias de actualización a través de las paradas obligatorias, flotas de runners que autoescalan bien, migraciones a almacenamiento de objetos y esquemas de copia que se han restaurado de verdad.
Si quieres una instancia de GitLab dimensionada con honestidad, una migración desde GitHub planificada por alguien que ya ha hecho la reescritura de CI, o una revisión de si tu copia actual sobreviviría a un fallo real, escribe a office@c9group.dev. Más sobre nuestro trabajo de infraestructura en la página de optimización de costes en AWS.
Si estás montando una pila autoalojada completa, el mismo razonamiento aplica a la analítica, la automatización de marketing y la mensajería de equipo.
Publicado: 8 de agosto de 2026 Categorías: DevOps, Código Abierto, Privacidad