Autoalojamiento de una forja Git: guía práctica para la soberanía de los datos

En Dumontix trabajamos exclusivamente con proveedores de nube europeos. No es una estrategia de marketing ni una postura filosófica que adoptamos porque sonaba bien; es un requisito práctico para muchos de nuestros clientes. Cuando manejas datos de empresas europeas, particularmente aquellas en industrias reguladas, “simplemente usa GitHub” no siempre es una opción. A veces tu código, tus issues, tus pipelines de CI/CD y tus secretos de despliegue necesitan permanecer dentro de límites jurisdiccionales que puedas verificar realmente.

Hemos pasado años construyendo experiencia con Scaleway, Hetzner, OVH y otros proveedores de infraestructura europeos. Conocemos sus particularidades, sus modelos de precios, sus tiempos de respuesta de soporte. Sabemos cuáles tienen el mejor rendimiento de almacenamiento en bloque y cuáles conviene evitar para cargas de trabajo sensibles a la latencia. Esta especialización significa que a veces tenemos que resolver problemas que serían triviales si pudiéramos simplemente dirigir a los clientes hacia una solución SaaS estadounidense.

El alojamiento de Git es uno de esos problemas.

El tutorial que se convirtió en proyecto

Todo esto empezó como un artículo de blog. Iba a escribir un tutorial sencillo: “Cómo desplegar Forgejo en Scaleway en 30 minutos”. Tenía las configuraciones de Terraform, algunas tareas de Ansible, notas sobre Let’s Encrypt y proxies inversos. Iba a ser directo.

Entonces empecé a escribir, y los casos especiales se acumularon. ¿Qué pasa con los respaldos? ¿Y las actualizaciones? ¿Cómo manejas la base de datos: en contenedor o directamente en el servidor? ¿Qué pasa cuando alguien quiere usar Hetzner en lugar de Scaleway (este es nuestro proveedor, así que originalmente lo escribí para su caso)? ¿Provisionas el almacenamiento por separado o usas el disco de arranque? ¿Cómo gestionas los secretos sin commitearlos al repositorio que intentas autoalojar?

Para cuando había abordado todas estas preguntas, ya no estaba escribiendo un tutorial. Estaba construyendo infraestructura como código que realmente querría usar en producción. Así que dejé de pretender que era un artículo de blog y lo convertí en un proyecto formal.

El resultado es forgejo-autohebergement, un kit de herramientas completo para desplegar Forgejo en proveedores de nube europeos. Maneja el aprovisionamiento de infraestructura con Terraform, la configuración del servidor con Ansible, respaldos automatizados, certificados HTTPS, reglas de firewall, e incluso acceso SSH basado en VPN. Puedes tener una forja Git lista para producción funcionando en menos de una hora, y más importante aún, puedes entender y modificar cada parte de ella.

Comiendo nuestras propias galletas con sabor a operaciones

La instancia de Forgejo en git.dumontix.eu corre sobre exactamente esta plantilla. Hicimos algunos ajustes según nuestras preferencias: diferentes períodos de retención de logs, algunos hooks de monitoreo adicionales, un calendario de respaldos ligeramente más agresivo; pero el núcleo es idéntico a lo que encontrarás en el repositorio público.

Esto no es solo dogfooding por credibilidad, es más bien compartir nuestro almuerzo. Cuando encontramos un bug o necesitamos una nueva funcionalidad, lo arreglamos en el mismo código que usan nuestros clientes. Cuando Forgejo lanza una nueva versión, actualizamos nuestra instancia primero y luego subimos los cambios probados. La plantilla mejora porque dependemos de ella.

Nuestro despliegue usa instancias DEV1-S de Scaleway en París, con almacenamiento en bloque para el volumen de datos. PostgreSQL corre directamente en el servidor en lugar de en un contenedor; preferimos la simplicidad operacional y la posibilidad de usar herramientas estándar de Debian para el mantenimiento de la base de datos. Caddy maneja la terminación TLS y el proxy inverso, lo que elimina toda una categoría de dolores de cabeza con la renovación de certificados que plagaban nuestras configuraciones anteriores con nginx.

La cuestión de Tailscale

Un componente en nuestro stack no es europeo: Tailscale. Lo usamos para asegurar el acceso SSH a nuestros servidores, creando una red de confianza cero donde el puerto de administración nunca está expuesto a internet público.

Fue una elección deliberada, y quiero ser transparente sobre el razonamiento. Conozco a los fundadores de pasar tiempo en la comunidad de Go. Los he visto construir la empresa y confío en su enfoque hacia la seguridad y la privacidad. Cuando eliges componentes de infraestructura, las personas detrás del proyecto importan tanto como las especificaciones técnicas.

Dicho esto, reconozco que esto crea una dependencia de un servicio estadounidense. Para clientes con requisitos estrictos de residencia de datos, discutimos alternativas. Headscale, el servidor de control de Tailscale de código abierto, es una opción. Netbird es otra. WireGuard directamente, con tu propia distribución de claves, funciona bien si te sientes cómodo gestionándolo. Los roles de Ansible en nuestra plantilla están diseñados para ser intercambiables: Tailscale es el predeterminado porque tiene la mejor experiencia de desarrollador, pero las reglas de firewall y la configuración SSH no asumen ninguna solución VPN particular.

