A Garnix será encerrada

• A garnix encerrará o serviço de hospedagem em 15 de julho de 2026, como parte da transição de integração com a Shopify
• O codebase da garnix será disponibilizado como open source, permitindo que usuários migrem para sua própria instância ou para uma instância compartilhada
• Usuários interessados em operar uma instância comunitária pública podem entrar em contato com a equipe da garnix, que também quer conversar sobre isso
• Em 15 de julho de 2026, todos os dados dos usuários serão apagados, incluindo os artefatos de build
• Dados e artefatos de build que precisem ser preservados devem ser baixados manualmente antes da data de encerramento; o anúncio atual está sendo compartilhado em forma de citação de e-mail

---

Encerramento do serviço e abertura do código

• A garnix está se unindo à Shopify e, como parte dessa transição, encerrará o serviço hospedado da garnix em 15 de julho de 2026
• O codebase da garnix será aberto como open source para que usuários possam migrar para sua própria instância ou para uma instância compartilhada
• Usuários interessados em operar uma instância comunitária pública podem entrar em contato com a equipe da garnix

Dados dos usuários e preparação para a migração

• Em 15 de julho de 2026, todos os dados dos usuários serão apagados, incluindo os artefatos de build
• Quaisquer dados ou artefatos de build que precisem ser preservados devem ser baixados manualmente antes da data de encerramento
• O anúncio de encerramento não foi encontrado em garnix.io e está sendo compartilhado em forma de citação do conteúdo de um e-mail recebido de [e-mail]
• A equipe da garnix agradeceu o apoio da comunidade, incluindo doações e feedback da época do Open Collective, e identificou os membros da equipe como Alex David, Sönke Hahn e Julian K. Arni

[GN⁺]

Opiniões no Lobste.rs

• Que pena! Eu realmente adorava o texto sobre embutir URLs dependentes do serviço no build do serviço para resolver problemas de implantação contínua
  https://garnix.io/blog/call-by-hash/

• Para quem está se perguntando o que é o Garnix:
  Garnix é um serviço de CI para repositórios GitHub baseados em flake e Nixificados
  Fonte: https://github.com/garnix-io/garnix-ci#garnix

• O Garnix foi de longe o melhor sistema de CI que já usei
  Quando o GitHub Actions ainda estava procurando um runner, o Garnix já tinha terminado o build, e até meu projeto em Rust de complexidade média normalmente terminava em menos de 1 minuto
  Quando eu só mudava a documentação, era ainda mais rápido, e ele de fato também fazia o build da documentação
  Claro que isso é graças ao Nix, mas o Garnix fazia essa integração muito bem
  Um CI integrado ao sistema de build pode funcionar muito melhor do que um esquema de baixar toda vez um tar parcial do sistema de arquivos do S3 e sobrepor um cache
  Além disso, como é baseado em Nix, ele faz exatamente o mesmo build que você faz localmente, então não existe aquele longo ciclo de feedback de “corrigir um typo no yaml, dar push, esperar 10 minutos, ver o próximo erro, adicionar saída de debug, dar push de novo...”
  Se compila localmente, funciona no CI

• Uma pena. Na última semana eu tinha visto alguns problemas estranhos, mas não dei muita importância
  Eu tinha minhas ressalvas por ele só suportar GitHub, mas ainda assim era um serviço excelente
  Neste fim de semana pretendo dar uma olhada na versão open source e avaliar se self-hosting é viável, e seria bom saber de alternativas para builds com Nix

• Que pena ver que vai encerrar, uso o garnix desde o lançamento
  Se alguém souber de Nix CI ou de uma solução que dê para hospedar por conta própria, seria ótimo saber
  Eu usava o garnix principalmente como cache e também tinha montado um fluxo de auto-merge com base no status público dos checks

  • O tangled.org deve lançar algo parecido em breve. Também deve dar para fazer self-hosting
  • Parece que o garnix está sendo aberto como open source, então talvez também possa virar uma opção para self-hosting
    Eu não era cliente e só uso Nix em casa, mas com certeza pretendo olhar como seria hospedar por conta própria

• Se não fosse pelo trecho a seguir, estaria totalmente fora de tópico:
  “Mas estamos abrindo o código do garnix como open source, e ele pode ser visto aqui”
  Essa parte eu considero pertinente ao tópico e interessante
  Na empresa estamos apostando tudo em Nix, então os sentimentos são bem mistos
  Grande parte da sensação negativa vem do fato de que Nix é uma tecnologia realmente excelente, mas ainda parece um artefato alienígena muito jovem
  O Nix é empolgante e ainda tem uma quantidade enorme de coisas interessantes e valiosas por fazer
  Adotar Nix significa abrir mão de várias conveniências que as plataformas existentes acumularam ao longo do tempo, então eu vinha olhando o Garnix e várias outras ferramentas do ecossistema Nix
  Na prática, na empresa estamos gastando muito mais esforço em funcionalidades “básicas” que normalmente viriam de graça
  Por exemplo, até rodar validações no GitHub Actions é mais complicado do que em um projeto comum, e elementos como cache e paralelização são extremamente importantes para builds rápidos e robustos
  Acho que as empresas que estão fazendo o ecossistema Nix evoluir vão crescer muito, ou então alguém vai criar, sobre os ombros dos gigantes do Nix, algo capaz de chacoalhar o mundo
  Infelizmente, o Garnix parece ser um daqueles pioneiros absorvidos por uma organização maior

  • O curioso é que o Nix não é tão jovem assim
    Ele surgiu alguns anos antes do Docker; só é uma tecnologia que floresceu tarde e por isso só recentemente ganhou popularidade

• Agora que o garnix virou open source, fico curioso sobre quão difícil seria desacoplá-lo do GitHub
  Desacoplar de flakes deve ser bem fácil. Flakes não são reais e não podem te machucar

  • Toda vez que eu olhava para o garnix, me sentia como o Lula Molusco olhando pela janela com inveja do Bob Esponja e do Patrick se divertindo
    Essa possibilidade com certeza me anima

• Mudando um pouco de assunto, estou tentando migrar meu CI para Nix, mas o ambiente de desenvolvimento/CI é grande
  O principal motivo é que ele inclui vários navegadores completos, e não consigo descobrir uma forma de evitar nix build ou a restauração de cache
  Até restaurar 10 GB em uma conexão de 1 Gbit é lento demais
  Com Docker, esse problema já está resolvido se você usar runners self-hosted
  Basta criar uma imagem Docker e mantê-la em cache no host onde o runner de CI sobe
  Mas no Nix eu não sei como fazer isso
  Eu precisaria de uma forma de compartilhar um nix store que já contenha tudo de que o ambiente de desenvolvimento precisa, e que seja derivado do flake real do ambiente de desenvolvimento versionado no repositório
  Isso não parece ser algo que exista, ou existe?

  • Não tenho certeza se entendi. Se você hospeda seus próprios runners e pré-popula o /nix/store com o que aquele workflow precisa, então, assim como uma imagem OCI, aquilo simplesmente já está lá, não?
    No meu emprego anterior, operávamos runners GitLab próprios e os aquecíamos previamente instanciando um conjunto recente de artefatos de build antes de colocá-los em serviço
    Aí os jobs simplesmente usavam o que já estava em cache no /nix/store