Por qué autoalojar tu forja Git en un VPS
Una forja Git autoalojada mantiene tu propiedad intelectual fuera de las plataformas públicas y elimina cualquier límite arbitrario sobre el número de repositorios privados, de colaboradores o de minutos de CI. En un VPS, controlas la localización de los datos, las copias de seguridad y la integración con tu pipeline interno. Gitea (y su fork Forgejo) está escrito en Go: un binario único, arranque instantáneo, huella de memoria mínima, ideal para un VPS modesto. GitLab CE es una suite integrada (incidencias, CI/CD, registro Docker, registro de paquetes, wiki, entornos), pero consume mucha más RAM.
Las ventajas de una forja autoalojada
- Repositorios privados sin tope ni suscripción por puesto
- CI/CD bajo tu control, con tus propios runners en el VPS
- Secretos y tokens almacenados en tu servidor, fuera de una plataforma de terceros
- Registro de imágenes Docker y de paquetes integrado, cerca de tus despliegues
- Cumplimiento y localización de los datos completamente bajo control
- Con Gitea: un único binario, con una copia de seguridad que se limita a una carpeta y una base de datos
Gitea vs GitLab: diferencias de licencia en 2026
Gitea se publica bajo licencia MIT: puedes leer el código, modificarlo, redistribuirlo y alojarlo sin restricciones comerciales. Forgejo, su fork comunitario nacido en 2022, aplica la misma licencia. GitLab CE también es MIT — pero únicamente la capa Community Edition. GitLab EE (Enterprise Edition) es propietario: las funcionalidades premium (SAML SSO avanzado, aprobaciones de MR múltiples, SAST/DAST integrados, epics, roadmaps) están bloqueadas detrás de una suscripción de pago que empieza en varios cientos de euros por usuario al año. Para un equipo que autoaloja GitLab CE, el riesgo principal no es la licencia sino el efecto de arrastre hacia el nivel de pago: las funcionalidades ausentes en CE empujan progresivamente hacia EE. Con Gitea o Forgejo, todas las funcionalidades disponibles están incluidas en la versión libre, sin nivel de pago.
Rendimiento y recursos del servidor
Gitea consume aproximadamente 100 a 150 MB de RAM en reposo en un despliegue Docker estándar con PostgreSQL. Con una decena de runners activos y algunas pipelines simultáneas, te mantienes por debajo de 400 MB para la forja — encaja fácilmente en un VPS de 2 GB. GitLab CE en omnibus es una categoría diferente: PostgreSQL, Redis, Sidekiq, Gitaly, Puma y NGINX corren en paralelo. En reposo, el conjunto supera habitualmente los 3 a 4 GB de RAM y puede subir a 6-8 GB bajo carga CI. GitLab recomienda oficialmente 8 GB de RAM para uso en producción con CI activado.
Gitea vs GitLab CE: tabla comparativa completa
Desplace la tabla
| Criterio | Gitea / Forgejo | GitLab CE |
|---|---|---|
| RAM en reposo | ~128 MB (solo la forja) | 3 a 4 GB (omnibus completo) |
| RAM recomendada producción | 1 a 2 GB | 8 GB |
| Arquitectura | Binario Go único | Suite multiservicio (omnibus) |
| Tiempo de arranque | Casi instantáneo | Varios minutos |
| Licencia | MIT (Gitea) / MIT (Forgejo) | MIT (CE) / propietaria (EE) |
| CI/CD integrada | Gitea Actions (estilo GitHub) | GitLab CI/CD, muy completa |
| Runners distribuidos | Básico (act runner) | Avanzado (runners distribuidos, executor k8s) |
| SAST / DAST integrado | No (vía plugins CI) | Solo EE |
| Aprobaciones de MR múltiples | Simple | Avanzado (EE) |
| Registro Docker / paquetes | Incluido y ligero | Incluido, completo |
| Gestión de proyectos (incidencias, tableros) | Esencial | Avanzada (epics según la edición) |
| Facilidad de copia de seguridad | Carpeta + dump SQL | Procedimiento omnibus dedicado |
| Ideal para | VPS modesto, equipos de 1 a 30 devs | Plataforma DevOps enterprise |
Comparativa de funcionalidades CI/CD
Gitea Actions apareció en Gitea 1.19 (2023) y reutiliza exactamente la sintaxis de los workflows de GitHub Actions: los archivos .github/workflows/*.yml existentes son reutilizables sin modificación en la mayoría de los casos. El ejecutor subyacente es act, encapsulado en un runner Docker. Es suficiente para la mayoría de las pipelines: build, test, lint, push de imagen, despliegue SSH. Las limitaciones aparecen en los casos avanzados: sin cachés compartidas entre runners a escala, sin entornos de revisión nativos. GitLab CI es más maduro en estos puntos: runners distribuidos en varias máquinas, ejecutores Kubernetes, cachés compartidas, entornos dinámicos, review apps, directivas rules: e include: potentes. La regla práctica: Gitea Actions es suficiente para equipos de 1 a 20 desarrolladores con pipelines estándar; GitLab CI se impone cuando la madurez del pipeline es en sí misma un criterio de elección.
Migración GitLab a Gitea: lo que cubre la CVE-2026-85706
La CVE-2026-85706 es una vulnerabilidad de tipo Server-Side Request Forgery (SSRF) descubierta en GitLab CE y EE que afecta a las versiones anteriores al parche de marzo de 2026. Permite a un atacante autenticado forzar a GitLab a hacer solicitudes HTTP hacia recursos de la red interna a través de la funcionalidad de importación de repositorio remoto. En un VPS donde GitLab comparte la red interna con otros servicios (bases de datos, registros, APIs), la exposición es real. Gitea no está afectado por esta CVE específica. La migración GitLab a Gitea está documentada y cubierta por gitea-migration-tool: importa repositorios, incidencias, etiquetas, hitos, pull requests y comentarios desde la API de GitLab. Si estás ejecutando una versión sin parchear de GitLab CE en un VPS expuesto, migrar a Gitea o actualizar urgentemente son las únicas opciones razonables.
Cuándo elegir GitLab CE pese al coste en recursos
- Equipos de más de 50 desarrolladores activos: la gestión detallada de permisos y los grupos anidados de GitLab justifican la complejidad
- Compliance enterprise o certificación ISO 27001: los logs de auditoría, las aprobaciones de MR con quórum y las políticas de push protegido son más maduras
- SAST / DAST integrado en el pipeline (requiere GitLab EE, pero algunos equipos prefieren consolidar en una única herramienta de pago)
- Review apps y entornos dinámicos por MR: GitLab CI lo gestiona nativamente; Gitea Actions requiere herramientas externas
- Runners de Kubernetes con autoescalado: GitLab dispone de un operador K8s dedicado y un executor nativo
- Wiki vinculada al repositorio con historial Git y renders de Mermaid / PlantUML integrados en la interfaz
Requisitos según la forja elegida
Gitea es frugal: 1 vCPU y 1 GB de RAM bastan para un equipo pequeño, 2 GB con la base de datos y algunos runners. GitLab CE es mucho más exigente: apunta como mínimo a 4 GB de RAM (8 GB recomendados en uso real con CI), 4 vCPU y un disco rápido, porque la suite incorpora PostgreSQL, Redis, Sidekiq y Gitaly. En ambos casos necesitas Docker y Compose, un subdominio (git.tudominio.com), un reverse proxy para el TLS e, idealmente, un segundo subdominio si activas el registro Docker.
Instalar Gitea en un VPS ServOrbit en 4 pasos
Preparar el volumen y la red Docker
En tu VPS ServOrbit, crea los directorios de datos y una red Docker aislada:
mkdir -p /srv/gitea/{data,db} && docker network create forge. Esta red permite que Gitea y PostgreSQL se comuniquen sin exponer la base de datos a la interfaz pública.Escribir el docker-compose.yml
Declara dos servicios:
gitea/gitea:latestmontado en/srv/gitea/dataypostgres:16-alpinemontado en/srv/gitea/db. Expón el puerto3000internamente y el puerto SSH de Git2222externamente. PasaGITEA__database__DB_TYPE=postgres,GITEA__server__DOMAINyGITEA__server__ROOT_URLcomo variables de entorno.Configurar el dominio y el SSL
En tu área de cliente ServOrbit, crea un registro DNS para
git.tudominio.comapuntando a la IP de tu VPS. Haz de proxy de ese subdominio con Caddy o Nginx hacia el puerto3000de Gitea. Caddy gestiona Let's Encrypt automáticamente; con Nginx, añade un bloque certbot. Verifica que se transmiteX-Forwarded-Proto: httpspara que las URL de clonado sean correctas.Crear el primer repositorio y conectar un runner CI
Ejecuta
docker compose up -d, luego accede ahttps://git.tudominio.com. El asistente de instalación se abre en la primera conexión: indica el tipo de base de datos (PostgreSQL), confirma el dominio y crea la cuenta de administrador. Para CI, instalaact_runner, regístralo en Administración > Runners y coloca tu primer.gitea/workflows/ci.ymlen un repositorio.
Desplegar Gitea (o GitLab) en un VPS con Docker
Crear los volúmenes y la red
Prepara
mkdir -p /srv/gitea/{data,db}y una red Docker dedicadadocker network create forge. La separación data/db facilita copias de seguridad diferenciadas del código y de la base de datos.Definir el docker-compose.yml
Para Gitea, declara el servicio
gitea/giteamás unpostgres, monta los volúmenes y expón el puerto HTTP3000y el puerto SSH de Git2222en local. Para GitLab, utilizagitlab/gitlab-cecon la variableGITLAB_OMNIBUS_CONFIGpara fijar laexternal_url.Arrancar y finalizar la instalación
Ejecuta
docker compose up -d. Gitea muestra un asistente de instalación en la primera conexión (indica el tipo de base de datos y el dominio); GitLab tarda varios minutos en inicializarse, recupera en los logs la contraseña root generada.Configurar el reverse proxy y el SSL
Haz de proxy de git.tudominio.com hacia el puerto HTTP de la forja con Caddy o Nginx para obtener un certificado Let's Encrypt. Asegúrate de transmitir el
X-Forwarded-Protocorrecto para que las URL de clonado HTTPS sean correctas.Activar el SSH de Git
Mapea el puerto SSH del contenedor hacia un puerto del VPS (por ejemplo, 2222) y configura tus claves. Rellena
SSH_DOMAINpara que los comandosgit cloneque propone la interfaz sean exactos.Conectar la CI/CD
Registra un runner: Gitea Actions (compatible con la sintaxis de GitHub Actions) o un GitLab Runner Docker. Limita sus recursos y aíslalo en su propio contenedor para que un job pesado no tumbe la forja.
Gitea vs GitLab CE: tabla comparativa
Desplace la tabla
| Criterio | Gitea | GitLab CE |
|---|---|---|
| RAM mínima recomendada | De 1 a 2 GB | De 4 a 8 GB |
| Arquitectura | Binario Go único | Suite multiservicio (omnibus) |
| Tiempo de arranque | Casi instantáneo | Varios minutos |
| CI/CD integrada | Gitea Actions (estilo GitHub) | GitLab CI/CD, muy completa |
| Registro Docker / paquetes | Incluido y ligero | Incluido, completo |
| Gestión de proyectos (incidencias, tableros) | Esencial | Avanzada (epics según la edición) |
| Facilidad de copia de seguridad | Carpeta + dump SQL | Procedimiento omnibus dedicado |
| Ideal para | VPS modesto, equipo pequeño/mediano | Plataforma DevOps completa |
Gitea + Woodpecker CI: el stack ligero para equipos de 1 a 15
Si Gitea Actions te parece demasiado cercano al ecosistema GitHub y quieres una CI estrictamente self-hosted sin dependencia de act, mira Woodpecker CI (un fork de Drone CI, licencia Apache 2.0). Se integra nativamente con Gitea vía OAuth, corre en Docker, y su sintaxis YAML es más explícita que GitHub Actions. El stack Gitea + Woodpecker CI consume menos de 300 MB de RAM en reposo en un VPS de 2 GB — frente a un mínimo de 4 GB para GitLab CE con CI activado. Para equipos de 1 a 15 desarrolladores con pipelines estándar, es la combinación self-hosted más frugal disponible.
En GitLab, evita el OOM-kill en un VPS pequeño reduciendo la concurrencia: pon puma['worker_processes'] a 2 y sidekiq['max_concurrency'] a 10 en la configuración omnibus. Si la RAM sigue siendo un problema, echa un vistazo a Forgejo (fork comunitario de Gitea), que conserva la ligereza y cubre el 90% de las necesidades de un equipo, registro y Actions incluidos.
