Flox | AI Stack as Code: Define It Once, Run It Everywhere3.7k<br>Sign in

Features

Use Cases

Resources

Pricing

Company

Sign in

Connect

Blog / Guides<br>AI Stack as Code: Define It Once, Run It Everywhere<br>Steve Swoyer|15 July 2026

“Do you have some AI stack-as-code examples?” It’s one of the most common questions we get from customers.

What they want are reference patterns for implementing declarative stacks for things like model-training, retrieval-augmented generation (RAG), embeddings, and other AI use cases. So we went ahead and built some .

One pattern composes four modular AI environments to create a reproducible, cross-platform, completely declarative AI RAG stack. It can be used either for development or as the foundation for a production RAG pattern.

A second pattern, a llamacpp-powered model serving environment, uses Flox’s documentation and articles from our blog to provide a RAG-powered knowledge assistant for asking questions about Flox. It demonstrates a production pattern for deploying AI stacks-as-code.

Let’s dig into what a stack-as-code is… and why it’s the best way to create, share, and manage AI stacks.

AI Stacks That Run on Every Machine

If you’ve ever experienced the mounting frustration, the mix of fear and loathing, of attempting to run someone’s AI stack on your local system, the genius of AI-stacks-as-code should resonate with you.

Say you’ve built something on your MacBook using Apple’s MPS APIs and you go to share it with the rest of your team… but not everybody can use it because they're on Windows or Linux machines with NVIDIA CUDA GPUs. Or imagine the reverse, where ML and AI Stacks someone built for CUDA won't run accelerated on your MacBook using MPS or Apple’s MLX framework. If It runs at all, it’s in a container, with no access to a GPU.

The ML- or AI-stack-as-code makes these problems go away. Instead of packaging and materializing an AI or ML stack’s runtime dependencies for a specific machine platform, you declare them, like so:

[install]<br>python.pkg-path = "python3"<br>python.version = "3.13.13"<br>uv.pkg-path = "uv"<br>git.pkg-path = "git"

torch.pkg-path = "python313Packages.torch"<br>numpy.pkg-path = "python313Packages.numpy"<br>jupyterlab.pkg-path = "python313Packages.jupyterlab"<br>sentence-transformers.pkg-path = "python313Packages.sentence-transformers"<br>chromadb.pkg-path = "python313Packages.chromadb"<br>The TOML above is an example of one kind of stack-as-code implementation: a Flox environment. It declares the basic dependencies for a reproducible, cross-platform AI RAG stack. Paste this into a Flox manifest and you get a runtime environment with exactly these declared dependencies. (Note : Flox isn’t the only declarative, stack-as-code technology out there. Others include Nix and Guix.) If you need GPU-accelerated packages for MPS/MLX Macs and NVIDIA CUDA to coexist in the same environment, no worries: just declare platform-specific versions of PyTorch and other performance-sensitive packages:

## cuda-accelerated dependencies<br>torch-cuda.pkg-path = "flox-cuda/python3Packages.torch"<br>torch-cuda.version = "2.10.0"<br>torch-cuda.systems = ["x86_64-linux", "aarch64-linux"]<br>numpy-cuda.pkg-path = "flox-cuda/python3Packages.numpy"<br>numpy-cuda.systems = ["x86_64-linux", "aarch64-linux"]

## mps-accelerated dependencies<br>mps-torch.pkg-path = "python313Packages.torch"<br>mps-torch.version = "2.10.0”<br>mps-torch.systems = ["aarch64-darwin"]<br>mps-numpy.pkg-path = "python313Packages.numpy"<br>mps-numpy.systems = ["aarch64-darwin"]<br>You’re not building (or re_building_) anything, least of all a multi-gigabyte container image. You’re delegating to a graph-backed resolver the work of pulling in just the right platform- and hardware-optimized dependencies. The resolver uses the stack’s declarative spec to identify compatible versions of runtime dependencies. These get materialized into an immutable, cryptographically hashed store that lives on each machine.

In other words: You declare what the stack needs; the tool resolves the dependency graph and figures out how to materialize what you’ve declared locally. Nothing gets installed globally, so your machine won’t break. You can even install conflicting versions of packages side-by-side… on the same system.

AI Stacks That Run at Any Time

This pattern also obviates one of the most frustrating parts of working with AI stacks: you’ve got the right dependencies in the right places, but the stack still won’t run because… because what now? Because the runtime environment itself isn’t standardized: the Jupyter notebook starts with the wrong Python; or the dynamic linker finds the wrong versions of native libraries; or the model cache lives in the cloud and needs an Oauth token; or the GPU runtime only works when certain shell variables get exported.

An AI stack-as-code runs and behaves the same way everywhere because it doesn’t just declare that stack’s runtime software packages… it declares the environment in which the stack itself is to...