Eventualmente, probablemente adoptaremos una alternativa completamente europea como predeterminada. El ecosistema está madurando, y proyectos como Netbird están alcanzando calidad de producción. Por ahora, hemos tomado una decisión pragmática que nos sentimos cómodos explicando a los clientes (y bueno, hay que elegir las batallas; puedes pelearlas todas, pero de a una).

¿Por qué Forgejo?

Elegí Forgejo sobre Gitea, GitLab u otras alternativas por varias razones. Es lo suficientemente ligero para correr en infraestructura mínima: nuestra instancia de producción usa un servidor de 2 vCPU y 2GB de RAM y apenas nota la carga. Está desarrollado activamente por una fundación sin fines de lucro con un modelo de gobernanza claro, lo cual importa cuando estás apostando tu código fuente a un proyecto. Y tiene paridad de funcionalidades con lo que la mayoría de los equipos realmente necesitan: pull requests, issues, integración de CI vía webhooks, registros de contenedores, y buena cobertura de API (además me gusta).

GitLab es excelente pero requiere significativamente más recursos y complejidad operacional. Para equipos que no necesitan sus funcionalidades avanzadas de CI/CD o integraciones empresariales, es excesivo. Gitea habría estado bien técnicamente, pero la situación de gobernanza nos incomodaba. Forgejo surgió de la comunidad de Gitea específicamente para abordar esas preocupaciones, y el proyecto ha demostrado ser estable y confiable.

Cómo funciona

El proceso de despliegue tiene dos fases. Primero, Terraform aprovisiona la infraestructura en la nube: una instancia de cómputo, un volumen de almacenamiento en bloque, registros DNS si los gestionas a través del proveedor, y las reglas de firewall necesarias a nivel de nube. Segundo, Ansible configura el servidor: instala dependencias, configura PostgreSQL, despliega Forgejo como contenedor Docker, configura Caddy para HTTPS, establece rutinas de respaldo, y fortalece el sistema.

Un asistente de configuración te guía a través de la configuración inicial:

./setup-wizard.sh

Te pregunta por las credenciales de tu proveedor de nube, tu nombre de dominio, y genera los secretos necesarios. También puedes configurar todo manualmente si lo prefieres; el asistente simplemente crea los mismos archivos YAML que escribirías a mano.

El Makefile proporciona atajos para operaciones comunes:

make help              # Mostrar todos los comandos disponibles
make install           # Despliegue completo desde cero
make deploy            # Actualizar configuración
make backup            # Crear un respaldo
make backup-cron       # Respaldo no interactivo para cron jobs
make ssh               # Conectar al servidor

Los respaldos incluyen la base de datos PostgreSQL, todos los repositorios Git, objetos LFS, y la configuración de Forgejo. Pueden quedarse localmente en el almacenamiento en bloque del servidor o sincronizarse a almacenamiento de objetos compatible con S3. La restauración es un solo comando que detiene el servicio, reemplaza los datos, y reinicia todo.

Contribuir sin registro

Dado que git.dumontix.eu no permite registro público, hemos establecido un flujo de trabajo para contribuciones externas. Hay un mirror sincronizado en Codeberg en codeberg.org/dumontix/forgejo-autohebergement. Los contribuidores hacen fork del mirror, realizan sus cambios y crean un Pull Request. Revisamos los cambios y los fusionamos con la atribución correspondiente.

No es tan fluido como un pull request en una plataforma con registro abierto, pero funciona. Las funcionalidades de federación de Forgejo eventualmente habilitarán pull requests entre instancias a través del protocolo ForgeFed; la especificación está en desarrollo y están apareciendo implementaciones tempranas. Hasta que eso esté listo para producción, el flujo de fork-y-enlace es un compromiso razonable.

Primeros pasos

Si quieres correr tu propia instancia, clona el repositorio y ejecuta el asistente:

git clone https://codeberg.org/dumontix/forgejo-autohebergement.git
cd forgejo-autohebergement
./setup-wizard.sh

Necesitarás cuentas con el proveedor de nube que elijas y un nombre de dominio apuntando a donde vivirá el servidor. El asistente se encarga del resto, incluyendo generar contraseñas seguras y claves de cifrado.

La documentación cubre detalles específicos de cada proveedor, opciones de personalización y procedimientos operacionales. Si encuentras problemas, abre un issue. Si haces mejoras, nos encantaría verlas.

El autoalojamiento no es para todos. Requiere mantenimiento continuo, conciencia de seguridad, y disposición para depurar problemas a las 2 AM cuando algo se rompe. Pero para organizaciones que necesitan control sobre su infraestructura de código fuente, ya sea por cumplimiento regulatorio, soberanía de datos, o simplemente preferencia filosófica, es completamente alcanzable. Las herramientas han madurado lo suficiente como para que no necesites un equipo de plataforma dedicado para correr una forja Git confiable.

Llevamos un tiempo corriendo la nuestra. Funciona.

–

Si esto resuena con los desafíos que tu empresa enfrenta a diario, hablemos y veamos cómo podemos ayudarte