One command in. flox activate out.
Point it at a repo you already have. It reads what is there, pins it, and proves the environment starts before it says it is done.
Installs the Flox CLI on macOS and Linux. Other ways to install
Then, in the repo you already have
Or skip the command and just ask: “Get this repo running with Flox.”
Run these from a clone of flox/flox-skills.
Then, in the repo you already have
Codex loads the skill from what you ask. There is no command to type.
Cursor, Copilot, Windsurf, Gemini and more, through skills.sh. Third party, needs Node.
Then, in the repo you already have
Your agent loads the skill from what you ask. There is no command to type.
No repo handy? Use ours.
Bring your own agent.
One new directory appears, and not one tracked file is touched. Nothing is called done until the environment has started and your interpreters have run inside it.
5
files written, all under .flox/
0
tracked files modified
0
lines deleted, anywhere
0.19s
to re-enter the environment
$ git statusOn branch mainUntracked files:(use "git add <file>..." to include in what will be committed).flox/nothing added to commit but untracked files present
$ git add -A && git diff --cached --stat.flox/.gitattributes | 1 + .flox/.gitignore | 5 + .flox/env.json | 4 + .flox/env/manifest.lock | 437 ++++++++++++++++++++++++++++++ .flox/env/manifest.toml | 26 ++ 5 files changed, 473 insertions(+)
[install]
go.pkg-path = "go" postgresql.pkg-path = "postgresql_16" redis.pkg-path = "redis"
[vars]
PGPORT = "5432" PGDATABASE = "checkout" REDIS_PORT = "6379"
[hook]
export PGDATA="$FLOX_ENV_CACHE/pg" [ -d "$PGDATA" ] || initdb -D "$PGDATA" ...
[services]
postgres postgres -D ... -p "$PGPORT" redis redis-server --port "$REDIS_PORT"
[options]
systems = ["x86_64-linux", "aarch64-linux", "aarch64-darwin"]
Read from the checkout-service run above. Agent packages (flox/claude-code, flox/codex) are real catalog entries you can add, not part of that manifest.
The toolchain, the databases and the environment variables all come with it.
No Docker
Databases start with it
and stop when you leave
$ flox activate --start-services -c "flox services status"NAME STATUS PIDpostgres Running 36881redis Running 36883$ pg_isready -h /tmp -p 5432/tmp:5432 - accepting connections$ redis-cli -p 6379 pingPONG
No installs
Already on your PATH
go: go (1.26.4) postgresql: postgresql_16 (16.14) redis: redis (8.8.0)
No onboarding doc
Everyone else just clones
$ git clone ...$ flox activatethat is the whole setup
No. It writes 5 files inside .flox/ and nothing anywhere else. Your devbox.json, Brewfile, .devcontainer/ and flake.nix keep working exactly as they do now, and nothing that git already tracks is edited. If you hate the result, the directory is the whole footprint.
The pin files you already keep: .python-version, .nvmrc, go.mod, rust-toolchain.toml and their equivalents. It also converts what other tools left behind, so devbox.json, .devcontainer/, a Brewfile, and asdf or mise pins all become manifest entries rather than being ignored. Anything it cannot pin from a file in the repo, it says so rather than guessing quietly.
Runtimes: Python, Node, Ruby, Go, Rust, PHP, Elixir, .NET, Deno and Bun. Package managers: uv, Poetry, npm, pnpm, Yarn, Bundler, Cargo, Composer and Mix, whichever one the repo already uses. The package manager runs on activation, so a clone is one command away from running. Ruby with native gems is the case most likely to need a hand afterwards.
It stays yours. PostgreSQL, Redis, MySQL, MariaDB and MongoDB can become managed Flox services that start and stop with the environment, but a docker-compose, Tilt or Sentry devservices topology is handed back to its own orchestrator instead of being half-translated.
No. Flox manages runtimes, system libraries and databases, which is the layer your package manager assumes is already there. Your package manager still runs, inside the environment, from the on-activate hook.
It switches to audit mode and reports gaps instead of overwriting. An existing manifest is never modified, so running it on a repo someone else already set up is safe and tells you what is missing.
Yes, that is the point of it. Committed, the next person clones and runs flox activate and is done. Uncommitted, you have solved the problem for exactly one machine.
Delete the directory. The skill offers that as an option when it finishes, and it runs rm -rf .flox/. There is no other state to clean up, nothing registered globally and nothing to uninstall.
Yes. The installer in step 01 detects your platform and installs the .pkg on macOS, the .deb on Debian and Ubuntu, and the .rpm on Fedora and RHEL. It stops rather than touching an existing Flox or Nix install.
floxify reads your repo and resolves against a live catalog, so it can be wrong. A clean verify means consistent with the files it read, not that it is correct. Ruby with native gems and polyglot monorepos are the hard cases. Read the manifest before you commit it.
Their setup README, steps, caveats and all.
Before, our local dev guide comprised 16 steps with 14 caveats. Now, it's just a universal flox activate.
We could tell people what to install, but we couldn't make sure they were actually on the same thing.
We had a lot of different environments. When something changed, we didn't have a good way of getting everyone updated.
Same problem, same fix: NVIDIA, D.E. Shaw, Arcesium, Neo4j, Weaviate, Detaso.
We're building the future of software and infrastructure management.
