Forgejo 15 en cooperativas: repos, permisos y salida
Caso anonimizado para alojar repositorios propios con Forgejo: Git, PostgreSQL, permisos, runners, backup y prueba de salida.
Una clave SSH de un proveedor siguio activa después de entregar el sistema de turnos. En una cooperativa electrica con internet rural, scripts de medidores, formularios web y configuraciones de routers vivian en carpetas ZIP compartidas. Forgejo 15.0.2 permite alojar repositorios Git propios, equipos, permisos y Actions. Este caso explica qué se guarda, quién puede cambiarlo, cómo se corre una prueba y que salida queda.
Donde un repositorio propio ordena cambios
El problema operativo aparece cuando el código de soporte depende de una cuenta externa. La cifra que ubica el mercado viene de Octoverse 2025: GitHub informo más de 180 millones de desarrolladores y 630 millones de repositorios. Una cooperativa no necesita ese volumen para sufrir el desorden. El detalle técnico también tiene fecha: Forgejo 15.0.2 fue publicado el 12 de mayo de 2026. Esa versión importa porque una instancia propia debe tener calendario de actualizacion, copia de base, copia de repositorios y prueba de permisos. El beneficio operativo no esta en alojar código por orgullo, sino en saber quién puede leer, subir, revisar y borrar.
El ZIP final que ya no explicaba nada
El antagonista es el archivo "sistema-final-v3.zip" enviado por un proveedor anterior y guardado en una carpeta compartida. En la oficina técnica, un router MikroTik apagado sobre un estante y una libreta de claves con hojas dobladas muestran el mismo problema: el cambio existe, pero su dueño no queda escrito. La guía de instalación binaria de Forgejo muestra usuario git, directorios, servicio y app.ini. La preparacion de base de datos cubre PostgreSQL, MariaDB y SQLite. La guía de Actions aclara que los jobs los ejecuta Forgejo Runner. La página de permisos de repositorio separa lectura, escritura y administración.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, sistemas crea organizaciones por área: medidores, atencion, redes y administración. Segundo, cada proyecto entra como repositorio Git con ramas protegidas. Tercero, Forgejo recibe commits, issues, revisiones y permisos. Cuarto, PostgreSQL guarda usuarios, equipos, repositorios, sesiones y auditoría de aplicación. Quinto, el filesystem guarda repositorios Git y adjuntos; S3 puede guardar LFS o artefactos. Sexto, Forgejo Runner toma workflows y ejecuta pruebas en un host controlado. Septimo, backup copia base, repos, app.ini, secretos y artefactos, y se prueba restaurando una rama. Forgejo recibe cambios de código y entrega historial, revisiones, permisos y estado de workflows. PostgreSQL recibe registros estructurados y entrega consultas internas. El almacenamiento recibe repositorios, adjuntos y artefactos. El permiso separa invitado, lector, escritor, mantenedor y administrador. Si falla Forgejo, se pierde interfaz y cola de trabajos. Si falla PostgreSQL, quedan repos sin contexto. Si falla Runner, las pruebas no corren.
Qué se instala o configura primero
La pila inicial usa Forgejo 15.0.2, PostgreSQL 18, usuario git, HTTPS, SMTP, organizaciones por área, repos privados, reglas de rama, runner aislado, backup diario y restauración mensual. El piloto cuesta entre USD 1.000 y USD 3.200, entre ARS 1,41 y ARS 4,52 millones al dólar vendedor oficial de $1.412 informado por Bluelytics. Incluye diez repositorios, veinte usuarios, permisos, runner y prueba. El plazo va de tres a cinco semanas. UMSA suele pedir un entregable verificable: repositorio migrado, proveedor sin acceso, rama protegida, merge revisado, job ejecutado, usuario lector y restauración en otro host. El costo no incluye reescritura de código, auditoría de seguridad profunda ni limpieza de secretos historicos. La primera prueba usa un script de lectura de medidores. Un técnico sube cambio en rama, otro revisa, el runner ejecuta prueba y gerencia mira el issue asociado. Un proveedor anterior intenta hacer push y recibe rechazo. Ese evento vale mas que una promesa de baja manual. La segunda prueba rota credenciales. Sistemas elimina una clave SSH, emite una nueva para un usuario nominal y revisa logs de acceso. Si el repositorio todavia acepta la clave vieja, el cierre de proveedor esta incompleto. La tercera prueba revisa salida de proveedor. Se exporta lista de usuarios, equipos, repositorios, ramas protegidas y llaves activas. Después se clona un repositorio desde una cuenta nueva y se recupera un issue con adjunto. Esa salida evita depender de memoria verbal cuando cambia el soporte.
Dónde se rompe y cómo probarlo Primer riesgo: repositorios privados con usuarios heredados.
La señal aparece cuando un proveedor viejo puede clonar. La prueba lista miembros, claves SSH y tokens antes de migrar. Segundo riesgo: runner con acceso a la red interna completa. La señal aparece cuando un job puede consultar servicios fuera de su tarea. La prueba ejecuta un workflow de control y exige bloqueo. Tercer riesgo: backup sin repositorios Git. La señal es una base restaurada que muestra proyectos pero no permite clonar. La prueba recupera PostgreSQL, repos y app.ini en otro host. Cuarto riesgo: secretos guardados en commits. La señal aparece en busquedas por patrones de token o contrasena. La prueba corre escaneo inicial y rota cualquier secreto encontrado. Un repositorio propio sirve cuando la salida también queda propia.