Flox

#PlanetNix 2026 throwback! Kelsey Hightower on discovering #Nix and realizing there was a fundamentally different way to think about software.

RustWeek is almost here, and Flox is excited to be part of the energy in Utrecht. This year's program is packed: a RustWeek-record 8 workshops, talks spanning web, gaming, embedded, compiler work, production Rust, open source, education, and more — plus a live recording on oxidizing the Linux kernel with Matthias Endler, Alice Ryhl, and Greg Kroah-Hartman. Flox's Yannik Sander will be there next week, May 18-23, to learn, connect, and enjoy the conference. He'd also be open to meeting with folks who want to talk about Nix, reproducible development environments, Rust workflows, or how teams can make development setups easier to share and maintain. Yannik is also attending as a participant — catching talks, joining hallway conversations, and making the most of the program — so his meetup time will be limited. Ping him early at yannik at flox dot devto find a slot! See you in Utrecht!

fellow.ai supports distributed teams across 100+ countries. But growth exposed familiar problems: ⚠️ Inconsistent dev environments ⚠️ “Works on my machine” failures ⚠️ Slower onboarding + rising release risk With Flox, Fellow standardized reproducible environments across the SDLC without changing how engineers work. Result: faster onboarding, higher velocity, fewer fire drills, and a more reliable path from dev → CI → prod. “Flox gives us a dependable foundation so we can move fast with tight feedback loops.” — Samuel Cormier-Iijima, CTO & Co-Founder Case study in comments.

Security and compliance work often comes down to certifying system state by reconstructing from scattered clues: scans, SBOMs, build records, tickets, cloud inventory, Kubernetes data. That is not a diligence problem. It is a delivery-system problem. Secure software by construction means the runtime environment carries provenance, traceability, and auditability from build to production. This changes the basis of proof, eliminating guesswork with versioned, reproducible, auditable environments across the SDLC. Read more about it here: buff.ly/5uhP9hm

@techgirl1908 Hell yeah! @floxdevelopment is super cool stuff! Met @ronefroni at a hack night event had me convinced of how useful it is

As engineering orgs become more fluent with AI, there's less of "this is the repo I work on every day". Now engineers bounce across repos, making driveby contributions - just implementing whatever needs to be done for the day. You no longer have to be an SME to contribute to an unfamiliar codebase. One friction point though is bootstrapping. Platform teams are now looking to create clone-and-go setups so that devs (and agents) can quickly get going in a given repo. Containers are one way to do this, but then I'm in an isolated bubble and it's harder to use my real environment... bruh, I need my local tools too! 😫 @floxdevelopment is approaching it differently. With Flox, I (or my agent) can activate the repo's declared environment complete with pinned dependencies without leaving my native system. Best of both worlds. Check out this great blog post to learn more: fandf.co/4eEGI03 Shout out to the Flox team for collaborating with me on this.

We just published a deep dive to clarify it all: “Package Managers and Package Management: A Guide for the Perplexed” Inside, we break down: - The real role of package managers (and their limits) - Why containers ≠ packaging - The difference between package vs. environment management - When to use tools like pip, npm, Conda, and when they fall short - Why reproducibility across the entire SDLC is still unsolved (for most teams) If you’re making decisions about developer tooling, platform strategy, or scaling engineering teams, check this out! buff.ly/RmpiS9j

CVE remediation is a dependency-graph problem. Scanning attempts to infer from built artifacts. Flox/Nix derive artifacts + runtimes from the causal dependency graph. Remediation = dbms lookup + declarative edit: identify artifacts/envs, pin a replacement ref, promote. Read more in the comments!

Containers or Flox? For many teams, it’s not either/or but both/and. It’s Flox for the project runtime and containers for services. This complementary pattern is what our new guide explores. - Use Flox for languages, toolchains, dependencies and local dev - Use containers for Postgres, Redis and other long-running services - Reuse the same environment in CI - Reduce environment drift without giving up existing container workflows We’re also sharing a short clip from @Rok on building containers with Flox, including thoughts on reproducibility, customization and why containers + Flox can work well together. buff.ly/wUjBYDv Deep dive on the blog! buff.ly/pNrVDda

