Gitea 1.26 en pymes: repos, permisos y respaldo
Guía para administrar repositorios internos con Gitea 1.26, equipos, permisos por repositorio, paquetes, CI y restauración probada.
¿Quién puede borrar el repositorio qué guarda el script de facturación? Esa pregunta aparece cuando una pyme ya tiene código, planillas versionadas, archivos de configuración y automatizaciones repartidas entre computadoras personales. Gitea 1.26 permite alojar repositorios Git, equipos, permisos, paquetes y tareas CI en servidor propio. Esta guía explica cómo separar lectura, escritura, administración y respaldo antes de mover trabajo sensible. ## Dónde aparece el repositorio que todos tocan Gitea publicó la versión 1.26.4 el 21 de junio de 2026. Su repositorio registraba 56.761 estrellas al momento de esta corrida, según la API pública de GitHub. La cifra muestra una comunidad grande, con código y reportes visibles, alrededor de una necesidad concreta: alojar Git sin entregar toda la administración a un tercero. La carpeta compartida llamada scripts-viejo corta la trazabilidad. El dato global acompaña la decisión local. La encuesta 2025 de Stack Overflow reunió más de 49.000 respuestas de 177 países y ubicó Git y GitHub entre las herramientas de colaboración más usadas. Una pyme puede bajar esa práctica a un alcance chico: cada cambio de código, consulta SQL o playbook debe tener autor, revisión y salida de respaldo. En una clínica privada de Godoy Cruz, el problema puede empezar con algo menor: un script que genera reportes, una configuración de proxy, un archivo de migración y una tarea nocturna. Si esos archivos viven en un escritorio compartido, nadie sabe qué versión llegó a producción. El archivo que reinicia un servicio también necesita revisión cuando afecta facturación, turnos o datos de pacientes.
Cómo funciona por dentro
El flujo empieza cuando IT crea una organización y separa equipos por función. Gitea recibe usuario, clave o identidad externa; entrega sesión, repositorios y permisos. Git guarda historial, ramas, etiquetas y cambios. La base guarda usuarios, equipos, repositorios, issues, pull requests, paquetes y auditoría. El almacenamiento conserva adjuntos, avatares, paquetes y repositorios Git. Gitea Actions ejecuta tareas cuando un commit o etiqueta dispara un flujo. La documentación de permisos separa acceso de lectura, escritura y administración por unidades del repositorio. Esa distinción permite que soporte lea un playbook, desarrollo cambie código y administración vea releases sin tocar ramas protegidas. El commit con dueño evita la discusión posterior. El circuito recomendado tiene seis pasos. Primero, se crean equipos: lectura, desarrollo, revisión y administración. Segundo, se migran tres repositorios de bajo riesgo. Tercero, cada cambio entra por rama y pull request. Cuarto, una tarea CI ejecuta una prueba simple. Quinto, un release guarda etiqueta y paquete. Sexto, el backup copia base, repositorios, configuración y adjuntos; la restauración abre un repositorio y verifica historial.
Qué se instala o configura primero
La instalación conservadora usa Docker Compose, Gitea 1.26, PostgreSQL 17, almacenamiento persistente, SMTP, TLS y backup externo. La guía de instalación con Docker muestra el servicio web, el volumen de datos y la base. La guía de backup y restauración describe el comando dump y la recuperación de una instancia. Con dólar oficial vendedor a $ 1510, una VM de USD 20 ronda $ 30.200 mensuales antes de impuestos, dominio, soporte y almacenamiento remoto. El primer entregable verificable toma dos o tres días: login, cuatro usuarios, dos equipos, tres repositorios, una regla de rama protegida, un pull request, un paquete y una restauración documentada. UMSA suele arrancar con repositorios que ya tienen uso operativo, pero bajo riesgo: scripts de reportes, plantillas de infraestructura y consultas SQL revisables. Esa muestra alcanza para probar permisos, historial y salida sin tocar el sistema principal. La política mínima entra por escrito. Cada repositorio necesita dueño, rama estable, regla de revisión, etiqueta de release y frecuencia de backup. Cuando un proveedor deja de trabajar, se lo quita del equipo, se revisan llaves SSH y se rotan tokens.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en permisos de administración. La señal es un usuario de soporte que puede borrar repositorios o cambiar ramas protegidas. La prueba crea usuarios de lectura, escritura y administración; luego intenta borrar, mezclar y etiquetar desde cada perfil. El segundo riesgo aparece en CI. La señal es una tarea que corre con secretos demasiado amplios. La prueba crea un secreto de prueba, ejecuta un flujo y confirma que el log no muestra valores sensibles ni permite escribir fuera del repositorio. El tercer riesgo aparece en restauración. La señal es una instancia que abre usuarios, pero pierde historial o adjuntos. La prueba toma un dump, restaura en otro servidor, clona un repositorio, abre un pull request viejo y descarga un paquete. El archivo más peligroso es el que nadie reconoce como código de producción. Gitea sirve cuando puede decir quién lo cambió, quién lo aprobó y cuánto tarda en volver.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.