Flox 1.0 – Codificação open source de ambientes de desenvolvimento com Nix

• Flox é uma plataforma de ambientes de software para equipes de engenharia, que gerencia com um único manifesto ambientes reproduzíveis de forma idêntica do notebook do desenvolvedor até CI e produção
• A base é o Nix, mas conhecer Nix é opcional; a estrutura reduz o drift de ambientes com manifestos declarativos e entradas de hash de conteúdo fixadas criptograficamente
• Funciona em macOS, Linux e Windows WSL2, permite buscar e instalar mais de 120.000 pacotes do Nixpkgs e também compilar e publicar seu próprio software como pacotes reproduzíveis
• Com o fluxo flox init, flox install, flox activate, cria ambientes isolados por projeto; ao ativar, as ferramentas aparecem, e ao sair desaparecem, mantendo o sistema limpo
• Inclui compartilhamento via FloxHub, geração de imagens OCI, execução de serviços, SBOM, correção de CVEs, SCA e até ambientes de execução determinísticos para agentes de codificação com IA, com foco no gerenciamento do ciclo de vida dos ambientes em nível organizacional

---

O problema que a Flox quer resolver

• Flox é uma plataforma que define o ambiente de desenvolvimento em um único arquivo e faz o mesmo ambiente rodar no notebook do desenvolvedor, em CI e em produção
• Enquanto gerenciadores de pacotes tradicionais focam na instalação de pacotes em uma única máquina, a Flox gerencia o ciclo de vida de pacotes e ambientes de toda a organização
• Há três propriedades centrais
  • Declarativo: descreve em um único arquivo as ferramentas, variáveis de ambiente e serviços necessários ao projeto
  • Reproduzível: a mesma definição cria o mesmo ambiente em qualquer sistema compatível
  • Componível: permite criar camadas de ambientes por projeto, equipe e pipeline

Usuários-alvo e ambientes de uso

• Equipes de Platform e DevX podem padronizar toolchains em toda a organização e expandir ambientes de referência sem obrigar todos a aprender Nix
• Equipes de Security e AppSec podem lidar com SBOM, resposta rápida a CVEs, origem de dependências e builds reproduzíveis
• Desenvolvedores podem usar ambientes reproduzíveis por projeto em macOS, Linux e Windows WSL2, operando de forma mais próxima de um ambiente virtual do que de contêineres ou VMs
• Agentes de codificação com IA obtêm ambientes determinísticos nos quais o código gerado pode ser compilado e executado sempre da mesma forma
  • Exemplos citados: Claude Code, Cursor, Copilot e Codex

Reprodutibilidade e segurança da cadeia de suprimentos

• Ambientes Flox são definidos com um manifesto declarativo e bloqueados por entradas de hash de conteúdo fixadas criptograficamente
• O mesmo lockfile é resolvido para os mesmos pacotes em cada sistema compatível, mantendo o ambiente idêntico entre máquinas
• Uma única definição de ambiente pode ser usada em notebooks de desenvolvedores, sandboxes de agentes de IA, CI e produção
• É possível usar mais de 120.000 pacotes do Nixpkgs
• Também é possível compilar software próprio a partir do código-fonte, transformá-lo em pacotes reproduzíveis e publicá-lo para uso de toda a equipe
• Com base nessa reprodutibilidade, fica mais fácil lidar com geração de SBOM, análise de composição de software (SCA), correção automática de vulnerabilidades e CVEs, verificação da origem das dependências e builds auditáveis

Instalação e fluxo de trabalho básico

• O CLI da Flox é instalado nativamente em macOS, Linux e Windows WSL2
  • macOS: brew install flox ou instalador .pkg
  • Linux: .deb para Debian/Ubuntu, .rpm para Fedora/RHEL
  • Windows: usa pacotes Linux no WSL2
• O fluxo básico de uso é criar um ambiente dentro do projeto, instalar os pacotes necessários e então ativar o ambiente
  • flox init: cria um ambiente no projeto
  • flox install python3 nodejs: instala pacotes no ambiente
  • flox activate: entra no ambiente
• O exemplo do README mostra que, dentro do ambiente ativado, python3 --version funciona como Python 3.13.13 e node --version como v24.15.0
• Ao sair do ambiente, as ferramentas instaladas desaparecem, evitando conflitos entre projetos e mantendo o sistema limpo

Principais recursos

