Categoría: Desarrollo
Gitea gestionado: Git ligero y CI propio en vuestro servidor
Repositorios, revisiones de código y pipelines en una sola aplicación que cabe en un servidor pequeño, con copias que restauramos de verdad y actualizaciones sin sobresaltos.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source, MIT
En resumen
Gitea es una forja de código ligera escrita en Go que reúne repositorios Git, incidencias, pull requests, paquetes y CI en un solo binario. Lo instalamos en vuestra cuenta o en vuestro servidor, lo conectamos con vuestro inicio de sesión, montamos los runners de Gitea Actions, hacemos copias completas que restauramos en pruebas y lo mantenemos actualizado.
¿Qué nos encargamos de mantener?
Gitea arranca en un minuto y por eso muchas veces se queda tal cual: un contenedor con SQLite, sin copias y con el runner en la misma máquina. Mientras el equipo es de tres personas no pasa nada. Cuando el código de la empresa vive ahí, cada pieza necesita a alguien detrás:
Repositorios
Almacenamiento en disco dimensionado, con recolección de basura de Git y avisos antes de que se llene.
Base de datos
PostgreSQL para usuarios, incidencias y pull requests, con copias independientes de las de los repositorios.
Runners de Actions
act_runner en máquinas separadas, con contenedores aislados por trabajo y limpieza de imágenes.
Acceso
SSH, HTTPS, tokens y claves de despliegue, con inicio de sesión único y doble factor.
Paquetes
Registro de contenedores, npm, Maven y otros formatos, con políticas para no guardar cada versión para siempre.
Vigilancia
Disco, certificados, cola de tareas internas y runners que dejan de responder.
¿Qué arquitectura recomendamos?
Gitea no necesita una plataforma grande. La separación que sí merece la pena es entre la forja y lo que ejecuta código ajeno:
Proxy inverso
Termina HTTPS, limita el tamaño de las subidas y deja pasar el SSH de Git por su puerto.
Gitea
Un solo proceso que sirve la web, la API y Git. Los repositorios van en un volumen propio, no en el disco del sistema.
PostgreSQL
Gestionada por el proveedor o montada por nosotros, con copias aparte. SQLite solo para pruebas.
Runners
act_runner en otra máquina: un pipeline que se descontrola no debe tumbar la forja ni leer sus datos.
Los adjuntos, los artefactos de Actions y los paquetes los mandamos a almacenamiento de objetos compatible con S3 cuando crecen, para que el disco del servidor solo guarde los repositorios.
¿Qué problemas encontramos en un Gitea self-hosted?
- SQLite con todo el equipo encima: bloqueos de escritura cuando varias personas comentan y fusionan a la vez.
- Runner en el mismo servidor: un trabajo que llena el disco con imágenes deja sin espacio a los repositorios.
- Registro de paquetes sin limpieza: cada compilación sube una imagen nueva y nadie borra las viejas.
- Puerto SSH en conflicto: el SSH del sistema y el de Gitea compiten y los
git pushfallan sin un mensaje claro. - Versiones saltadas: se pasa de una versión muy antigua a la última de golpe y la migración de la base de datos se queda a medias.
- Usuarios locales que nadie da de baja: sin conexión con el directorio, quien se va conserva su acceso al código.
¿Cómo hacemos las copias y las actualizaciones?
Gitea trae gitea dump, que empaqueta repositorios, base de datos, configuración y adjuntos. Lo usamos en instancias pequeñas; en las grandes copiamos por separado la base de datos con su herramienta nativa y los repositorios con una copia incremental, porque un volcado completo diario de varios cientos de gigas no tiene sentido. En los dos casos la copia sale del servidor y, cada cierto tiempo, levantamos una instancia aparte desde ella, clonamos un repositorio y abrimos una pull request para comprobar que todo encaja.
Gitea publica versiones menores con correcciones a menudo y una mayor cada pocos meses. Leemos las notas, actualizamos primero una copia de vuestra instancia, comprobamos que los runners siguen conectando y después actualizamos producción en una ventana avisada. Si vais varias versiones por detrás, avanzamos de mayor en mayor, sin atajos.
¿Cómo protegemos la instancia?
Desactivamos el registro abierto, obligamos al doble factor o lo delegamos en vuestro Keycloak por OpenID Connect y revisamos qué repositorios son públicos. Los runners ejecutan cada trabajo en un contenedor desechable, sin acceso a la red interna salvo lo imprescindible, y los secretos de Actions se guardan por repositorio u organización, nunca en el código. Si Gitea no tiene que verse desde internet, lo dejamos detrás de la VPN.
¿Cómo migramos desde GitLab o GitHub?
Gitea tiene un asistente de migración que trae cada repositorio con su historial y, si el origen lo permite, sus incidencias, pull requests, etiquetas y versiones. Preparamos antes la lista de organizaciones, equipos y permisos, porque esa estructura no se traslada sola. Los pipelines de GitLab CI hay que reescribirlos como workflows de Actions; los de GitHub Actions suelen funcionar con pocos cambios. Mantenemos el origen en solo lectura unos días hasta que nadie lo echa de menos.
Si lo que necesitáis es la plataforma completa, con despliegues incluidos, está en plataforma interna y PaaS. Si todavía dudáis entre las dos forjas, la página de GitLab self-hosted gestionado os ayuda a comparar.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Un servidor cloud para Gitea y PostgreSQL, y otro para los runners. Repositorios en un volumen y copias a Object Storage de Hetzner, compatible con S3. | Gitea consume poco: un servidor modesto da para un equipo entero. Lo que más crece es el disco de los repositorios. |
| AWS | Gitea en EC2 con volumen EBS, RDS for PostgreSQL y S3 para adjuntos, paquetes y copias. | Los runners pueden ir en instancias spot si los trabajos aguantan una interrupción. |
| Google Cloud | Compute Engine con disco persistente, Cloud SQL para PostgreSQL y Cloud Storage para adjuntos y copias. | Encaja si el resto de vuestra plataforma ya vive en Google Cloud. |
| Azure | Máquina virtual con disco administrado, Azure Database for PostgreSQL y Blob Storage para las copias. | El inicio de sesión se conecta con Microsoft Entra ID por OpenID Connect. |
| DigitalOcean | Droplet con Gitea, base de datos PostgreSQL gestionada y Spaces para adjuntos y copias. | |
| OVH | Instancia de Public Cloud, base de datos gestionada de OVHcloud y Object Storage para las copias. | |
| Servidor propio | Gitea y PostgreSQL en contenedores en vuestro servidor o en una máquina virtual, junto a vuestro directorio. | Si el acceso es solo interno, lo dejamos detrás de la VPN y publicamos, como mucho, los webhooks que lo necesiten. |
Qué incluye
- Gitea en vuestra cuenta cloud o en vuestro servidor, a nombre de vuestra empresa, con la configuración (app.ini) en vuestro repositorio.
- PostgreSQL como base de datos en lugar de SQLite cuando el equipo ya trabaja a diario con la instancia.
- Runners de Gitea Actions (act_runner) en máquinas separadas, con etiquetas por tipo de trabajo.
- Acceso por SSH y HTTPS detrás de un proxy inverso, con inicio de sesión por OpenID Connect o LDAP.
- Registro de paquetes y contenedores activado si lo usáis, con limpieza de versiones antiguas.
- Copias diarias de repositorios, base de datos y adjuntos, con restauración de prueba periódica.
- Actualizaciones siguiendo las notas de cada versión, probadas antes en una copia.
- Migración de repositorios, incidencias y pull requests desde GitLab, GitHub u otra forja.
Preguntas frecuentes
¿Gitea es una buena alternativa ligera a GitLab?
Para muchos equipos, sí. Ofrece repositorios, revisiones, incidencias, paquetes y CI con muchos menos recursos y menos piezas que mantener. Se queda corto si necesitáis planificación de cartera, análisis de seguridad integrado o permisos muy finos entre cientos de grupos; ahí GitLab tiene más recorrido.
¿Sirven nuestros workflows de GitHub Actions en Gitea Actions?
En buena parte, porque la sintaxis es compatible y muchas acciones públicas funcionan tal cual. Hay diferencias: algunas acciones dependen de la API de GitHub y no todas las opciones están implementadas. Revisamos vuestros workflows uno a uno y adaptamos los que fallan.
¿Gitea o Forgejo?
Forgejo es una bifurcación comunitaria de Gitea que hoy sigue su propio camino, con su propio calendario de versiones y su propio gobierno. Para el uso diario se parecen mucho. Mantenemos cualquiera de los dos; si ya tenéis uno, lo normal es seguir con él, y si empezáis de cero lo hablamos según qué os pese más.
¿Podemos traer los repositorios desde GitLab o GitHub sin perder el historial?
Sí. La migración de Gitea copia el historial completo de Git y, según el origen, también incidencias, pull requests, etiquetas, hitos y versiones publicadas. Lo que no viaja solo son los pipelines, las variables secretas y los webhooks, que preparamos aparte.
¿Quién gestiona los usuarios y los permisos?
La persona administradora de vuestra empresa, desde Gitea o desde vuestro directorio si está conectado por LDAP u OpenID Connect. Nosotros nos ocupamos del servidor, los runners, las copias y las actualizaciones.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el