Garnix dejará de operar

• garnix planea finalizar su servicio de hosting el 15 de julio de 2026 como parte de su transición al integrarse con Shopify
• La base de código de garnix se publicará como open source, para que los usuarios puedan migrar a una instancia propia o compartida
• Los usuarios interesados en operar una instancia comunitaria pública pueden contactar al equipo de garnix, que también quiere mantener esas conversaciones
• El 15 de julio de 2026 se eliminarán todos los datos de usuario, y eso incluye también los artefactos de compilación
• Los datos y artefactos de compilación que se quieran conservar deben descargarse manualmente antes de la fecha de cierre; el aviso actual se comparte en forma de cita de un correo electrónico

---

Cierre del servicio y publicación del código

• garnix se une a Shopify y, como parte de esta transición, cerrará el servicio alojado de garnix el 15 de julio de 2026
• La base de código de garnix se publicará como open source para que los usuarios puedan trasladarse a una instancia propia o compartida
• Los usuarios interesados en operar una instancia comunitaria pública pueden contactar al equipo de garnix

Datos de usuario y preparación para la migración

• El 15 de julio de 2026 se eliminarán todos los datos de usuario, incluidos los artefactos de compilación
• Cualquier dato o artefacto de compilación que se quiera conservar debe descargarse manualmente antes de la fecha de cierre
• El aviso de cierre no se encontró en garnix.io y se comparte en forma de cita del contenido de un correo recibido desde [e-mail]
• El equipo de garnix agradeció el apoyo de la comunidad, incluidas las donaciones y comentarios de la época de Open Collective, y se menciona a Alex David, Sönke Hahn y Julian K. Arni como integrantes del equipo

[GN⁺]

Comentarios en Lobste.rs

• ¡Qué lástima! Me encantó mucho el artículo sobre incrustar las URL de dependencias de servicios dentro del build del servicio para resolver problemas de despliegue continuo
  https://garnix.io/blog/call-by-hash/

• Para quien tenga curiosidad sobre qué es Garnix:
  Garnix es un servicio de CI para repositorios de GitHub nixificados y basados en flakes
  Fuente: https://github.com/garnix-io/garnix-ci#garnix

• Garnix fue por muchísimo el mejor sistema de CI que he usado hasta ahora
  Cuando GitHub Actions todavía seguía buscando un runner, Garnix ya había terminado el build, y hasta mi proyecto en Rust de complejidad media normalmente terminaba en menos de un minuto
  Cuando solo cambiaba documentación era todavía más rápido, y de hecho también hacía build de la documentación
  Claro, eso es gracias a Nix, pero Garnix hizo esa integración realmente bien
  Un CI integrado con el sistema de build puede funcionar muchísimo mejor que estar bajando cada vez medio tar del sistema de archivos desde S3 para luego montar cachés encima
  Además, como está basado en Nix, construye exactamente lo mismo que construyes en local, así que no existe ese ciclo larguísimo de retroalimentación de “arreglar un typo en yaml, hacer push, esperar 10 minutos, ver el siguiente error, agregar salida de depuración, volver a hacer push...”
  Si compila en local, funciona también en CI

• Qué pena. Durante la última semana más o menos vi algunos problemas raros, pero no les di mucha importancia
  Me molestaba un poco que solo soportara GitHub, pero aun así era un gran servicio
  Este fin de semana pienso revisar la versión open source y ver si hacer self-hosting es realista, y si alguien conoce alternativas para builds con Nix estaría bueno saberlo

• He usado garnix desde su lanzamiento, así que sí da bastante pena que cierre
  Si alguien conoce alguna solución de CI para Nix o que pueda self-hostearse, estaría bueno que la compartiera
  Yo usaba garnix principalmente como caché, y además tenía armado un flujo de auto-merge basado en su estado público de checks

  • tangled.org va a publicar algo parecido pronto. Probablemente también se podrá self-hostear
  • Como parece que garnix se va a publicar como open source, quizá también pueda ser una opción para self-hosting
    No era cliente y solo uso Nix en casa, pero igual pienso revisar muy bien cómo se podría self-hostear

• Si no fuera por lo siguiente, estaría completamente fuera de tema:
  “Pero vamos a publicar el código de garnix como open source, y se puede ver aquí”
  Esa parte sí me parece relevante e interesante para el tema
  En la empresa estamos apostando por completo por Nix, y me genera sentimientos bastante encontrados
  Gran parte de la sensación negativa viene de que Nix es una tecnología realmente excelente, pero todavía se siente como una reliquia alienígena muy joven
  Nix me entusiasma porque todavía queda muchísimo trabajo interesante y valioso por hacer
  Adoptar Nix significa renunciar a muchas funciones de conveniencia que las plataformas tradicionales han ido acumulando durante mucho tiempo, así que había estado revisando varias herramientas del ecosistema de Nix, incluyendo Garnix
  En la práctica, en la empresa estamos invirtiendo mucho más esfuerzo en funciones “básicas” que de otro modo vendrían gratis
  Por ejemplo, correr validaciones en GitHub Actions es más complicado que en un proyecto común, y cosas como caché y paralelización son muy importantes para tener builds rápidos y sólidos
  Me imagino que las empresas que impulsan el ecosistema de Nix van a crecer bastante, o que alguien va a construir algo que cambie el mundo sobre los hombros de gigantes de Nix
  Lamentablemente, Garnix parece ser uno de esos pioneros absorbidos por una organización más grande

  • Un dato curioso es que Nix en realidad no es tan joven
    Salió varios años antes que Docker; solo que floreció tarde y recién hace poco empezó a ganar popularidad

• Ahora que garnix es open source, me pregunto qué tan difícil sería desacoplarlo de GitHub
  Separarlo de flakes debería ser bastante fácil. Los flakes no son reales y no pueden hacerte daño

  • Cada vez que veía garnix me sentía como Calamardo mirando por la ventana con envidia mientras Bob Esponja y Patricio se divierten afuera
    Sin duda me entusiasma esta posibilidad

• Cambiando un poco de tema, estoy intentando mover el CI a Nix, pero el entorno de desarrollo/CI es grande
  La razón principal es que incluye varios navegadores completos, y no logro encontrar una forma de evitar nix build o la restauración de caché
  Incluso restaurar 10GB en un entorno de 1Gbit es demasiado lento
  Con Docker esto ya está resuelto si usas runners self-hosted
  Puedes crear una imagen de Docker y mantenerla en caché en el host donde arranca el runner de CI
  Pero en Nix no sé cómo se hace eso
  Necesito una forma de compartir un nix store que ya tenga todo lo necesario para el entorno de desarrollo, y que ese store derive del flake real del entorno de desarrollo versionado en el repositorio
  ¿No existe algo así?

  • No estoy seguro de entenderlo. Si hospedas tus propios runners y precargas /nix/store con lo necesario para ese workflow, ¿no simplemente queda ahí, igual que con una imagen OCI?
    En mi trabajo anterior operábamos runners propios de GitLab y los dejábamos precalentados instanciando de antemano el conjunto de artefactos de build más recientes antes de ponerlos en servicio
    Así los jobs usaban directamente lo que ya estaba cacheado en /nix/store