Gitea 28 en pymes: runners, auditoría y salida
Gitea 28 suma auditoría, cambios de Actions y retención de runs: guía real para instalar repos propios con permisos, backup y prueba de salida.
Tres cuentas SaaS para repos privados pueden costar menos que un servidor chico, hasta que el equipo necesita auditoría local, runners propios y salida ordenada. Para el responsable de sistemas de una metalúrgica en Maipú, Gitea 28 vale si reduce dependencia y deja pruebas de entrega. La decisión no empieza por instalar; empieza por saber qué repos, acciones, permisos y backups debe controlar la empresa.
Por qué Gitea 28 merece revisión antes de actualizar
El anuncio de Gitea 28.0.0 marca un cambio visible: el proyecto abandona el prefijo histórico 1.x y pasa a numerar 28.0.0. La versión incorpora auditoría, cuentas bot, deploy tokens con HTTPS, reglas de aprobación por code owners, filtros de archivos en diffs y una vista de cola para Actions. La noticia técnica pesa porque toca permisos, entrega y evidencia. La release en GitHub fue publicada el 29 de septiembre de 2026. Entre los cambios con impacto operativo aparecen Git 2.25 o superior, autorregistro apagado por defecto, reglas de salida de red para operaciones Git, workflows de Actions más estrictos y borrado de runs completados después de 400 días por defecto, salvo configuración distinta. El dato externo ayuda a medir el contexto. La encuesta Stack Overflow 2025 muestra un salto fuerte de Docker, con 17 puntos más de uso respecto de 2024. Esa adopción importa porque Gitea Actions suele ejecutar trabajos en contenedores, y el runner deja de ser una caja negra si sistemas mira imagen, token, cola y logs.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. Un usuario sube código a un repositorio, abre un issue o dispara un workflow. 2. Gitea guarda repositorios en disco y metadatos de usuarios, permisos, issues, paquetes y acciones en la base. 3. Gitea Actions lee archivos de workflow; la documentación oficial indica que la función está habilitada por defecto desde la versión 1.21. 4. El runner se registra con token, consulta trabajos en cola, ejecuta pasos en contenedor o máquina y devuelve logs. 5. La auditoría registra eventos de usuario, administración y repositorio cuando se activa la salida a base. 6. El backup copia configuración, base, repositorios, adjuntos, paquetes y logs; la restauración levanta otra instancia y regenera hooks. La frontera de permisos se define en repositorio, organización, equipo, rama protegida, token y runner. Un token de deploy no debería crear usuarios. Un runner compartido no debería compilar secretos de proyectos no relacionados. Una cuenta bot necesita dueño y rotación. La versión 28 no resuelve esas decisiones por sí sola; las vuelve visibles.
Qué se instala o configura primero
El primer entregable verificable es un mapa de repos y acciones. Incluye dueño, rama protegida, usuarios con escritura, secretos, runners, retención de runs y regla de backup. Una instalación inicial usa Gitea 28, base relacional, almacenamiento para repositorios, proxy HTTPS, runner separado, monitoreo de cola y prueba de restore. Tomando el dólar oficial vendedor informado por DolarAPI, una puesta en marcha de USD 420 a USD 880 equivale a ARS $646.800 a ARS $1.355.200. Ese costo cubre instalación, migración chica, permisos y prueba; no cubre reescritura de pipelines. UMSA puede comenzar con cinco repos reales y dos workflows: lint y empaquetado. El primer corte útil muestra un commit, un run, un artefacto, un log, una aprobación de código y una restauración documentada. Si un proyecto no puede salir de Gitea con repositorio, issues críticos y paquetes, todavía no está listo.
Dónde se rompe y cómo probarlo
El primer riesgo es actualizar sin revisar retención de runs. La señal aparece cuando un equipo busca logs de una entrega vieja y ya fueron eliminados. La prueba mínima es fijar días de retención y exportar una muestra mensual. El segundo riesgo es usar runners compartidos sin separación. La señal aparece cuando un workflow de pruebas puede leer secretos de otro proyecto. La prueba mínima es ejecutar un trabajo con permisos mínimos y comprobar variables disponibles. El tercer riesgo es activar auditoría sin política de espacio. La señal aparece cuando la base crece sin alerta. La prueba mínima es cargar eventos de prueba, medir volumen y definir retención. El cuarto riesgo es confiar en gitea dump sin ventana de parada. La guía de backup recomienda detener el servidor para consistencia cuando se usa ese comando. La prueba mínima es restaurar en otra máquina y abrir repos, issues y adjuntos. El quinto riesgo es dejar salida de red abierta para operaciones Git. La señal aparece cuando un repositorio puede forzar consultas a destinos no previstos. La prueba mínima es revisar reglas de egress y probar clones permitidos y bloqueados. Gitea tiene sentido cuando el equipo puede responder quién tocó código, qué acción corrió, dónde quedó el backup y cómo se recupera una entrega.