• Create: com flox init, é possível criar um ambiente declarativo ao lado do código e ativá-lo automaticamente
• Search: com flox search, é possível encontrar mais de 120.000 pacotes do Nixpkgs
• Share: com flox push / flox pull, membros da equipe podem obter exatamente o mesmo ambiente de referência único no FloxHub
• Containerize: com flox containerize, é possível transformar um ambiente Flox em imagem OCI sem Dockerfile
• Build & publish: com flox build / flox publish, é possível compilar software próprio como pacote reproduzível e publicá-lo para a equipe
• Services: com flox services start, bancos de dados, filas e processos em segundo plano podem ser executados como parte do ambiente; iniciam na ativação e param no encerramento
• Configure: em manifest.toml, variáveis de ambiente, shell hooks e scripts de ativação são definidos declarativamente
• AI-ready: via flox-agentic, agentes de codificação com IA podem compilar e executar com as mesmas dependências a cada execução

Posicionamento para usuários de Docker e Nix

• Flox não é uma tecnologia de contêiner e não é substituto do Docker
• No Docker, empacotamento e isolamento de contêiner às vezes ficam misturados, mas a Flox defende separar empacotamento de software do método de isolamento escolhido
• Ambientes Flox funcionam da mesma forma em bare metal, VMs e contêineres
• flox containerize cria imagens OCI com o ambiente de software incluído, podendo ser usado junto com Docker, Kubernetes e outros runtimes de contêiner
• Para usuários de Nix, Flox não é substituto, e sim uma ferramenta adicional
  • Oferece o serviço central FloxHub para ambientes colaborativos e compartilhamento de pacotes
  • Reúne hooks de ativação, serviços e perfis de shell em um único arquivo TOML declarativo

Origem e recursos de suporte

• Flox surgiu a partir de uma implantação corporativa de Nix em larga escala no grupo D.E. Shaw e foi usada para tornar o Nix mais acessível em grandes organizações de engenharia
• Recursos relacionados
  • Documentation: tutoriais, referência e guias
  • FloxHub: exploração e compartilhamento de ambientes
  • Discourse: perguntas, discussões e anúncios
  • Blog: textos aprofundados e fluxos de trabalho
  • VS Code extension: gerenciamento de ambientes Flox no editor
• Dúvidas relacionadas à segurança são recebidas em [e-mail]
• A licença do CLI da Flox é GPLv2

[GN⁺]

Opiniões do Hacker News

• Ron, parabéns pelo lançamento. O que eu queria saber é como funciona o modelo de receita
  Há um CEO, uma empresa e funcionários, e olhando no Crunchbase parece que receberam US$ 24 milhões em investimento, mas não consigo encontrar informações de preço na landing page nem na documentação
  Mesmo fazendo login no FloxHub com meu perfil do GitHub, não vejo opções de pagamento; fiquei curioso sobre os planos

  • Obrigado pelo apontamento. O formato gratuito e open source que anunciamos hoje foi um dos grandes motivos para começarmos o Flox, e pretendemos incluir muito mais no futuro
    O cliente open source anunciado hoje e o serviço FloxHub para compartilhamento de ambientes serão oferecidos gratuitamente para sempre
    Mais adiante, queremos oferecer um catálogo de software privado mais poderoso, construído sobre o Flox Catalog básico
    Se você precisa distribuir seus próprios artefatos ou de versões modificadas de pacotes open source dentro do Flox, planejamos facilitar a criação do seu próprio catálogo para complementar o Flox Catalog, que será sempre gratuito
    No longo prazo, queremos vender soluções empresariais em forma de assinaturas e serviços para ajudar empresas a gerenciar melhor cadeias de suprimentos de software amplas e fragmentadas, e achamos razoável que empresas compartilhem o custo de desenvolver ferramentas sob medida para empresas
  • Surpreende saber que receberam US$ 24 milhões. Não vejo muito bem o caminho daqui até uma saída de US$ 2,4 bilhões, mas boa sorte

