Síntesis de cinco lentes —quien lo administra, la academia, el escéptico, el economista y el historiador— sobre si a CreaRack le conviene alojar su propio servidor de código, más la medición directa de nuestra propia infraestructura.
Nos preguntamos si conviene dejar GitHub —la web donde guardamos el código y donde se lanzan las comprobaciones automáticas— y montar en un servidor nuestro un programa parecido que se llama Forgejo. El motivo no es el dinero: es no quedarnos parados cuando ellos se averían, como pasó ayer.
Lo primero que hemos hecho es mirar los números de casa, y cambian bastante la conversación. La parte cara de esa independencia ya la compramos en julio, cuando las comprobaciones automáticas pasaron a ejecutarse en nuestro propio servidor. Desde entonces no pagamos nada por ellas, y en los últimos tres meses, de casi seiscientas comprobaciones lanzadas, solo once se quedaron a medias por culpa de GitHub. La avería de ayer fue mala suerte concentrada, no el pan de cada día.
Lo segundo es que el código, en sí, ya es nuestro y ya está a salvo: cada uno de nosotros tiene una copia completa en su ordenador, y funciona sin conexión con nadie. Lo que de verdad ataría a GitHub no es el código, sino todo lo que hay alrededor: las conversaciones de cada cambio, los permisos, y sobre todo el pegamento que hemos ido montando —los ayudantes automáticos que suben y vigilan los cambios, los despliegues que se lanzan solos, los avisos—. Eso hay que reescribirlo entero, porque las herramientas que usamos no hablan con Forgejo.
Lo tercero es lo incómodo: montar esto en casa no elimina el riesgo de avería, lo cambia de dueño. Si GitHub se cae, hay miles de personas arreglándolo mientras nosotros esperamos. Si se cae lo nuestro un sábado por la noche, el que no duerme eres tú. Además, este tipo de programas ha tenido este mismo año dos agujeros de seguridad graves, uno de ellos activado de fábrica en la instalación más común, y a los trece días ya lo estaban aprovechando por ahí fuera. Vigilar eso pasaría a ser trabajo nuestro.
Y el cuarto punto es el dinero, que va justo al revés de lo que uno esperaría: hoy GitHub nos cuesta unos ciento cuarenta euros al año. Montar y mantener lo nuestro se comería entre diez y veinte veces esa cifra, no en servidores, sino en horas tuyas, que este verano son el recurso más escaso que tenemos.
La recomendación que sale de las cinco lentes, y coinciden todas, es la misma: no mudarse, pero dejar de estar desprotegidos. Montar una copia automática de todo en un servidor nuestro, que se actualice sola y que sirva de red si un día GitHub desaparece o nos echa. Eso cuesta unos pocos euros al mes y unas horas de montaje, y nos da casi toda la tranquilidad que buscas sin heredar el trabajo de mantenerlo. Si algún día la copia demuestra que aguanta, siempre se puede dar el paso siguiente; al revés no: una vez te has mudado, volver es otra mudanza.
El hecho asentado es que la parte cara de la soberanía ya está comprada: desde julio el CI corre en runners propios, la factura de automatización es 0 € dos meses seguidos, y el impacto medido de las caídas de GitHub sobre nosotros es de 11 corridas canceladas sobre ~600 en 90 días. La interpretación en disputa es cuánto vale lo que queda: alojar seis repositorios que suman 95 MB y unas identidades. Las cinco lentes convergen en que ese resto es a la vez lo más barato de mover y lo más caro de mantener, porque lo que se migra de verdad no es el código —que ya es soberano en cada clon— sino el pegamento: la interfaz gh que usan nuestros agentes de commit, los despliegues automáticos de Dokploy, y la publicación a Cloudflare. La tensión real no es GitHub contra Forgejo: es que migrar convierte una dependencia atendida por miles de ingenieros en una dependencia atendida por una persona que en agosto está sola y en septiembre tiene que enseñar la plataforma nueva a dos compañeros. Existe una tercera vía que ninguna lente descarta y todas mencionan: el espejo propio automático, que compra el seguro sin comprar el trabajo.
Medido hoy en vivo contra nuestra propia cuenta y nuestros propios servidores. El consumo facturado de automatización cayó de 5.398 minutos en junio a 576 en julio y 24 en los primeros siete días de agosto — el desplome coincide con el 3 de julio, cuando el CI pasó a runners propios. Coste: 0 € dos meses seguidos, contra 3.000 minutos incluidos en el plan. Y el daño real de las averías de GitHub: de casi 600 corridas lanzadas en 90 días entre los dos repositorios, solo 11 quedaron canceladas, diez de ellas en el workspace. La tarde perdida de ayer es real, pero es un caso aislado, no un patrón.
Git es distribuido: cada clon es una copia completa, así que el repositorio es el único activo que ya es soberano por diseño. Lo que ata a GitHub es exactamente lo que Git no cubre. Y ahí las cuatro piezas se rompen a la vez: la interfaz gh no funciona contra Forgejo (no expone la vía que necesita), y nuestro inventario dice que de ella dependen los dos agentes de commit —13 llamadas entre ambos— y el script de push blindado. Cloudflare Pages no conecta con instancias autoalojadas, por política escrita de Cloudflare. Dokploy no crea los avisos automáticos en Gitea/Forgejo (fallo abierto), y hemos confirmado que nuestros despliegues cuelgan de dos integraciones suyas instaladas en la organización. La única buena noticia medida: el auto-actualizador del Agente no depende de las Releases de GitHub — descarga del propio CreaRack —, así que esa pieza no es ruta crítica.
Dos agujeros graves documentados en 2026. El primero, de gravedad 9,8 sobre 10: la imagen oficial de Gitea traía activada de fábrica una opción que permitía a cualquiera hacerse pasar por el administrador con una simple cabecera HTTP, sin contraseña; a los trece días del aviso ya había escaneo masivo, con unas 6.200 instancias expuestas. El segundo dejó registros de contenedores privados legibles sin credenciales durante casi cuatro años, afectando a unos 30.000 despliegues. No son errores de quien instala: son valores por defecto. Con servidor propio, quien tiene que estar mirando esos avisos y aplicando el parche somos nosotros.
Tres asientos de GitHub Team salen por unos 144 $ al año, con 3.000 minutos de automatización incluidos que ya casi no usamos. Enfrente, el montaje inicial (dos a cuatro días) más el mantenimiento mensual suman una cifra estimada de 1.500 a 3.000 € anuales en tiempo de desarrollo, y el hierro dedicado añadiría unos 528 € al año si se alquila máquina nueva. El detalle que más pesa: hoy somos el peor cliente posible de GitHub —pagamos el asiento barato y no consumimos lo caro— y esa es justamente la posición más rentable en la que estar.
La propia documentación de Forgejo admite que su entorno base es distinto (una imagen mínima, no la grande de GitHub), que faltan claves de contexto y —lo peligroso— que ignora en silencio dos ajustes de los flujos de trabajo: los permisos y el "continuar si falla". Ignorar en silencio es peor que fallar: el proceso sale verde y tú te lo crees. Nuestro inventario lo pone en contexto: usamos 13 acciones distintas del ecosistema en 74 llamadas, y las cuatro más usadas —descarga del código, preparación de Node, de Python y de pnpm— son precisamente las que hay que espejar a mano. Además, los runners montados en julio no se reaprovechan: el programa que ejecuta las automatizaciones de Forgejo es otro binario, con otro registro. Se reutiliza el servidor, no el montaje.
La cifra (257 incidencias, 48 averías mayores, 6 h de media para recuperarse, entre mayo de 2025 y abril de 2026) procede de un agregador comercial, no del informe oficial de GitHub, y no son porcentajes de disponibilidad auditados. Nuestra propia medición la relativiza: en 90 días solo 11 corridas nuestras se vieron afectadas. Sirve para decir "GitHub falla más de lo que promete", no para justificar una migración por sí sola.
Por un lado, todas las lentes dicen que autoalojar es caro y arriesgado para tres personas. Por otro, la misma investigación reconoce que la queja de fondo es legítima: GitHub falla, y ayer nos dejó parados. Parecen incompatibles: o el riesgo importa o no importa.
Se resuelven al mirar qué parte de la soberanía ya está pagada. En julio movimos el CI a nuestros runners, y esa era la pieza cara: la que consumía dinero, la que se saturaba, la que dependía de la capacidad de un tercero. Lo que queda en GitHub son dos cosas de naturaleza opuesta: el repositorio, que ya es soberano porque Git es distribuido y cada clon es una copia entera; y la periferia —identidades, revisiones, integraciones—, que es justamente lo que peor se autoaloja y lo que más trabajo da mantener. Migrar ahora significa pagar caro por mover lo que ya era gratis, y heredar el mantenimiento de lo que nunca deja de dar guerra.
Compramos el 80% de la independencia en julio sin darnos cuenta. Lo que queda no se compra migrando: se compra con una copia automática que cuesta unos euros al mes.
Las cinco lentes congelaron dos variables que en CreaRack no son secundarias. La primera: nuestro método de trabajo está cableado a GitHub mucho más que el de un equipo normal — los agentes que suben y vigilan los cambios, el script de push blindado, los enganches del arranque de sesión y varios servicios del workspace que leen contenido por la interfaz de GitHub. Ninguna lente ha contado ese trabajo, porque ninguna sabe que existe. La segunda: el factor humano del equipo — Dani y Txell vuelven a mediados de septiembre y tendrían que aprender una plataforma distinta justo cuando arranca el trimestre fuerte.
La sexta lente que falta es, por tanto, la del propio método: alguien que cuantifique cuántas horas cuesta reescribir el pegamento y quién lo mantiene después. Si esa cifra fuera pequeña, el veredicto podría girar hacia una migración por fases. Si es grande —y el inventario apunta a que lo es—, refuerza todo lo anterior. Esa medición no existe todavía y es la que convertiría este informe en una decisión cerrada.
Para Edu, decidiendo esta semana. Movimientos concretos, ordenados por relación entre lo que protegen y lo que cuestan.
Un Forgejo que replique los seis repositorios cada pocas horas. Cuesta unas horas de montaje y unos pocos euros al mes, y compra el seguro real: si GitHub cierra la cuenta, sube precios o se cae una semana, el código y su historia siguen siendo nuestros y arrancables. Es la jugada que las cinco lentes señalan como la históricamente ganadora para equipos pequeños. Aviso medido: OPS solo tiene 24 GB libres (67% ocupado) — los seis repositorios suman 95 MB, así que caben de sobra, pero el disco pide vigilancia antes de añadirle nada más.
El espejo salva el código, pero no las conversaciones de cada cambio, las incidencias ni los permisos. Un volcado mensual de esos metadatos, verificado, es lo que convierte el espejo en una salida de verdad. Sin esto, el espejo protege el activo fácil y deja fuera justo lo que costaría reconstruir.
Es cambiar una línea en cada uno. Reduce la exposición a sus averías sin migrar nada, y de paso confirma en la práctica si nuestros servidores aguantan toda la carga — que es el ensayo previo a cualquier migración futura. Casi todos son tareas programadas del workspace: wiki, catálogo, revisiones.
Hoy la única cifra que tenemos es "11 corridas canceladas en 90 días" y la sensación de ayer. Un registro de tres meses convierte esta discusión en un número. Si al cabo de un trimestre las horas perdidas superan a las que costaría mantener lo propio, la decisión se toma sola y con datos, no con el recuerdo de una mala tarde.
Antes de plantear siquiera una migración por fases, hay que contar cuántas horas cuesta reescribir lo que hoy usa la interfaz gh —los dos agentes de commit, el push blindado— y rehacer los despliegues automáticos. Es la cifra que falta, y sin ella cualquier plan de migración es una estimación a ojo.
Es la única cifra que falta para cerrar la decisión, y ninguna de las cinco lentes podía darla porque ninguna conoce nuestro método por dentro. Amenaza directamente al plan de migración: si son dos semanas de trabajo, hablamos de una obra que se paga sola con el tiempo; si son dos meses del único desarrollador disponible en verano, la conversación se acaba. Responderla es barato —un inventario detallado y una estimación por pieza— y desbloquea la única versión honesta de un plan por fases.
permissions y continue-on-error ignorados en silencio. forgejo.orgcode.forgejo.org pese a tener las acciones espejadas (fallo del runner, sept-2024). code.forgejo.org