GitLab vs. GitHub: ¿cuál debería usar nuestro pequeño equipo?

La semana en que contratas a un sexto desarrollador, el grupo privado de nivel superior que aloja tu código en GitLab.com Free supera los cinco usuarios. Según la documentación de GitLab sobre el límite de usuarios gratuitos, el grupo pasa entonces a ser de solo lectura. En GitHub Free para organizaciones, la nueva incorporación entra sin problema, ya que los colaboradores son ilimitados, pero te toparás con otro límite la primera vez que quieras bloquear main. Los repositorios privados de GitHub Free no pueden usar ramas protegidas ni propietarios de código.

Los planes de pago que compararías a continuación son GitHub Team, a 4 $ por usuario al mes for the first 12 months, y GitLab Premium, a 29 $ por usuario al mes con facturación anual. También hay una opción sin ningún coste de licencia: GitLab Community Edition. CE funciona en servidores que tú controlas, uno para GitLab y otro para el runner que ejecuta tus trabajos de CI, y la tabla siguiente le dedica su propia columna.

Cómo se comparan los planes en un repositorio privado

Cada fila de la tabla supone un repositorio privado de equipo. Los datos de cada plan proceden de la página de precios o la documentación de cada proveedor.

Planes y precios según github.com/pricing y about.gitlab.com/pricing a 28 de septiembre de 2026, sin cambios cuando volvimos a consultar ambas páginas el 21 de octubre. La página de GitHub no indica cuánto cuesta Team después de los primeros 12 meses. La fila de almacenamiento no compara lo mismo: lo que incluye GitHub cubre paquetes y artefactos de Actions, y lo de GitLab cubre el almacenamiento del repositorio Git y LFS en cada proyecto.

Si tu equipo quiere que alguien dé el visto bueno antes de que un despliegue llegue a producción, fíjate en la fila de despliegue antes que en la del precio. En GitHub Free, Pro y Team, los revisores obligatorios para entornos de despliegue solo funcionan en repositorios públicos, lo que sitúa ese control un nivel por encima de la revisión obligatoria antes de fusionar para cualquiera con código privado. GitLab incluye ambos en Premium, donde los entornos protegidos definen quién puede desplegar y quién debe aprobar. Si tu código es público, la mayoría de estas diferencias desaparecen en GitHub: las ramas protegidas y los revisores de despliegue funcionan en repositorios públicos sin plan de pago.

Cuál encaja con tu equipo

En nuestra opinión, GitHub es más difícil de dejar cuando tus pipelines dependen de Actions, ya que mudarte implica adaptar a GitLab CI los flujos del Marketplace que reutilizas.

Qué deja fuera GitLab CE y qué conserva

En CE, uno de tus responsables puede fusionar una solicitud que nadie ha revisado, y GitLab no lo impedirá. Las aprobaciones del nivel gratuito, que es el conjunto de funciones que ejecuta CE, «son opcionales y no impiden fusionar sin aprobación». Todo lo que aparece en la lista What needs Premium lleva la etiqueta Premium en la documentación de GitLab.

Que haya una revisión antes sigue dependiendo de tus Maintainers. Si un contrato con un cliente o una auditoría de cumplimiento exige que ningún cambio salga sin una segunda aprobación, CE no puede imponerlo, y las reglas de aprobación de Premium sí.

No tendrás que migrar para conseguirlas. La documentación de conversión de GitLab te indica que instales el paquete Enterprise Edition (EE) sobre CE y después añadas una licencia. Hasta que la añadas, EE ofrece las mismas funciones Free sin coste. Las funciones de Premium se activan cuando activas una licencia de pago.

Qué supone gestionarlo por tu cuenta

Un administrador de CE en el foro de GitLab, que gestiona una instancia con unos 40 usuarios registrados, de los que unos cinco están activos, hace esta rutina cada lunes:

Tu plan necesita algo más:

• Aplicar las actualizaciones de GitLab siguiendo un calendario fijo, a una hora tranquila. Tras un arranque en frío, nuestra instancia de prueba tardó unos 2 minutos en mostrar la página de inicio de sesión
• Hacer copias de seguridad en un lugar distinto del servidor y restaurar una copia de vez en cuando para comprobar que funciona. La copia de seguridad de GitLab no incluye gitlab.rb ni gitlab-secrets.json, y su documentación sobre copias de seguridad indica que los copies tú
• Actualizar también GitLab Runner en su propio servidor
• Designar a una segunda persona que pueda encargarse de todo cuando la primera no esté

Esto es lo que cuesta un año de usuarios a precio de lista, sin contar los servidores:

Son 29 $ y 4 $ por usuario al mes, por 12. Nuestra guía sobre los costes por usuario de GitLab y GitHub frente a un servidor de GitLab CE calcula la factura completa, servidores incluidos. Con el salario mediano de 2025 en EE. UU. para desarrolladores de software, analistas de QA y testers, de 64,44 $ por hora según la Bureau of Labor Statistics, 10 usuarios de Premium cuestan al año lo mismo que unas 54 horas de trabajo de un desarrollador, y 10 usuarios de GitHub Team, unas 7 horas.

Para comparar esas horas con las cuotas por usuario de tu propio equipo, toma un año de usuarios de Premium, resta lo que cuestan los dos servidores y divide entre tu coste por hora. El resultado son las horas de mantenimiento al año que podrías dedicar antes de que CE salga más caro que Premium. Esto solo compara costes, ya que CE no impone aprobaciones como hace Premium. Si tu otra opción es GitHub Team, haz el mismo cálculo con su precio de 4 $ por usuario. A ese precio, las cuotas tardan mucho más en igualar el coste de dos servidores y su mantenimiento.

En el VPS de GitLab de DreamHost, DreamHost se ocupa del hardware, la red y la conectividad 24/7, y la página del producto indica que las actualizaciones de software y la configuración corren de tu cuenta. Las copias de seguridad también, como indica la lista anterior.

Cuánto servidor necesita GitLab

La página de requisitos de GitLab fija 8 vCPU y 16 GB de memoria como base para una instalación de un solo nodo. Los planes de VPS de GitLab de DreamHost incluyen Stack 16 (4 vCPU, 16 GB) y Stack 32 (8 vCPU, 32 GB). Stack 32 es el primer plan que cumple esa base. Stack 16 alcanza los 16 GB pero tiene la mitad de las 8 vCPU, así que queda por debajo de la base, y los planes más pequeños quedan aún más lejos. La guía de GitLab para memoria limitada baja mucho más, para un máximo de cinco desarrolladores. Ninguna de las dos páginas menciona equipos de 10 o 20 personas.

Esas cifras son solo para GitLab. Los trabajos de CI van en otro sitio: la página de instalación del runner de GitLab indica que instales GitLab Runner en una máquina distinta de la que aloja tu instancia de GitLab. GitLab no publica un tamaño para esa máquina. Su página de requisitos del runner dice que depende de cuánta CPU y memoria usen tus trabajos, cuántos se ejecuten a la vez y cuántas personas trabajen en paralelo. Según nuestra estimación, basta con un Stack 8, que tiene 2 vCPU y 8 GB, lo mismo que el runner alojado predeterminado de GitLab.com.

Páginas de requisitos de GitLab consultadas el 28 de septiembre de 2026, y las del runner, el 20 de octubre de 2026. Las especificaciones de los Stack proceden de la página del VPS de GitLab de DreamHost.

La documentación de GitLab no indica en qué punto 4 vCPU se quedan cortas para un equipo como el tuyo, y nosotros tampoco lo hemos medido, así que la prueba siguiente ejecuta GitLab en Stack 16 y lo vigila mientras corren los pipelines. Si los trabajos se quedan en cola durante la prueba, revisa la configuración de concurrencia del runner y el uso de CPU en ambos servidores antes de culpar al plan. Un servidor de GitLab con la CPU casi al máximo mientras corren los pipelines es la señal de que has dado con el límite, y Stack 32 cumple las dos cifras base de la página de requisitos. El disco crece con tus repositorios, imágenes de contenedores y artefactos de CI, así que revisa el espacio usado al final de la prueba y proyéctalo a futuro.

Lo que consumió GitLab CE en nuestra VM de prueba