• Sempre me incomodo quando vejo frases no README do tipo “torna o Nix mais fácil para novos usuários”, ou expressões parecidas
  Eu me considero razoavelmente competente, mas nunca houve um momento usando Nix em que eu pensasse “isso foi fácil”
  Gosto muito dos conceitos do Nix, mas a experiência do usuário é terrível. Talvez esta ferramenta resolva isso, mas para chegar a esse ponto há pouquíssima documentação, é preciso se perder em abordagens já obsoletas e ficar mexendo infinitamente nas configurações, o que é muito frustrante
  De todo modo, sempre que vejo algo relacionado ao Nix, penso: “mal posso esperar pelo dia em que isso vai ficar fácil”

  • Se você está falando da frase “O Flox começou durante a adoção do Nix no D. E. Shaw Group e rapidamente demonstrou valor ao tornar o Nix mais fácil para novos usuários”, ela soa como o oposto da interpretação original
  • Essa frase não significa que o Nix é fácil para novos usuários; leio como dizendo que o Flox torna o Nix fácil
  • Tive exatamente a mesma experiência. Mexi bastante com NixOS por um bom tempo, mas nunca me acostumei com .nix nem com flakes
    Os conceitos básicos continuavam escapando da minha cabeça, então toda vez que eu configurava algo novo precisava pesquisar de novo e, no fim, desistia
    Depurar problemas também é difícil; para saber o que deu errado, é preciso vasculhar comandos muito específicos e um sistema de arquivos infernal
    Gosto dos conceitos, mas na prática sinto que atrapalha demais
  • Gosto do Nix e até contribuí com vários pacotes para o repositório nix, mas jamais diria que é fácil
    Como tenho background em Haskell, ele parece um pouco mais familiar para mim, mas a própria sintaxe também não é intuitiva para novos usuários
  • Concordo fortemente. Dá para ver as vantagens, mas a curva de aprendizado inicial é extremamente íngreme
    É parecido com aprender Rust, então até tem seu lado divertido

• O problema central de produtos do tipo “oferece o poder do Nix sem curva de aprendizado” é que, por trás, ainda existem o Nix e o /nix/store, e o Nix deliberadamente não limpa isso automaticamente
  Quando usuários experimentam uma ferramenta que esconde o Nix, o disco acaba enchendo, e como eles não sabem como reduzir o uso de armazenamento, fica difícil chamar isso de amigável ao usuário
  É diferente quando o usuário sabe que está instalando o Nix e passa pelo processo de aprendizado, porque pode criar um modelo mental do que é o /nix/store e de como deve gerenciá-lo
  Fico curioso sobre como vocês pretendem lidar com essa complexidade subjacente

  • Se você dá suporte a rollbacks e histórico, o disco inevitavelmente pode encher. No Nix, isso acontece porque normalmente várias raízes de GC apontam para perfis e pacotes, impedindo a limpeza
    Os ambientes do Flox não são simples links simbólicos; eles têm um formato declarativo e, internamente, flakes, de modo que podem ser removidos e, se necessário, reproduzidos novamente
    Por isso, a coleta de lixo pode ser menos destrutiva do que ao usar nix-env/nix profile, e é possível limpar gerações antigas de forma mais agressiva
    A estratégia é sempre garantir uma forma declarativa e reproduzível de recuperar o que foi limpo e, depois, usar heurísticas como espaço livre, idade, falta de uso recente e baixa frequência de uso para evitar que o disco encha
  • Fico pensando como isso se compara com Docker ou Bazel
    Por outro lado, nunca tive esse problema com Nix. Ele informa claramente como fazer a limpeza de lixo, e é fácil investigar o que permanece e por quê
    O motivo de não vir ativado por padrão é que, como outros coletores de lixo, isso pode atrapalhar, e não existe uma política que sirva para todos
    No fim, se há raízes de GC demais, é preciso tomar decisões
  • O Nix oferece suporte a coleta de lixo
    Sempre que se usa um computador, milhares de coisas absurdamente complexas acontecem nos bastidores; não entendo por que abstrair o Nix seria tratado como algo especial
  • No trabalho temos o mesmo problema com Bazel. Depois de alguns meses, as máquinas de desenvolvimento ficam sem espaço em disco
  • Basta configurar a coleta de lixo do Nix para rodar a cada 30 minutos

• Parabéns pelo lançamento. Eu gosto muito do Nix, mas também reconheço que a experiência de onboarding é ruim na melhor das hipóteses e horrível na pior
  Então, tentativas de torná-lo mais acessível são bem-vindas. Uma CLI imperativa é muito mais próxima do que muita gente espera e se sente confortável usando, então acho que é uma boa direção
  Também concordo bastante com simplificar o processo de usar o ambiente de outro lugar
  Mas algo que parece importante e que não estou vendo é a integração com IDEs. Iniciar a IDE pela linha de comando dentro do ambiente não é intuitivo para muitos colegas, e já diagnostiquei isso várias vezes como a causa raiz real de problemas
  Fico curioso sobre como fica a história de descer para o “Nix de verdade” quando necessário. Por exemplo, em um ambiente um pouco mais complexo para configurar uma toolchain de cross-compilation em Rust, tenho receio de cair de um penhasco
  Como exemplo de desenvolvimento em Rust, precisei colocar um shellHook longo em um flake para que o Rust-Analyzer funcionasse corretamente, e fico curioso sobre como esse tipo de configuração poderia ser feito no Flox
  Também fico curioso se a ideia é abstrair essas partes ou, se não for, como um usuário que não conhece Nix conseguiria descobrir isso
  Não estou dizendo de forma alguma que seja impossível, e realmente quero que dê certo, mas ainda não consigo ver bem o caminho

  • A parte de descer para o “Nix de verdade” quando necessário já foi discutida, e o plano é permitir usar o próprio Nix quando for preciso mais poder
    A ideia atual é permitir referências a flakes em campos específicos ou ter um ponto de entrada no estilo Nix
    Ainda não foi divulgado nem documentado, então seria bom aguardar
    Concordo totalmente que existe uma linha muito sutil entre esconder complexidade e expor capacidade

