Por qué esta pregunta es urgente en 2026
La CVE-2026-59774 se publicó el 4 de agosto de 2026. Afecta a Gitea desde la versión 1.22.1 hasta la 1.27.0 incluida — puntuación CVSS 9.9, 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., publicó su propio parche el mismo día a través de su rama de seguridad.
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 idéntica a la de Gitea Actions (compatible con GitHub Actions), compatible con Woodpecker CI y con los runners Docker, activa en Codeberg desde 2024
- 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 la integración SSO sin token permanente), endurecimiento SSRF activado por defecto para el mirroring Git, reducción de ancho de banda en los avatares
- 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: 4 GB de RAM como mínimo, 8 GB recomendados
- Cinco comparativas independientes publicadas en 2026 convergen en la misma jerarquía: 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: 4 GB de RAM es el mínimo absoluto para arrancar, 8 GB para un uso cómodo, con Postgres, Redis, Gitaly y Sidekiq funcionando en paralelo. Prevea al menos 4 vCPU y 50 GB de almacenamiento SSD. 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 | 512 MB – 1 GB | 4 GB (8 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: beta opt-in · Gitea: no previsto | No |
| Parches de seguridad independientes | Forgejo: sí (CVE-2026-59774 el mismo día) · Gitea: vía Gitea Ltd. | Vía GitLab Inc. |
| Novedades v16 (julio de 2026) | Forgejo: revisiones multilínea, JWT externo, SSRF por defecto · Gitea: 1.27.1 solo el parche | No aplica |
| Migración desde Gitea | Forgejo: mismo esquema de base de datos, un comando · GitLab: importación por API o migrador | 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. Ambos proyectos han compartido el mismo esquema de base de datos desde el origen y Forgejo mantiene la compatibilidad ascendente. 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 migración está probada desde las versiones recientes — una instancia muy antigua puede necesitar una actualización intermedia) y compruebe que sus runners de CI usan la misma sintaxis (Forgejo Actions y Gitea Actions son compatibles). La migración en sentido contrario — hacia GitLab CE — es más larga: GitLab ofrece una herramienta de importación por API (repositorios, issues, merge requests, 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).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:latest, un volumen persistente para/data, los puertos3000:3000(HTTP) 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. La interfaz de instalación está disponible enhttp://<ip-du-vps>:3000.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:
docker run -d --name forgejo-runner -v /var/run/docker.sock:/var/run/docker.sock codeberg.org/forgejo/runner:latest daemon --config config.yml.Verificar la seguridad básica (actualización v16)
Desde Forgejo v16.0, el endurecimiento SSRF está activo por defecto para el mirroring Git —
FORGEJO__migrations__ALLOW_LOCALNETWORKSestá enfalsepor defecto. Si necesita hacer mirroring hacia repositorios internos de la red local, debe activarlo explícitamente y evaluar su impacto. Compruebe también queFORGEJO__server__LOCAL_ROOT_URLno apunte a una IP interna expuesta. Para las instancias migradas desde Gitea afectadas por la CVE-2026-59774: invalideINTERNAL_TOKENySECRET_KEYenapp.ini, y después rote los tokens de acceso personales de sus usuarios.
Para una forja Gitea existente afectada por la CVE-2026-59774 (versiones 1.22.1 a 1.27.0): tanto la migración a Forgejo como la actualización a Gitea 1.27.1 corrigen la vulnerabilidad. Si opta por quedarse en Gitea, aplique el parche de inmediato. Si lleva tiempo planteándose Forgejo, la migración resuelve los dos problemas en una sola operación: parchee migrando, en lugar de actualizar y migrar después. Al migrar a Forgejo v16.0+, obtiene además el endurecimiento SSRF por defecto, 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, invalide INTERNAL_TOKEN y SECRET_KEY en app.ini tras cualquier sospecha de exposición, y rote los tokens de acceso personales de sus usuarios.
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— Forgejo busca las claves SSH en/data/gitea/.ssh; si el volumen no está montado o si los permisos son incorrectos, ejecutedocker compose exec forgejo forgejo admin regenerate keyspara regenerarlasx509: 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 bloquea por defecto el mirroring hacia direcciones de la red local (
FORGEJO__migrations__ALLOW_LOCALNETWORKS=false); si su mirror apunta a un GitLab o un Gitea interno, active la opción explícitamente y restrinja mediante lista blanca de IP
Qué herramienta elegir según su situación
Para una instalación nueva en 2026: Forgejo es la opción por defecto en la práctica totalidad de las comparativas independientes publicadas este año. La gobernanza comunitaria, los parches de seguridad independientes de Gitea Ltd. (ilustrados por la respuesta a la CVE-2026-59774 el mismo día de su publicación), 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. GitLab CE se impone cuando su equipo necesita toda la cadena DevOps en una sola instalación — escaneo de seguridad, pages, entornos de despliegue, métricas DORA — 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.
