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 despues 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 que se guarda, quien puede cambiarlo, como se corre una prueba y que salida queda.
Donde un repositorio propio ordena cambios
El problema operativo aparece cuando el codigo de soporte depende de una cuenta externa. La cifra que ubica el mercado viene de Octoverse 2025: GitHub informo mas de 180 millones de desarrolladores y 630 millones de repositorios.
Una cooperativa no necesita ese volumen para sufrir el desorden.
El detalle tecnico tambien tiene fecha: Forgejo 15.0.2 fue publicado el 12 de mayo de 2026. Esa version 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 codigo por orgullo, sino en saber quien 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 tecnica, 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 guia de instalacion binaria de Forgejo muestra usuario git, directorios, servicio y app.ini. La preparacion de base de datos cubre PostgreSQL, MariaDB y SQLite. La guia de Actions aclara que los jobs los ejecuta Forgejo Runner. La pagina de permisos de repositorio separa lectura, escritura y administracion.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, sistemas crea organizaciones por area: medidores, atencion, redes y administracion. 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 auditoria de aplicacion. 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 codigo 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.
Que se instala o configura primero
La pila inicial usa Forgejo 15.0.2, PostgreSQL 18, usuario git, HTTPS, SMTP, organizaciones por area, repos privados, reglas de rama, runner aislado, backup diario y restauracion mensual. El piloto cuesta entre USD 1.000 y USD 3.200, entre ARS 1,41 y ARS 4,52 millones al dolar 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 restauracion en otro host. El costo no incluye reescritura de codigo, auditoria de seguridad profunda ni limpieza de secretos historicos.
La primera prueba usa un script de lectura de medidores. Un tecnico 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. Despues 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.
Donde se rompe y como probarlo
Primer riesgo: repositorios privados con usuarios heredados. La senal 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 senal 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 senal 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 senal 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 tambien queda propia.