• Fico curioso sobre qual é a vantagem de usar Flox em vez do nix-shell comum ou nix develop

  • Sou funcionário da Flox. Começando pela relação com as ferramentas do Nix, o objetivo é ser mais amigável ao usuário
    A ideia é permitir que a pessoa tenha sucesso sem precisar aprender a linguagem de expressões do Nix ou entender a estrutura interna do Nix
    Também adicionamos um certo grau de direção e polimento. Por exemplo, há uma interface mista imperativa/declarativa, então, se você executar flox install && flox list, as mudanças são refletidas no TOML. Já com nix develop, é preciso editar expressões Nix
    nix develop entra em um shell bash, mas flox activate pode entrar em um shell bash ou zsh, e planejamos adicionar suporte a fish
    Gerenciar ambientes com Git é suportado como nas ferramentas do Nix, mas também adicionamos compartilhamento de ambientes de formas que essas ferramentas não oferecem, como flox push/flox pull/flox activate -r
    Se você criar uma conta, poderá ver os pacotes do meu ambiente em https://hub.flox.dev/mkenigs/default e, se tiver a CLI, poderá verificar com flox list -r mkenigs/default e depois usar com flox activate -r mkenigs/default
    Acho isso muito mais fácil de digerir para alguém que não conhece a linguagem de expressões do Nix do que enviar um link para um flake.nix
  • Dito de outro modo, acho melhor que engenheiros individuais aprendam a tecnologia de base e as ferramentas associadas a ela
    Há uma chance suficiente de que ferramentas como Flox ou devenv cheguem ao fim da vida, não acompanhem bem o nixpkgs ou sofram alguma das várias formas de apodrecimento de software
    Por outro lado, nix develop vai continuar existindo enquanto o Nix Flakes continuar, e também há incentivo para oferecer um caminho de migração para o próximo modelo
    Mais importante: toda abstração vaza. A CLI do Flox pode parecer mais limpa, mas, no fim, para usá-la de forma eficaz, provavelmente será preciso aprender Nix
    Não vejo por que aprender o dobro do que é necessário
  • Ou também há https://devenv.sh

