Por qué GitLab.com se volvió insostenible para equipos de 5 o más personas
El 15 de agosto de 2026, GitLab aplicó una nueva política en su nivel gratuito: cualquier namespace con más de cinco miembros pasa automáticamente a modo de solo lectura (fuente: support.gitlab.com/hc/en-us/articles/28301407860508). En la práctica, los desarrolladores adicionales no pueden hacer push de código, abrir merge requests ni lanzar pipelines de CI/CD. La única salida que propone GitLab es la suscripción de pago, cuyo coste por usuario se vuelve rápidamente significativo para una startup o agencia.
Esta decisión se enmarca en una monetización acelerada de la plataforma SaaS. Afecta principalmente a los equipos de código abierto con presupuesto reducido, las agencias con varios proyectos y los desarrolladores independientes que comparten un namespace. No es la primera restricción de este tipo: GitLab ya eliminó los minutos de CI/CD gratuitos para nuevos usuarios en 2021. La tendencia es estructural.
Frente a esta restricción, autoalojar la forja Git en un VPS recupera todo su sentido. Controlas los accesos, los datos permanecen en tu infraestructura y el coste es fijo — el del servidor, no el de los puestos.
Lo que Gitea proporciona de forma nativa
- Forja Git completa — repositorios, ramas, etiquetas, pull requests, revisión de código inline y gestión de conflictos desde la interfaz web.
- Gestión de organizaciones y equipos — permisos granulares por repositorio (lectura, escritura, administración) sin límite de miembros.
- Gitea Actions — motor CI/CD compatible con la sintaxis YAML de GitHub Actions, lo que facilita la portabilidad de los flujos de trabajo existentes.
- Registro de paquetes integrado — npm, PyPI, Maven, Docker, Helm: publica y consume artefactos sin dependencia externa.
- Webhooks y API REST — superficie de API amplia para integrar herramientas de despliegue, notificaciones Slack o paneles internos.
- Autenticación SSO — LDAP, OAuth2, SAML y OpenID Connect soportados de forma nativa para centralizar la gestión de identidades.
- Huella de memoria reducida — 512 MB de RAM son suficientes para un equipo de diez personas; se recomienda 1 GB para runners concurrentes de Actions.
- Actualizaciones sencillas — binario único o imagen Docker oficial, migraciones de base de datos automáticas en cada actualización de versión.
Requisitos previos antes de empezar
En el lado del servidor, Gitea v1.27.3 funciona cómodamente con 512 MB de RAM para un uso mínimo; prevé 1 GB si activas Gitea Actions con runners concurrentes. La plantilla VPS de ServOrbit parte de una imagen Debian 12 con Docker preinstalado — es el modo de despliegue recomendado ya que aísla el proceso de Gitea y simplifica las actualizaciones.
En el lado de la red, apunta un subdominio a la IP de tu VPS antes de lanzar la instalación: Gitea genera las URLs de clonación SSH y HTTPS en el primer inicio, y corregirlas después resulta tedioso. Un registro A git.your-domain.com es suficiente. También necesitarás un certificado TLS — Caddy o Traefik pueden generarlo automáticamente vía Let's Encrypt como proxy frontal de Gitea.
En GitLab.com, comprueba que tienes derechos de Owner en los grupos o proyectos a migrar: la exportación requiere este nivel de acceso. Genera un token de API personal con los ámbitos api y read_repository — se usará durante la exportación vía API.
GitLab vs Gitea — criterios clave
Desplace la tabla
| Criterio | GitLab.com Free | Gitea VPS |
|---|---|---|
| Límite de miembros (SaaS gratuito) | 5 miembros (solo lectura más allá desde agosto 2026) | Ilimitado en autoalojado |
| Huella de memoria mínima | 4 GB (GitLab CE autoalojado) | 512 MB |
| CI/CD integrada | GitLab CI (YAML) | Gitea Actions (sintaxis GitHub Actions) |
| Registro de contenedores | Sí (GitLab Container Registry) | Sí (Gitea Packages — Docker incluido) |
| Gestión de merge/pull requests | Merge Requests avanzadas | Pull Requests con revisión de código inline |
| Autenticación SSO | SAML, LDAP, OAuth2 | LDAP, OAuth2, SAML, OIDC |
| Importación desde GitLab | No disponible | Importación nativa vía API o archivo .tar.gz |
| Coste de operación | 29 $/usuario/mes (Premium) | Solo el coste del VPS (99 DH/mes/mes) |
Preparar la exportación de GitLab
Para exportar vía API sin pasar por la interfaz, lanza la ex
Para exportar vía API sin pasar por la interfaz, lanza la exportación con:
curl --request POST --header "PRIVATE-TOKEN: <your-token>" "https://gitlab.com/api/v4/projects/<project-id>/export"Comprueba el estado de la exportación con:
Comprueba el estado de la exportación con:
curl --header "PRIVATE-TOKEN: <your-token>" "https://gitlab.com/api/v4/projects/<project-id>/export"— espera el estadofinished.Descarga el archivo de exportación:
Descarga el archivo de exportación:
curl --location --header "PRIVATE-TOKEN: <your-token>" "https://gitlab.com/api/v4/projects/<project-id>/export/download" --output gitlab-export.tar.gzPara migrar también el historial Git completo, clona el repo
Para migrar también el historial Git completo, clona el repositorio con todas las referencias:
git clone --mirror [email protected]:your-group/your-project.git your-project.gitVerifica la integridad del clon espejo antes de transferir:
Verifica la integridad del clon espejo antes de transferir:
git -C your-project.git fsck --no-progress— no debe aparecer ningún error.Transfiere el archivo y el repositorio espejo a tu VPS:
Transfiere el archivo y el repositorio espejo a tu VPS:
rsync -avz gitlab-export.tar.gz your-project.git user@your-vps:/tmp/migration/
Importar en Gitea en el VPS
En tu VPS, crea la organización destino en Gitea vía la inte
En tu VPS, crea la organización destino en Gitea vía la interfaz web o la API:
curl -X POST "https://git.your-domain.com/api/v1/orgs" -H "Authorization: token <gitea-token>" -H "Content-Type: application/json" -d '{"username":"my-organisation","visibility":"private"}'Crea el repositorio vacío en Gitea antes de la importación:
Crea el repositorio vacío en Gitea antes de la importación:
curl -X POST "https://git.your-domain.com/api/v1/orgs/my-organisation/repos" -H "Authorization: token <gitea-token>" -H "Content-Type: application/json" -d '{"name":"my-project","private":true}'Empuja el historial Git desde el clon espejo:
Empuja el historial Git desde el clon espejo:
git -C your-project.git remote set-url origin https://git.your-domain.com/my-organisation/my-project.gity luegogit -C your-project.git push --mirrorPara importar issues y merge requests desde el archivo de Gi
Para importar issues y merge requests desde el archivo de GitLab, usa la herramienta
gitea-migratoro la importación nativa de Gitea: en la interfaz, + New Migration > GitLab y proporciona la URL del proyecto fuente con tu token de GitLab.Verifica que todas las ramas y etiquetas están presentes:
Verifica que todas las ramas y etiquetas están presentes:
git ls-remote https://git.your-domain.com/my-organisation/my-project.gitdebe listar las mismas referencias que el original.Actualiza las URLs de clonación en la configuración local de
Actualiza las URLs de clonación en la configuración local de cada desarrollador:
git remote set-url origin https://git.your-domain.com/my-organisation/my-project.git
Configurar la CI/CD en Gitea
Gitea v1.27.3 incluye Gitea Actions, un motor de CI/CD cuya sintaxis YAML es intencionalmente compatible con GitHub Actions. Si tus pipelines existían en GitLab CI, es necesaria cierta adaptación — los stages y script de GitLab se traducen en jobs y steps de Gitea Actions — pero la lógica es la misma.
Para activar los runners, instala act_runner en tu VPS o en una máquina dedicada: act_runner register --no-interactive --instance https://git.your-domain.com --token <runner-token> --name my-runner --labels ubuntu-latest:docker://node:20-bullseye. El token de registro se encuentra en Site Administration > Runners.
Si prefieres un enfoque de CI/CD más desacoplado, Woodpecker CI es una alternativa madura que se integra de forma nativa con Gitea vía OAuth2 y ofrece una interfaz de supervisión de builds. Su archivo de pipeline .woodpecker.yml también está próximo a la sintaxis de Drone CI, lo que simplifica las migraciones desde stacks más antiguos.
Migrar los miembros del equipo y los permisos
Gitea organiza los accesos en tres niveles: organizaciones (equivalentes a los grupos de GitLab), equipos dentro de una organización y permisos por repositorio. Empieza creando todas las cuentas de usuario — ya sea manualmente, activando el autoregistro temporalmente, o vía LDAP/SSO si ya está disponible.
Crea después los equipos en tu organización: Owners, Developers, Reporters se corresponden con los roles Owner, Developer y Reporter de GitLab. Gitea permite refinar los permisos por repositorio dentro del mismo equipo — un subconjunto de miembros puede tener acceso de escritura solo a ciertos repos.
Para migrar las membresías en lote, la API de Gitea acepta llamadas como: curl -X PUT "https://git.your-domain.com/api/v1/orgs/my-organisation/teams/<team-id>/members/<username>" -H "Authorization: token <gitea-token>". Un script shell que recorra tu lista de usuarios exportada de GitLab es suficiente para automatizar este paso en equipos de menos de cincuenta personas.
Resolución de problemas — los 4 errores más frecuentes
remote: repository not found durante el push espejo. El repositorio destino aún no existe en Gitea, o el token usado no tiene derechos de escritura. Verifica que el repositorio se haya creado (paso 2 de la importación) y que tu token tenga el ámbito write:repository.
error: src refspec refs/merge-requests/... does not match any durante push --mirror. Las referencias internas de GitLab (refs/merge-requests/) no son aceptadas por Gitea. Filtralas explícitamente antes de hacer push: elimina las refs parásitas localmente con git -C your-project.git for-each-ref --format='%(refname)' refs/merge-requests | xargs -I{} git update-ref -d {}.
Error 413: Request Entity Too Large al importar un archivo grande. El tamaño máximo de carga está configurado en app.ini de Gitea bajo la clave MAX_UPLOAD_SIZE. Auméntalo (MAX_UPLOAD_SIZE = 2048 para 2 GB) y recarga el servicio: docker compose restart gitea.
Las issues importadas no muestran los autores correctos. Gitea asocia las issues con las cuentas locales por nombre de usuario. Si el nombre de GitLab difiere del de Gitea, las issues se atribuyen al usuario que lanzó la importación. Crea todas las cuentas con los mismos nombres de usuario que en GitLab antes de ejecutar la migración de issues.
Consejo de seguridad post-migración
Una vez completada la migración, desactiva el autoregistro (DISABLE_REGISTRATION = true en app.ini) si no usas SSO, y activa la autenticación de dos factores obligatoria para todos los miembros Owner. Configura también copias de seguridad automáticas del volumen Docker que contiene /data/gitea: un volcado diario a almacenamiento remoto (S3, Backblaze B2) te protege de pérdida de disco. Por último, verifica que el puerto SSH de Gitea (por defecto 2222 en Docker) no esté expuesto directamente en la IP pública si filtras por clave SSH — una regla de fail2ban o de UFW que limite las conexiones SSH por minuto reduce significativamente la superficie de ataque.
Recupera el control de tu forja Git
La restricción de GitLab.com del 15 de agosto de 2026 aceleró una tendencia ya en marcha: los equipos que habían aceptado depender de una plataforma SaaS gratuita se encuentran ante una decisión de precio no anticipada. Gitea v1.27.3 responde a las necesidades esenciales de una forja Git de equipo — repositorios, pull requests, CI/CD, registro de paquetes, SSO — en una huella que cabe en un VPS de entrada.
La migración no es instantánea, pero es secuencial y reversible en cada paso: el historial Git está completo tras el push --mirror, las issues y pull requests siguen a través de la importación nativa, y la CI/CD se reconfigura en pocas horas si tus flujos de trabajo ya estaban en YAML. La plantilla VPS Gitea de ServOrbit te ahorra la fase de instalación y configuración inicial — Gitea está listo, Docker está en su lugar, solo queda vincular tu dominio y seguir los pasos descritos aquí.
Consulta las guías complementarias sobre la stack IA self-hosted con Gitea y Ollama, la sustitución de GitHub Actions por Woodpecker CI y la instalación de GitLab CE en VPS si aún estás comparando ambas opciones.
