Por qué esta pregunta es urgente en 2026
La CVE-2026-59774 se publicó el 2 de agosto de 2026 en el aviso de seguridad de Gitea. Afecta a Gitea desde la versión 1.22.1 hasta la 1.27.0 incluida — puntuación CVSS 9.8, crítica. El vector: la directiva #+INCLUDE del renderizado Org-mode permite a un atacante no autenticado leer archivos arbitrarios accesibles para la cuenta de servicio de Gitea, incluidos app.ini y los tokens internos. La exposición de INTERNAL_TOKEN abre después la vía a una inyección de hook Git y a la ejecución remota de código. La corrección está en la versión 1.27.1. Si su instancia funciona con una versión anterior y no está aislada de la red pública, parchear es la primera acción. La segunda es decidir si se queda en Gitea o si la situación acelera una migración que venía posponiendo. Forgejo, que mantiene sus propios parches de seguridad de forma independiente de Gitea Ltd., ya había corregido el mismo fallo del renderizado Org-mode en sus versiones v16.0.2 y v15.0.6, publicadas el 30 de julio de 2026, antes del aviso de Gitea.
Lo que ha cambiado desde 2024 y pesa en esta elección
- Forgejo es un fork duro desde principios de 2024 — la base de código ha divergido de Gitea; ambos proyectos comparten todavía lo esencial, pero las trayectorias de evolución difieren ya claramente
- Gobernanza comunitaria en Forgejo — gestionado por una asociación sin ánimo de lucro, sin acuerdo de contribución firmado con una empresa matriz; los parches de seguridad llegan de forma independiente
- Forgejo Actions en producción — sintaxis cercana a la de GitHub Actions, como Gitea Actions (Forgejo advierte que un workflow de GitHub suele requerir algunos retoques), ejecutada por runners Docker; Woodpecker CI sigue siendo una alternativa que se integra con Forgejo, y Codeberg todavía ofrece Actions alojado solo de forma limitada
- Forgejo v16.0 en julio de 2026 — comentarios de revisión multilínea (selección de un rango de líneas en el diff, hilos inline), autenticación JWT externa para la API (permite que sistemas externos se autentiquen sin token permanente), endurecimiento SSRF del mirroring Git (las reglas
[migrations]se aplican en todas partes y Git ya no sigue las redirecciones), reducción de ancho de banda en los avatares; rama no LTS, sin mantenimiento desde el 29 de octubre de 2026: sus novedades continúan en Forgejo v17.0 (octubre de 2026) - Forgejo v15.0 en abril de 2026 — flujo de registro de runner simplificado desde la interfaz web, tokens restringidos por repositorio, versión 100 de Forgejo
- GitLab CE sigue siendo completo pero pesado — la versión comunitaria integra CI/CD, registro de contenedores, escaneo de seguridad y Pages; el precio: 8 GB de RAM como mínimo, 16 GB recomendados
- La jerarquía que se perfila en 2026: Forgejo para empezar, Gitea si ya está en él y actualizado, GitLab CE si necesita una plataforma DevOps completa en una sola instalación
Requisitos previos según su elección
Forgejo y Gitea están escritos en Go y se distribuyen como un único binario estático. Una instancia modesta (hasta veinte repositorios, unos pocos runners de CI) funciona con holgura en 1 vCPU y 1 GB de RAM; una instancia de equipo (runners de CI activos, LFS, registro de paquetes) preferirá 2 vCPU y de 2 a 4 GB. GitLab CE está en otra categoría: su documentación fija el mínimo en 8 GB de RAM y recomienda 16 GB, con Postgres, Redis, Gitaly y Sidekiq funcionando en paralelo. Prevé 8 vCPU y al menos 40 GB de almacenamiento SSD para la aplicación, más el tamaño de sus repositorios. Para las tres herramientas necesitará un dominio apuntando a su VPS, los puertos 22 (SSH Git), 80 y 443 abiertos, y un reverse proxy (Nginx o Caddy) para el HTTPS.
Forgejo vs Gitea vs GitLab CE — tabla comparativa 2026
Desplace la tabla
| Criterio | Forgejo / Gitea | GitLab CE |
|---|---|---|
| RAM mínima | Sin mínimo oficial (1 GB para un equipo pequeño) | 8 GB (16 GB recomendados) |
| Formato de distribución | Binario estático único o imagen Docker | Omnibus (multiproceso) o Helm chart |
| CI/CD nativo | Forgejo Actions / Gitea Actions (sintaxis GitHub Actions) | GitLab CI/CD integrado, runners compartidos o dedicados |
| Gobernanza | Forgejo: asociación sin ánimo de lucro (Codeberg) · Gitea: Gitea Ltd. | GitLab Inc. (open-core, CE libre) |
| Registro de contenedores | Sí (packages + container registry) | Sí, más completo |
| Federación / ActivityPub | Forgejo: experimental, desactivada por defecto · Gitea: no previsto | No |
| Parches de seguridad independientes | Forgejo: sí (fallo Org-mode corregido en v16.0.2, julio de 2026) · Gitea: vía Gitea Ltd. | Vía GitLab Inc. |
| Novedades v16 (julio de 2026) | Forgejo: revisiones multilínea, JWT externo, SSRF reforzado · Gitea: 1.27.1 solo el parche | No aplica |
| Migración desde Gitea | Forgejo: retoma directa de la base de datos hasta Gitea 1.22, después migración repositorio por repositorio · GitLab: importador de Gitea | Importación parcial (repositorios, issues, PR) |
| Ideal para | Equipos de 1 a 50 desarrolladores, VPS modesto, CI ligera | Organización que quiere todo en una sola instalación, con presupuesto de infraestructura disponible |
Migrar de Gitea a Forgejo: en qué consiste realmente
La migración Gitea → Forgejo suele describirse como «un comando» — y es cierto en el caso simple. Pero solo hasta Gitea 1.22: Forgejo indica que Gitea 1.22 es la última versión que se retoma de forma transparente. Desde Gitea 1.23, los esquemas de base de datos han divergido, y la vía oficial consiste en migrar los repositorios uno a uno con la herramienta de migración integrada en Forgejo. Para una instancia en 1.22.x como máximo, el procedimiento se resume en detener el contenedor Gitea, apuntar el mismo volumen de datos hacia una imagen Forgejo y arrancar. Forgejo detecta el esquema existente y aplica sus propias migraciones. Algunos puntos que conviene verificar antes: haga una copia de seguridad de app.ini y de la base de datos, anote la versión de Gitea en uso (la retoma pasa primero por Forgejo v10.0 y después a una versión más reciente) y revise sus workflows de CI (Forgejo Actions y Gitea Actions tienen sintaxis cercanas: pruébelos en un repositorio antes de cambiar). La migración en sentido contrario — hacia GitLab CE — es más larga: GitLab ofrece un importador de Gitea (repositorios, issues, pull requests, hitos, etiquetas), pero los pipelines de CI deben reescribirse en sintaxis GitLab CI.
Desplegar Forgejo en un VPS con Docker y Nginx
Preparar el VPS
Actualice el sistema e instale Docker y Docker Compose:
apt update && apt install -y docker.io docker-compose-plugin. Abra los puertos necesarios:ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp && ufw allow 2222/tcp(2222 para SSH Git si no quiere exponer el puerto 22 del sistema). Atención: los puertos publicados por Docker eluden las reglas de ufw; publique solo lo que deba publicarse (paso siguiente).Crear los directorios y el archivo Compose
Cree un directorio dedicado:
mkdir -p /opt/forgejo && cd /opt/forgejo. Después, cree un archivocompose.ymlcon un servicioforgejoque apunte a la imagencodeberg.org/forgejo/forgejo:17(etiqueta de versión mayor, como en la documentación oficial), un volumen persistente para/data, los puertos127.0.0.1:3000:3000(HTTP, accesible solo para Nginx) y2222:22(SSH), y unas variables de entorno mínimas (FORGEJO__server__DOMAIN=git.votre-domaine.com,FORGEJO__server__SSH_PORT=2222).Arrancar Forgejo
Lance el servicio:
docker compose up -d. Compruebe que el contenedor está activo condocker compose psy consulte los registros condocker compose logs -f forgejo. El puerto 3000 solo escucha en la propia máquina: compruébelo concurl -I http://127.0.0.1:3000, y no complete el asistente de instalación hasta tener el HTTPS en marcha (paso 6), para que nadie lo complete antes que usted.Configurar Nginx como reverse proxy HTTPS
Instale Nginx y Certbot:
apt install -y nginx python3-certbot-nginx. Cree un virtual host paragit.votre-domaine.comque haga de proxy haciahttp://localhost:3000con las cabeceras proxy estándar (proxy_set_header Host $host,proxy_set_header X-Real-IP $remote_addr,proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for,proxy_set_header X-Forwarded-Proto $scheme).Obtener el certificado TLS
Ejecute
certbot --nginx -d git.votre-domaine.com. Certbot configura la redirección HTTP→HTTPS y programa la renovación automática. Compruebe concurl -I https://git.votre-domaine.comque el código es efectivamente200.Finalizar la instalación desde la interfaz web
Abra
https://git.votre-domaine.comen un navegador. El asistente de instalación le pide el tipo de base de datos (SQLite para empezar, PostgreSQL para producción), la URL de la instancia y los parámetros SSH. Cree la cuenta de administrador y luego desactive los registros públicos si la instancia es privada (FORGEJO__service__DISABLE_REGISTRATION=trueencompose.yml).Activar un runner de CI (opcional)
Forgejo v15.0 (abril de 2026) introdujo un flujo de registro de runner simplificado desde la interfaz web. Vaya a Configuración del sitio → Actions → Runners, haga clic en Crear un runner y copie el comando de registro. Lance el runner en un segundo contenedor, junto a un servicio
docker:dindque ejecuta los jobs, como en el ejemplo Compose de la documentación oficial (imagendata.forgejo.org/forgejo/runner:13, comandoforgejo-runner daemon --config runner-config.yml). Evite montar/var/run/docker.sock: los workflows obtendrían el equivalente a un acceso root al host.Verificar la seguridad básica (actualización v16)
Forgejo v16.0 endureció la protección SSRF del mirroring Git: los ajustes
[migrations](ALLOWED_DOMAINS,BLOCKED_DOMAINS,ALLOW_LOCALNETWORKS) se aplican ahora a todas las operaciones de migración y de mirroring, y Git ya no sigue las redirecciones HTTP.FORGEJO__migrations__ALLOW_LOCALNETWORKSsigue enfalsepor defecto: si necesita hacer mirroring hacia repositorios internos de la red local, declárelos enFORGEJO__migrations__ALLOWED_DOMAINSen lugar de abrir toda la red local, y evalúe su impacto. DejeFORGEJO__server__LOCAL_ROOT_URLen su valor por defecto (la dirección local por la que los procesos internos llegan al servicio web), salvo si el SSH funciona en otra máquina. Para las instancias migradas desde Gitea afectadas por la CVE-2026-59774: regenereINTERNAL_TOKEN(forgejo generate secret INTERNAL_TOKEN) y después rote los tokens de acceso personales de sus usuarios. No sustituyaSECRET_KEYa la ligera: cifra, entre otros, los secretos 2FA, que la nueva clave ya no podría descifrar.
Para una forja Gitea existente afectada por la CVE-2026-59774 (versiones 1.22.1 a 1.27.0): la actualización a Gitea 1.27.1 o a una versión posterior corrige la vulnerabilidad, y es lo primero que hay que hacer. Migrar a Forgejo solo es un atajo desde Gitea 1.22.x, la última versión cuya base de datos retoma Forgejo; desde Gitea 1.23, parchee primero Gitea y después migre repositorio por repositorio si opta por Forgejo. Al migrar a Forgejo v16.0+, obtiene además el endurecimiento SSRF del mirroring, los comentarios de revisión multilínea y la autenticación JWT externa — funcionalidades no disponibles en Gitea 1.27.1. En todos los casos, tras cualquier sospecha de exposición, regenere INTERNAL_TOKEN, rote los tokens de acceso personales de sus usuarios y sus secretos OAuth, y cambie SECRET_KEY solo sabiendo que los secretos 2FA cifrados con la clave antigua quedarán ilegibles.
Resolución de problemas: errores frecuentes en la instalación
Los errores que figuran a continuación cubren los casos más frecuentes durante un primer despliegue o una migración.
Errores habituales y sus soluciones
level=fatal msg="Failed to initialize ORM engine" error="Error 1071: Specified key was too long"(MySQL/MariaDB) — la colación de la base de datos no esutf8mb4: cree la base de datos conCHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ciy reinicieFailed to initialize SSH: ssh: no key found— una clave de host SSH está vacía o es ilegible: compruebe que el volumen/dataestá montado y pertenece al UID/GID declarados en el Compose (1000:1000 por defecto), y después elimine el archivo de clave vacío y reinicie el contenedor para que se vuelva a crear;forgejo admin regenerate keyssolo regenera el archivoauthorized_keysx509: certificate signed by unknown authorityen los webhooks salientes — su instancia llama a un servicio interno con un certificado autofirmado; añadaFORGEJO__webhook__SKIP_TLS_VERIFY=trueúnicamente en desarrollo, o monte el certificado CA en el contenedor medianteSSL_CERT_FILEError response from daemon: conflict: unable to delete imagedurante una actualización — detenga primero el contenedor (docker compose down), elimine la imagen (docker image rm codeberg.org/forgejo/forgejo) y vuelva a descargarla (docker compose pull) antes de reiniciar- Runners de CI bloqueados en
waiting for available runnertras el registro — compruebe que el runner puede alcanzar la instancia Forgejo:curl -s https://git.votre-domaine.com/api/v1/versiondesde el contenedor del runner debe devolver un JSON con la versión; si el nombre de dominio no se resuelve desde el contenedor, añada unextra_hostsen el Compose o use la IP del VPS - Mirroring de repositorio rechazado tras la migración a v16 — Forgejo v16.0 aplica estrictamente los ajustes
[migrations], conFORGEJO__migrations__ALLOW_LOCALNETWORKS=falsepor defecto: un mirror hacia una dirección de la red local, o servido tras una redirección HTTP, puede ser rechazado; si su mirror apunta a un GitLab o un Gitea interno, declare su dominio enFORGEJO__migrations__ALLOWED_DOMAINSen lugar de abrir toda la red local
Qué herramienta elegir según su situación
Para una instalación nueva en 2026: Forgejo es la opción por defecto que recomendamos. La gobernanza comunitaria, los parches de seguridad independientes de Gitea Ltd. (ilustrados por el fallo Org-mode de la CVE-2026-59774, corregido en Forgejo desde el 30 de julio de 2026), la compatibilidad con las herramientas existentes (runners, webhooks, tokens) y una huella de memoria idéntica a la de Gitea reúnen todos los argumentos sin contrapartida destacable para un proyecto nuevo. Con Forgejo v16.0, los comentarios de revisión multilínea y la autenticación JWT externa cubren dos carencias funcionales que a veces justificaban la elección de GitLab CE. Si ya explota una instancia Gitea actualizada (1.27.1+) y responde a sus necesidades, la migración no es urgente — pero la próxima vez que se plantee una actualización mayor, evalúe Forgejo en ese momento, teniendo en cuenta que desde Gitea 1.23 el paso se hace repositorio por repositorio. GitLab CE se impone cuando su equipo necesita toda la cadena DevOps en una sola instalación — escaneo de seguridad, pages, entornos de despliegue, registro de contenedores — y usted dispone de la infraestructura para hacerlo funcionar con holgura. En un VPS modesto, no es la herramienta adecuada. Para ir más lejos: nuestra guía de instalación detallada de Forgejo, la puesta en marcha de un pipeline de CI con Woodpecker y el artículo sobre el endurecimiento inicial de un servidor Linux completan esta comparativa.
