Flox 1.0 – Codificación open source de entornos de desarrollo con Nix

• Flox es una plataforma de entornos de software para equipos de ingeniería, que gestiona con un solo manifiesto entornos idénticos y reproducibles desde la laptop del desarrollador hasta CI y producción
• Está basada en Nix, pero conocer Nix es opcional; su estructura reduce el drift de entornos mediante manifiestos declarativos e inputs con hashes de contenido fijados criptográficamente
• Funciona en macOS, Linux y Windows WSL2, permite buscar e instalar más de 120,000 paquetes de Nixpkgs y compilar/publicar software propio como paquetes reproducibles
• Con el flujo flox init, flox install, flox activate crea entornos aislados por proyecto; al activarlos aparecen las herramientas y al salir desaparecen, manteniendo el sistema limpio
• Incluye compartición con FloxHub, creación de imágenes OCI, ejecución de servicios, SBOM, parches de CVE y SCA, e incluso entornos de ejecución deterministas para agentes de coding con IA, con foco en la gestión del ciclo de vida de entornos a nivel organizacional

---

El problema que Flox busca resolver

• Flox es una plataforma que define el entorno de desarrollo en un solo archivo y hace posible ejecutar el mismo entorno en la laptop del desarrollador, en CI y en producción
• Mientras que los gestores de paquetes tradicionales se enfocan en instalar paquetes en una sola máquina, Flox administra el ciclo de vida de paquetes y entornos de toda la organización
• Tiene tres propiedades clave
  • Declarativo: describe en un solo archivo las herramientas, variables de entorno y servicios que necesita un proyecto
  • Reproducible: la misma definición crea el mismo entorno en cualquier sistema compatible
  • Componible: permite superponer entornos por proyecto, equipo o pipeline

Usuarios objetivo y entornos de uso

• Los equipos de Platform y DevX pueden estandarizar toolchains en toda la organización y extender entornos base sin obligar a aprender Nix
• Los equipos de Security y AppSec pueden trabajar con SBOM, respuesta rápida ante CVE, procedencia de dependencias y builds reproducibles
• Los desarrolladores pueden usar entornos reproducibles por proyecto en macOS, Linux y Windows WSL2, con un funcionamiento más cercano a un entorno virtual que a un contenedor o una VM
• Los agentes de coding con IA obtienen un entorno determinista donde pueden compilar y ejecutar código generado siempre de la misma forma
  • Ejemplos objetivo: Claude Code, Cursor, Copilot y Codex

Reproducibilidad y seguridad de la cadena de suministro

• Los entornos de Flox se definen con un manifiesto declarativo y quedan fijados a inputs con hashes de contenido establecidos criptográficamente
• El mismo lockfile se resuelve al mismo conjunto de paquetes en cada sistema compatible, por lo que el entorno se mantiene idéntico entre máquinas
• Una sola definición de entorno puede usarse en la laptop del desarrollador, en sandboxes de agentes de IA, en CI y en producción
• Se pueden usar más de 120,000 paquetes de Nixpkgs
• También permite compilar software propio desde el código fuente para convertirlo en paquetes reproducibles y publicarlo para uso de todo el equipo
• A partir de esa reproducibilidad, facilita la generación de SBOM, el análisis de composición de software (SCA), el parcheo automático de vulnerabilidades y CVE, la verificación de procedencia de dependencias y los builds auditables

Instalación y flujo de trabajo básico

• El CLI de Flox se instala de forma nativa en macOS, Linux y Windows WSL2
  • macOS: brew install flox o instalador .pkg
  • Linux: .deb para Debian/Ubuntu, .rpm para Fedora/RHEL
  • Windows: uso de paquetes Linux dentro de WSL2
• El flujo básico consiste en crear un entorno dentro del proyecto, instalar los paquetes necesarios y luego activar el entorno
  • flox init: crea un entorno en el proyecto
  • flox install python3 nodejs: instala paquetes en el entorno
  • flox activate: entra al entorno
• El ejemplo del README muestra que dentro del entorno activado python3 --version funciona como Python 3.13.13 y node --version como v24.15.0
• Al salir del entorno, las herramientas instaladas desaparecen, lo que evita conflictos entre proyectos y mantiene limpio el sistema

Funciones principales

