Authentication - Flox

Flox

4 min read Original article ↗

Starting in early October 2026, several Flox CLI commands will require authentication with a free Flox account.

What’s changing

Several Flox commands have always run through Flox cloud services for search, indexing, package resolution, and environment operations. Beginning in early October, these commands will require authentication to communicate with the Flox catalog:

Other commands such as flox activate will require authentication only when an environment doesn’t already have a lockfile.

Probably not, and if you do it’s one command. Find the row closest to how you use Flox.

What stays the same

flox activate does not require authentication for an environment that already has a lockfile. If your daily workflow or CI pipeline simply activates an existing environment that relies on public packages, nothing changes for you. flox search and flox show stay open too, so browsing the catalog needs no account. So does pulling a public environment with flox pull. Private packages and environments continue to require authentication as they do today, and so does publishing. Nothing about those changes.

Why we’re doing this

Flox has grown from an open source CLI into foundational infrastructure used across developer machines, CI, build systems, and increasingly AI agents. As usage has grown exponentially, so has our responsibility to operate the cloud services behind Flox reliably and to keep improving them based on how they’re actually being used. Requiring authentication for the commands that interact with those services gives us a better foundation for understanding those workflows, operating the service reliably, and investing in the parts of Flox people depend on most. It also gives us better standards around abuse prevention. We’re intentionally keeping flox activate available without an account for public environments. If you’re consuming an environment someone else maintains, you do not need to create an account just to use it. To be clear: this is not a paywall. The free tier keeps the same capabilities it has today. You’ll need a free account for the commands above, not a paid subscription.

Signing in

FloxHub has made it easy to login. How you sign in depends on where you’re running Flox.

Run flox auth login and follow the browser prompt. You can log in with an existing GitHub, Google, or GitLab account. If you don’t have an account, the same flow creates one.

You do this once per machine. Paid customers can also authenticate with their own SSO provider — see Enterprise SSO.

Over SSH, inside a container, or anywhere a browser can’t open, use a token instead. A personal access token signs the CLI in as you. A service account token signs it in as your organization. The CLI reads either one from the same variable.

You can also sign in on the web at hub.flox.dev.

CI and automation

Automation breaks quietly, so it’s worth handling before anything else. Two ways through:

  • Commit your lockfile. A pipeline that activates an existing environment against a committed manifest.lock never calls the catalog, so there’s no token to manage. You get reproducible builds and one less network dependency out of it, which is worth doing anyway.
  • Or give the pipeline a token. Pipelines that run flox install, flox upgrade, or any of the other commands above do reach the catalog. So does flox build when the lockfile it’s building against is out of date. Issue a token in FloxHub and set it as FLOX_FLOXHUB_TOKEN from your CI platform’s secret store. The pipeline or agent then runs Flox commands without user interaction.

A personal access token works on any account, including a free personal one, and acts as you. A service account token belongs to an organization instead, so the pipeline keeps running after someone changes teams or leaves. The CLI reads both from the same variable. The CI/CD tutorial covers setup on specific platforms.

FAQ