Las páginas de dimensionamiento de GitLab dan una base para uso real y un mínimo para poca memoria, pero ningún dato de lo que consume realmente una instalación vacía. Así que ejecutamos la imagen oficial de GitLab CE 19.5.0 en una VM de prueba con 2 vCPU y 8 GB, más o menos el tamaño del servidor del runner mencionado arriba, y medimos su memoria 10 minutos después de que se estabilizara. Después ejecutamos tres pipelines de un pequeño proyecto de Node.js, con GitLab Runner en la misma VM.

En las cifras de CPU, el 100 % equivale a una vCPU, así que el trabajo y GitLab juntos necesitaron más que las dos de la VM. Estas ejecuciones no tenían usuarios y solo un proyecto pequeño, así que no pueden indicarte un tamaño de equipo. Lo que sí muestran es que la memoria de GitLab en reposo ronda los 4285 MiB con la configuración predeterminada y los 2657 MiB con la de poca memoria, aproximadamente una cuarta parte o menos de los 16 GB de Stack 16, lo que deja las 4 vCPU como la cifra que hay que vigilar. Por eso, durante la prueba, vigila la CPU de ambos servidores mientras se ejecutan tus propios pipelines.

Cómo probar CE durante un sprint

Replica tu código en el servidor de prueba y deja el original donde está: si la prueba no sale bien, no tendrás nada que devolver.

1. Copia un repositorio real

   Elige un repositorio con un pipeline que funcione y su historial real, para que la prueba refleje tu tamaño y tus tiempos de compilación reales. El importador de GitHub de GitLab trae el repositorio, las incidencias y las pull requests.

2. Configura la regla de fusión

   Protege main con Allowed to merge en Maintainers y Allowed to push and merge en No one. Después comprueba si tus responsables se sienten cómodos con aprobaciones que GitLab no hace obligatorias.

3. Ejecuta una semana normal de CI

   Registra un runner en un segundo servidor, un Stack 8, y ejecuta tus pipelines habituales. Si son flujos de trabajo de GitHub Actions, reescríbelos primero para GitLab CI y cuenta esas horas en la prueba. Anota cuánto esperan los trabajos mientras la gente usa la aplicación web.

4. Prueba una restauración y una actualización

   Restaura una copia de seguridad, junto con tus copias de gitlab.rb y gitlab-secrets.json, en un servidor de repuesto desechable y luego aplica una actualización de GitLab. Anota cuánto tardó cada cosa y lo que tuviste que arreglar a mano. Nosotros no cronometramos ninguna actualización en nuestra VM de prueba, así que de este paso sale tu cifra de mantenimiento.

Antes de que empiece el sprint, apunta tu criterio de aprobado: cuánto puede esperar una compilación y cuántas horas de mantenimiento al mes estás dispuesto a asumir.

Cómo probamos GitLab CE

Las cifras de GitLab de esta página las midió DreamHost en una VM de prueba (arm64), no en un servidor de DreamHost, el 20 de octubre de 2026. Es la misma prueba en la que se basa nuestra guía sobre los costes por usuario de GitLab y GitHub, que incluye la configuración completa y las mediciones en reposo con más detalle. Nuestros planes usan procesadores x86 AMD EPYC, así que espera pequeñas diferencias en un servidor real. En resumen: la imagen oficial de CE 19.5.0 en una máquina de 2 vCPU con 8 GB de memoria (7922 MiB según Linux), una vez con la configuración predeterminada y otra con la configuración para memoria limitada de GitLab. Para los pipelines, GitLab Runner estaba en la misma máquina y ejecutó tres veces los trabajos de prueba y compilación del proyecto de código abierto Express, mientras medíamos la memoria y la CPU cada 3 segundos.

Lo que no probamos: la carga de un equipo real, un repositorio grande, varios pipelines a la vez, un runner en un segundo servidor, las 4 vCPU de Stack 16 o las 8 de Stack 32, y el tiempo de inactividad de una actualización. Cada configuración se ejecutó una sola vez. Los datos y precios de los planes proceden de las propias páginas de GitHub y GitLab en las fechas indicadas en las fuentes.

Preguntas frecuentes sobre GitLab y GitHub