• Create: con flox init se puede crear un entorno declarativo junto al código y activarlo automáticamente
• Search: con flox search se pueden encontrar más de 120,000 paquetes de Nixpkgs
• Share: con flox push / flox pull, los integrantes del equipo pueden obtener exactamente el mismo entorno de referencia único alojado en FloxHub
• Containerize: con flox containerize se puede convertir un entorno Flox en una imagen OCI sin Dockerfile
• Build & publish: con flox build / flox publish se puede compilar software propio como paquetes reproducibles y publicarlo para el equipo
• Services: con flox services start se pueden ejecutar bases de datos, colas y procesos en segundo plano como parte del entorno; se inician al activar y se detienen al salir
• Configure: en manifest.toml se definen de forma declarativa variables de entorno, hooks de shell y scripts de activación
• AI-ready: mediante flox-agentic, permite que agentes de coding con IA compilen y ejecuten con las mismas dependencias en cada ejecución

Posicionamiento frente a Docker y para usuarios de Nix

• Flox no es una tecnología de contenedores ni un reemplazo de Docker
• En Docker suele mezclarse el empaquetado con el aislamiento del contenedor, pero Flox parte de la idea de que el empaquetado de software debe separarse del mecanismo de aislamiento elegido
• Los entornos de Flox funcionan de la misma forma en bare metal, VM y contenedores
• flox containerize crea imágenes OCI que incluyen el entorno de software y pueden usarse junto con Docker, Kubernetes y otros runtimes de contenedores
• Para usuarios de Nix, Flox no es un sustituto sino una herramienta adicional
  • Ofrece FloxHub, un servicio central para entornos colaborativos y compartición de paquetes
  • Reúne hooks de activación, servicios y perfiles de shell en un solo archivo TOML declarativo

Origen y recursos de soporte

• Flox surgió a partir de un despliegue empresarial de Nix a gran escala en D.E. Shaw group, donde se usó para hacer Nix más accesible en grandes organizaciones de ingeniería
• Recursos relacionados
  • Documentation: tutoriales, referencia y guías
  • FloxHub: exploración y compartición de entornos
  • Discourse: preguntas, debate y anuncios
  • Blog: artículos en profundidad y flujos de trabajo
  • VS Code extension: gestión de entornos Flox desde el editor
• Las consultas de seguridad se reciben en [e-mail]
• La licencia del CLI de Flox es GPLv2

[GN⁺]

Comentarios en Hacker News

• Ron, felicitaciones por el lanzamiento. Lo que me da curiosidad es cuál sería el modelo de ingresos
  Hay un CEO, una empresa y empleados, y en Crunchbase parece que recibieron 24 millones de dólares en inversión, pero no encuentro información de precios en la landing page ni en la documentación
  Incluso si inicio sesión en FloxHub con mi perfil de GitHub, no veo ninguna opción de pago, así que me intriga cuál es el plan

  • Gracias por señalarlo. La modalidad gratuita y de código abierto que presentamos hoy fue una de las grandes razones para empezar Flox, y planeamos agregar mucho más en el futuro
    El cliente de código abierto que lanzamos hoy y el servicio FloxHub para compartir entornos se ofrecerán gratis para siempre
    Más adelante queremos ofrecer un catálogo de software privado más potente, montado sobre el Flox Catalog básico
    Si necesitas distribuir tus propios artefactos o versiones modificadas de paquetes de código abierto dentro de Flox, planeamos facilitar la creación de tu propio catálogo para complementar el Flox Catalog, que siempre será gratuito
    A largo plazo, queremos vender soluciones empresariales por suscripción y como servicio para ayudar a las empresas a gestionar mejor cadenas de suministro de software amplias y fragmentadas, y nos parece razonable que las empresas compartan el costo de desarrollar herramientas a su medida
  • Me sorprende que hayan recibido 24 millones de dólares. No veo muy claro el camino de aquí a una salida de 2.4 mil millones de dólares, pero les deseo suerte