• Fico curioso sobre como isso se compara ao projeto Devbox existente (https://www.jetpack.io/devbox)
  Também gostaria de saber se o Flox tem uma solução em nuvem opcional, se é possível instalar versões específicas de pacotes Nix e como ele lida com dependências específicas por sistema operacional
  Venho usando esse tipo de ferramenta há 5 anos, então fico curioso sobre o que o Flox traz de novo em relação ao que já existe

• Eu realmente não entendo por que deveria usar isso em vez do Nix comum; alguém pode explicar?

  • Só quero ambientes limpos e repetíveis por projeto. Tentei começar com Nix algumas vezes, mas toda vez fiquei sobrecarregado porque o Nix faz coisas demais
    Isto parece 100 vezes mais simples para mim
  • Entendemos que o Nix resolve muitos problemas e, de fato, apostamos nessa capacidade. Por isso também investimos muito esforço no próprio Nix
    Mas, como o Nix foi construído desde os primeiros princípios para ser muito genérico, sua curva de aprendizado é bem íngreme
    O Flox é uma ferramenta que tenta simplificar as coisas restringindo o escopo do problema e oferecendo abstrações e interfaces especializadas, para que seja possível aproveitar o poder do Nix sem precisar ser especialista em Nix desde o primeiro dia
  • É muito mais fácil convencer colegas a usar flox ou devenv do que convencê-los a usar Nix

• Tenho muito interesse em ambientes de desenvolvimento reproduzíveis e já uso bem dev containers no trabalho há alguns anos
  Ouvi falar do Nix há cerca de um ano e, no começo, fiquei bem animado porque a promessa era excelente, mas o processo de onboarding foi horrível para mim
  Tenho clareza sobre o ambiente de desenvolvimento que quero criar, mas sempre sinto que estou deixando alguma coisa passar na abordagem
  Fico feliz que tenha surgido uma nova ferramenta tentando melhorar a experiência como um todo, e espero que, continuando a tentar, em algum momento a ficha caia
  Fico curioso: em que momento o Nix “clicou” para você?

  • Obrigado pela pergunta. Esse é o tipo de assunto para conversar a fundo tomando uma cerveja se você vier à Bay Area
    Por acaso você já viu o vídeo sobre Microservices? https://www.youtube.com/watch?v=y8OnoxKotPQ
    Na época, eu liderava a equipe de produtos para desenvolvedores no Facebook e iniciei um projeto para injetar funcionalidades remotas no desenvolvimento local
    Milhares de desenvolvedores esperavam 45 minutos por cold builds
    Uma das etapas iniciais foi mapear todo o ciclo de vida de desenvolvimento de software, com o objetivo de entender quais partes da toolchain precisávamos recriar
    Ao olhar para o quadro branco no fim do vídeo, vem à mente que, no momento em que visualizamos o quanto havíamos tornado tudo complexo, entramos no modo de pensar: “não é possível que seja assim que trabalhamos”

• Na última vez que usei Nix, havia muita confusão em torno de flakes
  Alguns tutoriais diziam para usar, outros diziam que ainda estava em desenvolvimento, então fico curioso para saber se a situação melhorou

  • Acho que melhorou. Quase todas, ou todas, as soluções listadas aqui parecem usar flakes internamente: https://news.ycombinator.com/item?id=39696038
    Acho que os problemas com flakes vêm de duas coisas
    Uma é que elas carregam o rótulo experimental há quase 5 anos, o que confunde usuários novos, mas na prática são usadas de forma ampla em quase todos os lugares
    A outra é que parece haver um clima ruim entre a https://determinate.systems/ e usuários/desenvolvedores antigos do Nix. Pelo que parece, a Determinate Systems é criticada por usar o Nix em benefício próprio sem retribuir com contribuições
    Pelo que entendo, a Determinate Systems introduziu flakes, e por isso algumas pessoas parecem resistir
    Em resumo, quase todo mundo adotou flakes, e guias que não as usam provavelmente são, em geral, antigos
    Link relacionado: https://discourse.nixos.org/t/introducing-flakehub/32044
  • Não conheço ninguém hoje em dia que recomende não usar flakes
    O rótulo “experimental” tem mais a ver com estabilidade da API do que com maturidade ou bugs
    Em certas situações pode haver problemas de desempenho, mas há contornos, e uma solução permanente também está em andamento
    Ainda assim, uso bastante flakes em casa e no trabalho
  • Referência: plano para estabilizar gradualmente a nova CLI e Flakes https://github.com/NixOS/rfcs/pull/136

• Testei o Flox ontem à noite no macOS e vi que ele instala o Nix no perfil padrão separadamente do Nix gerenciado pelo Nix-Darwin em /run/current-system/sw/bin, e cria um link simbólico dessa cópia em /usr/local/bin
  Também não havia orientação para usuários existentes do Nix, ou seja, usuários de NixOS ou de outras distribuições que já instalaram o Nix mas não têm um formato de pacote de distribuição suportado pelo Flox
  Fico curioso se isso acontece porque o Flox é um gerenciador de perfis de terceiros para Nix e depende de coisas como o formato instável do manifest do Nix profile, ou se na prática ele pode ser usado com várias versões do Nix, mas simplesmente não foi testado
  Também gostaria de saber se a instalação do Flox baseada em Nix é algo pensado como suporte futuro
  Além disso, foi dito que o suporte a fish está chegando, mas você poderia indicar onde a integração com shell do subcomando activate fica de fato no código-fonte ou na configuração do Flox?
  Enquanto esperava o suporte oficial a fish, tentei improvisar algo com fenv ou similar, mas, olhando a instalação e o código-fonte, não consegui encontrar bem onde encaixar isso

  • Acho que você deixou passar as abas Nix/Generic e Nix/NixOS em https://flox.dev/docs/install-flox/. Fico curioso se isso atende ao caso de uso em paralelo que você mencionou
    Acho que a melhor forma de usar fish no momento é FLOX_SHELL=zsh flox activate -- fish. Não dá suporte a aliases, mas deve funcionar na maior parte dos casos
    Também fico curioso se você realmente quer hackear o código-fonte, ou se está tentando entender a estrutura para criar um contorno
    Em shells que não sejam bash ou zsh, ele gera erro por aqui: https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827...
    Se quiser tentar corrigir diretamente, fico feliz em explicar melhor o contexto