CI/CD a Forgejo: lecciones de la caída de GitHub de 2026

El 17 de agosto de 2026, a partir de las 9:40 hora de la Costa Este, GitHub sufrió un fallo de capacidad en su centro de datos de la zona Central US. La plataforma alcanzó un pico de tráfico que su infraestructura no absorbió: alrededor de un 20 % de errores en las experiencias web y en las llamadas de API, y hasta un 50 % en las descargas de archivos comprimidos. GitHub Actions fue uno de los servicios afectados de forma más duradera. El conjunto de los servicios no volvió a la normalidad hasta las 17:27, es decir 7 h 47 después del inicio del incidente — reconocido públicamente por GitHub el 20 de agosto de 2026.

DanubeData, una empresa de infraestructura de datos, publicó un informe de experiencia detallado: el incidente reveló una dependencia oculta de su plano de control respecto a GitHub. En respuesta, migraron 9 repositorios —333 pull requests y unos 400 MB de historial Git— a una instancia de Forgejo autoalojada, en una sola jornada. Su pipeline de build principal y su workflow de despliegue en producción siguieron a continuación.

La pregunta ya no es «¿puede caerse GitHub?», sino «¿cuál es nuestra exposición si ocurre?». Forgejo Actions responde a esa pregunta desplazando la ejecución de la CI/CD a su propia infraestructura.

Antes de empezar la instalación, compruebe que su VPS reúne los recursos siguientes.

RAM: 2 GB como mínimo para la forja sola, con 5 a 20 desarrolladores y repositorios de tamaño razonable. Cuente 4 GB si ejecuta Forgejo Actions con runners que compilan localmente (Go, Rust, Java).

vCPU: 2 vCPU bastan para un equipo de 20 desarrolladores. Añada 2 vCPU por runner simultáneo si sus builds son intensivos en CPU.

Disco: reserve al menos 20 GB de SSD para los repositorios, el historial Git, los artefactos de CI y los registros. Prevea 50 GB si aloja varios años de historial o artefactos binarios voluminosos.

Red: el puerto 22 sigue disponible en el host (SSH del sistema); el SSH de Forgejo se expondrá en un puerto distinto, por convención el 2222. El puerto 443 debe estar abierto para el reverse proxy.

Dominio: prepare un subdominio como git.sudominio.com con un registro A que apunte a la IP de su VPS.

Software: Docker 24+ y el plugin Compose instalados en el VPS.

Tras validar la ejecución de los pipelines, quedan tres puntos por configurar.

Webhooks y notificaciones: si algunos sistemas externos (Slack, Mattermost, un webhook de despliegue) escuchaban los eventos de GitHub, vuelva a crearlos en Forgejo en Ajustes → Webhooks. La carga útil es similar a la de GitHub, pero el formato difiere en algunos campos: ajuste sus endpoints de recepción.

Secretos de pipeline: los secretos de GitHub (menú Settings → Secrets) deben recrearse en Forgejo en Ajustes del repositorio → Actions → Secrets. Para los secretos de organización, utilice Administración → Organizaciones → [su org] → Ajustes → Actions → Secrets. No migre nunca un secreto por su valor en un commit ni en un archivo versionado.

Permisos de los runners: por defecto, un runner registrado a nivel de instancia puede ejecutar workflows para todos los repositorios. Para un control más fino, restrinja un runner a una organización o a un repositorio concreto en la pestaña Runners de los ajustes correspondientes.

504 Gateway Timeout durante la migración de un repositorio. Forgejo realiza la importación de forma síncrona dentro de la petición HTTP. Si el reverse proxy corta la conexión antes del final, la migración se interrumpe y el repositorio queda en estado «Migración en curso». Aumente proxy_read_timeout a 600 s (Nginx) o añada timeouts { read_body 10m } (Caddy) antes de lanzar la migración. Elimine después el repositorio incompleto y vuelva a lanzarla.

Runner stays Offline after startup. Compruebe que FORGEJO_INSTANCE_URL apunta a la URL HTTPS pública de su instancia, y no a localhost ni a la IP interna del contenedor. El runner debe alcanzar Forgejo por el mismo camino que un navegador externo.

Workflow not triggered after push. Compruebe que los archivos de workflow están en .forgejo/workflows/ y no en .github/workflows/. Forgejo no lee el directorio .github/.

Error: this step uses an action, but the runner does not support actions. Algunas acciones de terceros referenciadas por uses: llaman a la API de GitHub. Sustitúyalas por un equivalente disponible en Codeberg o replíquelas en su instancia.

permission denied en un script al final de un job. La imagen base del runner (Debian bookworm) no contiene las mismas utilidades que la imagen Ubuntu de GitHub. Añada un paso apt-get install -y <herramienta> al principio del job, o especifique una imagen Docker personalizada mediante container:.

Esta guía cubre la instalación y la migración de su CI/CD a Forgejo Actions. Para ir más lejos, los artículos siguientes tratan temas complementarios: el alojamiento inicial de Forgejo en un VPS con Docker y SSL, la puesta en marcha de un pipeline Woodpecker CI como complemento de Forgejo, y la migración de sus repositorios de GitHub a una forja Git autoalojada.

Alojar Forgejo en su propio VPS — instalación completa, reverse proxy y primer runner.

Pipeline Woodpecker CI en un VPS con Forgejo — alternativa a Forgejo Actions para los equipos que quieren separar la forja y el motor de CI.

Migrar sus repositorios de GitHub a Gitea o Forgejo en un VPS — procedimiento de migración paso a paso con la herramienta oficial.