• Siempre me hace ruido cuando veo en el README frases como “Nix facilita las cosas para los nuevos usuarios” o expresiones parecidas
  Me considero bastante competente, pero nunca he usado Nix y pensado “esto fue fácil”
  Los conceptos de Nix me encantan, pero la experiencia de usuario es terrible. Puede que esta herramienta resuelva eso, pero para llegar a ese punto hay tan poca documentación y tantas formas ya descartadas por las que uno termina deambulando, ajustando configuración sin parar, que resulta muy frustrante
  De todos modos, cada vez que veo algo relacionado con Nix pienso “ojalá llegue el día en que esto se vuelva fácil”

  • Si te refieres a la frase “Flox comenzó mientras el grupo D. E. Shaw adoptaba Nix, y rápidamente demostró su valor al hacer que Nix fuera más fácil para los nuevos usuarios”, a mí me suena al revés de la interpretación original
  • Esa frase no significa que Nix sea fácil para los nuevos usuarios, sino que Flox hace que Nix sea más fácil
  • He tenido exactamente la misma experiencia. Probé NixOS durante bastante tiempo, pero nunca logré acostumbrarme a .nix ni a flakes
    Los conceptos básicos se me seguían yendo de la cabeza, así que cada vez que quería configurar algo nuevo tenía que volver a buscarlos y al final me cansé
    También es difícil depurar problemas, y para saber qué salió mal hay que rebuscar entre comandos muy específicos y un sistema de archivos infernal
    La idea me gusta, pero en la práctica siento que estorba demasiado
  • Me gusta Nix y hasta he contribuido bastante con paquetes al repositorio de nix, pero de ninguna manera diría que es fácil
    Tengo experiencia con Haskell, así que se me hace más familiar, pero la sintaxis en sí tampoco es intuitiva para usuarios nuevos
  • Totalmente de acuerdo. Se le ven las ventajas, pero la curva de aprendizaje inicial es tremendamente empinada
    Se parece a aprender Rust, así que hasta tiene su lado divertido

• El problema central de los productos del tipo “te damos el poder de Nix sin curva de aprendizaje” es que por debajo siguen estando Nix y /nix/store, y Nix intencionalmente no limpia eso de forma automática
  Si un usuario prueba una herramienta que oculta Nix, al final igual se le va a llenar el disco, y como no sabe cómo liberar espacio, cuesta llamarlo algo amigable para el usuario
  Es diferente cuando el usuario sabe que está instalando Nix y pasa por el proceso de aprendizaje, porque así puede formarse un modelo mental de qué es /nix/store y cómo debe gestionarlo
  Me da curiosidad cómo planean manejar esta complejidad subyacente

  • Si das soporte a rollbacks e historial, el disco necesariamente se va a llenar. En Nix normalmente hay varios GC roots apuntando a perfiles y paquetes, así que no se pueden limpiar
    Los entornos de Flox no son simples enlaces simbólicos, sino un formato declarativo que internamente tiene flakes, así que se pueden eliminar y volver a reproducir después si hace falta
    Por eso la recolección de basura es menos destructiva que al usar nix-env/nix profile, y se pueden limpiar generaciones viejas de forma más agresiva
    La estrategia es garantizar siempre una forma declarativa y reproducible de recuperar lo que se limpió, y luego evitar que el disco se llene usando heurísticas como espacio libre, antigüedad, falta de uso reciente y baja frecuencia de uso
  • Me pregunto cómo se compara con Docker o Bazel
    En cambio, con Nix nunca he tenido este problema. Explica con claridad cómo limpiar basura, y también es fácil investigar qué sigue ahí y por qué sigue ahí
    La razón por la que no está activado por defecto es que, como cualquier otro recolector de basura, puede volverse una molestia, y no existe una política que le sirva a todo el mundo
    Al final, si hay demasiados GC roots, hay que tomar decisiones
  • Nix sí soporta recolección de basura
    Cada vez que usas una computadora están ocurriendo por detrás miles de cosas ridículamente complejas, así que no entiendo por qué abstraer Nix se trata como algo especial
  • En el trabajo también tenemos el mismo problema con Bazel. Después de unos meses, el disco de la máquina de desarrollo se queda sin espacio
  • Basta con configurar la recolección de basura de Nix para que corra cada 30 minutos

• Felicitaciones por el lanzamiento. Me gusta mucho Nix, pero también reconozco que la experiencia de onboarding es, siendo generosos, mala, y en el peor de los casos terrible.
  Por eso, cualquier intento de hacerlo más accesible es bienvenido. Una CLI imperativa me parece una buena dirección porque se acerca mucho más a la forma que mucha gente espera y con la que se siente cómoda.
  También coincido totalmente en simplificar el proceso de usar entornos de otros lugares.
  Pero algo importante que parece faltar es la integración con IDE. Iniciar el IDE desde la línea de comandos dentro del entorno no resulta intuitivo para muchos colegas, y de hecho lo he diagnosticado varias veces como la causa raíz de problemas reales.
  Me pregunto qué pasará con la posibilidad de bajar al “Nix real” cuando haga falta. Por ejemplo, me preocupa si en entornos un poco más complejos, como configurar toolchains de compilación cruzada para Rust, uno se va a caer por un precipicio.
  Como ejemplo de desarrollo en Rust, tuve que poner un shellHook largo en un flake para que Rust-Analyzer funcionara correctamente, y me pregunto cómo se podría hacer ese tipo de configuración en Flox.
  También me pregunto si la idea es abstraer ese tipo de cosas o, si no, cómo las va a descubrir un usuario que no conoce Nix.
  No quiero decir que sea absolutamente imposible; de verdad espero que funcione muy bien, pero todavía no veo claramente cómo.

  • La parte de bajar al “Nix real” cuando haga falta ya la hemos discutido, y el plan es permitir usar Nix directamente cuando se necesite potencia adicional.
    La idea actual es permitir referencias a flakes en ciertos campos o tener puntos de entrada al estilo de Nix.
    Aún no es algo público ni está documentado, así que agradeceríamos un poco de paciencia.
    Coincido por completo en que hay una línea realmente sutil entre ocultar la complejidad y exponer la capacidad.