We talk a lot about #AI right now, but this keeps coming up in conversations: determinism and reproducibility. If code is being generated by agents, and systems are getting more complex, you need to be able to answer a pretty simple question: what actually ran? Same inputs, same environment, same result. Otherwise it’s really hard to debug anything, share it with a team, or move it to production with confidence. Not a new idea, but it matters a lot more now. Ron on this at PlanetNix 2026 👇

One of the most expensive problems in software supply chain #security is knowing when it’s OK to be concerned. CVEs drop every single day. To some team, somewhere, even the most niche CVE can be a world-wrecker: a five-alarm fire requiring an immediate, all-hands-on-deck response. But how do you know? 👀 Knowing should be simple, unequivocal, immediate. In too many organizations it isn’t: Security asks “Where is this vulnerable package or dependency running?” and then the scramble begins. Engineering has one part of the picture, Platform another, Compliance still another. Security pulls vulnerability scanning results. Engineering digs through CI logs and published build metadata. Platform struggles to determine what’s actually running and where. Compliance assembles all these inputs, trying feverishly to stitch together a retroactive source of truth. Hours fly by, sometimes days. Thanks to these heroic efforts, the vulnerability gets triaged and addressed. If you don’t have a single version of the truth for what you’ve built, which versions of which dependencies went into it, and where it’s deployed + running, your ability to respond to CVEs must always depend on heroic fire-fighting. Thankfully, this reactive model has a cheat code: a delivery system where reproducibility, traceability, auditability, and policy enforcement are built into software delivery from the beginning. This is what Flox means when we talk about “secure software by construction:” guaranteeing these same qualities as properties of the way software gets built, packaged, and realized at runtime. It’s a better way to run software: the difference between operating from concrete facts and guessing. buff.ly/DaJC0PV

Working with AI tools in your dev workflow? There’s more than one way to integrate them with your environment. In this quick Flox tutorial, we show a few approaches: → Activate your environment and run tools like Codex or VS Code → Use Flox inside your editor (Cursor, VS Code, etc.) → Let AI agents install packages and manage environments for you The interesting part: your AI can actually search the Flox catalog, install dependencies, and activate environments on the fly. If you’re building with AI, your environment matters more than ever. buff.ly/TM4euVy

“Feels like everyone just wants to solve problems together.” One of the best parts of #PlanetNix this year? The community. Captured a bit of that vibe along with a few favorite moments and talks from the event. And a little throwback to our after party, good times! 💜

What if the same ML/AI runtime could follow your team from training on Slurm to serving on #Kubernetes? That’s the idea behind our new guide: It walks through how to use Flox to build a shared, declarative runtime foundation for AI workflows across: - local prototyping - GPU training on Slurm - evaluation and packaging - Kubernetes deployment Instead of rebuilding images and re-debugging dependencies at every stage, teams can promote one pinned environment across the lifecycle. A practical look at: - PyTorch runtimes that work across platforms - modular CUDA environments - build toolchains for R&D and MLOps - reproducible deployment patterns for AI teams Check it out! Linked in the thread!

A lot of people are talking about frontier models but less attention is going to how you run them reliably. That’s where environments matter. Our new guide shows how to run Gemma 4 and GLM 4.7 Flash locally with Flox using turn-key model-serving stacks for Ollama and LM Studio, across Mac, Linux, and Windows (WSL2). It’s a practical look at deterministic foundations for local AI workflows: - Native hardware acceleration (CUDA + Metal/MPS) - Reproducible environments instead of fragile setup - Built-in agents like Claude Code, Codex, and OpenCode running against local frontier models If you’re exploring agentic development, check this out! Linked in the thread.

In capital markets, speed matters. But so do control, auditability, and the ability to reproduce exactly what’ s running in production. That’s where ML/AI workflows get tricky. CUDA, Python, model-serving frameworks, native C/C++ dependencies: the stack is fragile, tightly coupled, and difficult to update without introducing risk. In this case study, we explore how firms are using Flox & Nix to: 🟣 reduce the rebuild → publish → redeploy tax 🟣 promote and roll back by pinned reference 🟣 improve traceability and supply-chain visibility 🟣 move faster without giving up control A practical look at reproducible ML/AI infrastructure for regulated environments. Linked in the thread!