Flox | Auto-Activation Is Now Native in Flox3.7k<br>Sign in

Features

Use Cases

Resources

Pricing

Company

Sign in

Connect

Blog / News<br>Auto-Activation Is Now Native in Flox<br>Steve Swoyer|29 July 2026

We noticed people hacking direnv so they could use it to auto-activate their Flox environments.

So we built a native auto-activation feature.

Flox already lets you define cross-platform, reproducible environments as code. A Flox environment declares a project’s runtime, packages, variables, hooks, managed services, even build recipes. But until now, you had to manually run flox activate to enter into an environment. Now, with Flox-native auto-activation, whenever a directory contains a valid Flox environment, that environment starts up as soon as you cd into it. In the same way, the environment automatically deactivates when you change out of it.

Flox can even auto-start a project’s services … and stop them when you leave:

Enter the directory and Flox activates the environment and starts its declared services.

Leave the directory and Flox stops those services, deactivates the environment, and restores your shell.

This means when you’re in your flow... everything just works. Your tools, your environment, your whole dev setup: every action flows easily, one to another. You don’t even have to think about it.

Auto-Activating / De-Activating an Environment

Let’s start with a simple example… a Flox environment that runs a llama.cpp model server for inference workloads:

schema-version = "1.13.0"

[install]<br>llamacpp.pkg-path = "flox-labs/llamacpp"<br>llamacpp.pkg-group = "llamacpp"<br>llamacpp.systems = ["aarch64-darwin", "aarch64-linux", "x86_64-linux"]

[services]<br>auto-start = true

[services.llamacpp]<br>command = '''<br>[ -f "$FLOX_ENV_CACHE/llama-server.env" ] && . "$FLOX_ENV_CACHE/llama-server.env"<br>exec llamacpp-proxy \<br>--listen "${LLAMACPP_HOST:-127.0.0.1}:${LLAMACPP_PROXY_PORT:-8081}" \<br>--backend "${LLAMACPP_HOST:-127.0.0.1}:${LLAMACPP_PORT:-8080}" \<br>--backend-api-key "${LLAMACPP_API_KEY:-llamacpp-local}"<br>'''<br>The [services.llamacpp] table declares the service. The new auto-start = true setting tells Flox to start declared services when the environment activates via auto-activation. When you change into a directory that contains a Flox environment, Flox prompts you: Do you want to auto-activate? Yay or nay?

~/dev$ cd llamacpp<br>Auto-activate the environment in '/home/floxuser/dev/llamacpp'? [y/N] y<br>Flox remembers this decision for each environment. If you allow auto-activation, entering the directory activates the environment and (if auto-start = true is set in the manifest) starts any declared services.

flox [llamacpp]:~/dev/llamacpp$ flox services status<br>NAME STATUS PID<br>llamacpp Running 1694723<br>Changing out of the directory deactivates the environment and stops the service:

flox [llamacpp]:~/dev/llamacpp$ cd ..<br>~/dev$ flox services status -d ./llamacpp<br>NAME STATUS<br>llamacpp Stopped<br>Changing back in reactivates it again:

~/dev$ cd llamacpp<br>flox [llamacpp]:~/dev/llamacpp$ flox services status<br>NAME STATUS PID<br>llamacpp Running 1700183<br>The upshot is that Flox tracks whether an environment remains in scope, manages the services associated with each activation, and restores your shell whenever you leave the environment.

Activating Nested Environments

Flox now auto-activates nested environments, too. This is especially useful with monorepos, where nested environments define distinct tools, runtimes, or services… while also inheriting a shared base environment.

Imagine that you cd directly into your working directory: a retrieval-augmented generation (RAG) project that’s nested inside Flox environments that support data prep, generate embeddings, and serve models:

~$ cd ~/dev/ai-base/ingest/embeddings/rag_app<br>Auto-activate these 4 environments?<br>/home/daedalus/dev/ai-base<br>/home/daedalus/dev/ai-base/ingest<br>/home/daedalus/dev/ai-base/ingest/embeddings<br>/home/daedalus/dev/ai-base/ingest/embeddings/rag_app<br>[y/N]<br>Each directory in this path contains its own .flox environment:

~/dev/ai-base/.flox<br>└── ingest/.flox<br>└── embeddings/.flox<br>└── rag_app/.flox<br>In this stack:

ai-base provides shared tools such as Python, uv , Git LFS, and so on;

ingest adds file-parsing dependencies + a service that monitors an input directory for file drops;

embeddings adds PyTorch, Sentence Transformers, and a local vector database service;

rag_app` provides the project’s runtime, API server, retrieval configuration, and dev commands.

Flox is smart enough to auto-activate the environments from the outside in:

ai-base → ingest → embeddings → rag_app

Defining services.auto-start = true in ingest and embeddings starts their services automatically.

Running Tools inside an Already-Activated Environment

The way Flox works is that any commands you run inside an activated environment automatically inherit that environment’s shell settings … including access to binaries, libraries, or executable commands on PATH .

With auto-activation, changing...