• Me pregunto cuál es la ventaja de usar Flox en lugar de un nix-shell normal o nix develop.

  • Trabajo en Flox. Para empezar por la relación con las herramientas de Nix, el objetivo es ser más amigable para el usuario.
    La idea es que puedas tener éxito sin aprender el lenguaje de expresiones de Nix ni entender su estructura interna.
    También agregamos cierta dirección y pulido. Por ejemplo, hay una interfaz híbrida imperativa/declarativa, así que si ejecutas flox install && flox list, los cambios se reflejan en TOML. En cambio, con nix develop tienes que editar expresiones de Nix.
    nix develop te mete en un shell de bash, pero flox activate puede entrar a shells bash o zsh, y planeamos agregar soporte para fish.
    Administrar entornos con Git está soportado, igual que en las herramientas de Nix, pero además agregamos formas de compartir entornos que esas herramientas no ofrecen, como flox push/flox pull/flox activate -r.
    Si creas una cuenta, puedes ver los paquetes de mi entorno en https://hub.flox.dev/mkenigs/default, y si tienes la CLI, puedes revisarlos con flox list -r mkenigs/default y luego usarlos con flox activate -r mkenigs/default.
    Me parece mucho más digerible para alguien que no conoce el lenguaje de expresiones de Nix que pasarle un enlace a un flake.nix.
  • Dicho de otra manera, creo que para cada ingeniero individual es mejor aprender la tecnología subyacente y las herramientas que la acompañan.
    Es totalmente posible que herramientas como Flox o devenv lleguen al fin de su vida útil, no logren seguir bien el ritmo de nixpkgs, o sufran alguna de las muchas formas en que el software se deteriora.
    En cambio, nix develop seguirá existiendo mientras Nix Flakes siga existiendo, y además habrá incentivos para ofrecer una ruta de migración hacia lo que venga después.
    Más importante aún: toda abstracción tiene fugas. Aunque la CLI de Flox pueda verse más limpia, al final vas a tener que aprender Nix para usarlo de forma realmente efectiva.
    No veo por qué aprender el doble de lo que realmente necesitas.
  • O también está https://devenv.sh.

• Me pregunto cómo se compara con el proyecto Devbox existente (https://www.jetpack.io/devbox).
  También quiero saber si Flox tiene una solución en la nube opcional, si permite instalar versiones específicas de paquetes de Nix y cómo maneja las dependencias según el sistema operativo.
  Llevo 5 años usando herramientas de este tipo, así que me interesa qué aporta Flox que no exista ya.

• De verdad no entiendo por qué debería usar esto en lugar de Nix normal; ¿alguien me lo puede explicar?

  • Solo quiero entornos limpios y reproducibles por proyecto. He intentado entrar a Nix varias veces, pero Nix hace tantas cosas que cada vez termino sintiéndome abrumado.
    Esto me parece 100 veces más simple.
  • Entiendo que Nix resuelve muchos problemas, y de hecho aposté por sus capacidades. Por eso también invertimos mucho esfuerzo en Nix mismo.
    Pero Nix se construyó desde los primeros principios para ser muy general, así que su curva de aprendizaje es bastante pronunciada.
    Flox es una herramienta que intenta simplificar eso reduciendo el alcance del problema y ofreciendo abstracciones e interfaces especializadas, para que puedas aprovechar las capacidades de Nix sin tener que volverte experto en Nix desde el primer día.
  • Es muchísimo más fácil convencer a mis colegas de usar flox o devenv que convencerlos de usar Nix.

• Me interesan muchísimo los entornos de desarrollo reproducibles, y en el trabajo llevo años usando contenedores de desarrollo con buenos resultados.
  Escuché sobre Nix por primera vez hace como un año y al principio me entusiasmó mucho la promesa, pero el proceso de onboarding fue terrible para mí.
  Tengo claro qué entorno de desarrollo quiero crear, pero siempre siento que me estoy perdiendo algo en el enfoque.
  Me alegra ver herramientas nuevas que intentan mejorar toda la experiencia, y ojalá, si sigo probando, en algún momento me haga clic.
  Me da curiosidad saber en qué momento Nix te “hizo clic” a ti.

  • Gracias por la pregunta. Este es un tema para conversar a fondo con una cerveza si alguna vez vienes al Bay Area.
    ¿Has visto por casualidad el video de Microservices? https://www.youtube.com/watch?v=y8OnoxKotPQ
    En ese momento yo dirigía el equipo de productos para desarrolladores en Facebook, y comenzamos un proyecto para inyectar capacidades remotas en el desarrollo local.
    Miles de desarrolladores estaban esperando 45 minutos por compilaciones en frío.
    Una de las primeras etapas fue dibujar todo el ciclo de vida del desarrollo de software para identificar qué partes del toolchain tendríamos que reconstruir.
    Como se ve en el pizarrón hacia el final del video, en el momento en que visualizamos lo complejas que habían llegado a ser las cosas, entré en ese estado mental de “no puede ser que así sea como trabajamos”.

• La última vez que usé Nix, había mucha confusión alrededor de flakes
  Algunos tutoriales decían que había que usarlas y otros que todavía estaban en desarrollo, así que me pregunto si la situación ha mejorado

  • Yo diría que sí. Parece que casi todas, o incluso todas, las soluciones listadas aquí usan flakes internamente: https://news.ycombinator.com/item?id=39696038
    Creo que el problema con flakes viene de dos cosas
    Una es que han llevado la etiqueta experimental por casi 5 años, así que eso confunde a los usuarios nuevos, aunque en la práctica se usan de forma bastante generalizada casi en todas partes
    La otra es que parece haber mala relación entre https://determinate.systems/ y usuarios/desarrolladores veteranos de Nix. Al parecer critican a Determinate Systems por usar Nix para su propio beneficio sin retribuir con contribuciones
    Según entiendo, Determinate Systems introdujo flakes, y por eso parece que parte de la comunidad se resiste
    En conclusión, casi todo el mundo adoptó flakes, y las guías que no las usan probablemente sean antiguas
    Enlace relacionado: https://discourse.nixos.org/t/introducing-flakehub/32044
  • Ya no conozco a nadie que recomiende no usar flakes hoy en día
    La etiqueta “experimental” se refiere más a la estabilidad de la API que a su nivel de terminación o a bugs
    En ciertas situaciones puede haber problemas de rendimiento, pero hay formas de rodearlos y también se está trabajando en una solución permanente
    Aun así, uso flakes bastante tanto en casa como en el trabajo
  • Referencia: plan para estabilizar gradualmente el nuevo CLI y Flakes https://github.com/NixOS/rfcs/pull/136

• Anoche probé Flox en macOS y vi que instaló Nix en el perfil por defecto, separado del Nix que Nix-Darwin administra en /run/current-system/sw/bin, y que hizo un enlace simbólico de esa copia en /usr/local/bin
  Tampoco encontré orientación para usuarios de Nix ya existentes, es decir, usuarios de NixOS o usuarios de otras distribuciones donde ya está instalado Nix pero no existe el formato de paquete de la distro que Flox soporta
  Me pregunto si eso se debe a que Flox, como administrador de perfiles de terceros para Nix, depende de cosas como el inestable formato Nix profile manifest, o si en realidad puede usarse con varias versiones de Nix pero simplemente no lo han probado
  También quisiera saber si consideran dar soporte más adelante a una instalación de Flox basada en Nix
  Además, dijeron que el soporte para fish viene en camino, pero ¿podrían decirme en qué parte del código fuente o la configuración de Flox está realmente la integración con el shell del subcomando activate?
  Mientras espero el soporte oficial para fish, intenté improvisar algo temporal con fenv, pero incluso revisando la instalación y el código fuente no me quedó claro dónde conectarlo

  • Parece que te perdiste las pestañas Nix/Generic y Nix/NixOS en https://flox.dev/docs/install-flox/. Me pregunto si eso cubre el caso de uso en paralelo que mencionaste
    Por ahora, creo que la mejor forma de usar fish es FLOX_SHELL=zsh flox activate -- fish. No soporta alias, pero la mayor parte debería funcionar
    También me pregunto si realmente quieres hackear el código fuente o si solo estás tratando de entender la estructura para armar una solución alternativa
    En shells que no son bash ni zsh, falla por aquí: https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827...
    Si quieres intentar arreglarlo tú mismo, con gusto te doy más contexto de fondo